This commit removes all remaining references to cs_comments_service
except the ForumsConfig model. The only purpose of keeping the model
and table around is so that the webapp processes don't start throwing
errors during deployment because they're running the old code for a
few minutes after the database migration has run. We can drop
ForumsConfig and add the drop-table migration after Ulmo is cut.
Also bumps the openedx-forum version to 0.3.7
---------
Co-authored-by: Taimoor Ahmed <taimoor.ahmed@A006-01711.local>
This commit migrates the data calculation logic for the GradeSummary
table, which was previously in the frontend-app-learning.
This commit also introduces a new visibility option for assignment
scores: “Never show individual assessment results, but show overall
assessment results after the due date.”
With this option, learners cannot see question-level correctness or
scores at any time. However, once the due date has passed, they can
view their overall score in the total grades section on the Progress
page.
These two changes are coupled with each other because it compromises
the integrity of this data to do the score hiding logic on the front
end.
The corresponding frontend PR is: openedx/frontend-app-learning#1797
If ENABLE_MKTG_SITE is True, MKTG_URLS['ROOT'] must be set. However if
it is set to the same value as the LMS_ROOT_URL (which points to this
view), you can end up in an infinite redirect loop. If the two URLs do
match, don't redirect, just fall through to the content that this page
would have responded with instead.
The behavior of the MariaDB backend has changed behavior for UUIDField
from a `CharField(32)` to an actual `uuid` type. This is not converted
automatically, which results in all writes to the affected columns to
error with a message about the data being too long. This is because the
actual tring being written is a UUID with the `-` included, resulting in
a 36 character value which can't be inserted into a 32 character column.
This removes the last remaining code that called out to the
cs_comments_service. All forums backend logic now uses the v2 API from
the forum repo (https://github.com/openedx/forum). This does NOT remove
MongoDB support.
This also implements the endpoint to retrieve all comments for a user
using the new forum backend. This is not actually called from any known
frontend code, but it has not been formally deprecated as an endpoint,
and therefore needs to be supported.
As part of the cleanup, the ENABLE_FORUM_V2 course waffle flag has also
been removed, along with all remaining switching logic that used to
route between the Python API in the forum repo and service calls to the
cs_comments_service Ruby service.
Other endpoints affected (switching logic removed):
* get course commentable counts
* get/update course user stats
* update comment/thread/user
* delete thread (implementation moved to forum repo)
* follow
* retire user
This is part of the following overall DEPR ticket:
https://github.com/openedx/cs_comments_service/issues/437
By adjusting social media sharing settings(specifically linkedin) certificate parameters are autopopulated to LinkedIn API. Additional setting parameters(such as CERTIFICATE_LINKEDIN_DEFAULTS_TO_COURSE_ORGANIZATION_NAME) are introduced to override existing(platform level parameter for organization name) parameters for an operator to configure course level organization name. This will enable learners to share certificate in to LinkedIn with an option for course associated organization to be autopopulated.
- Adds `blockType` and `is_modified` to the `showXBlockLibraryChangesPreview` iframe message.
- Add title to the `xblock_iframe`
- Add `is-modified` to `studio_xblock_wrapper`
- Add `disable_staff_debug_info` as a query param in `render_xblock`
- `downstream_is_modified` added to ComponentLink and ContainerLink
Block structures are meant to be an optimization for the LMS, meaning
that they should always be collecting from the published branch of
modulestore. This is what happens by default when it's run from the LMS
celery process, but this code is sometimes invoked from a Studio worker
(e.g. development mode celery, running in immediate in-proc mode).
---------
Co-authored-by: Peter Pinch <pdpinch@mit.edu>
The library consisted of this set of utilities and a cli and was only
being used in the edx-platform repo. The CLI will be DEPRed along with
the repo but the code that is being used for retirement will be moved
here.
Rationale: The instructor may create short labels that are longer than
3 characters, and they can be hard to work with in the mobile UI. Thus,
on mobile, it was decided to add short labels to the api response by
getting them from section breakdown, which ensures they are consistent
with the labels the user sees in the Grading section.
- This will force the use of the new v2 forum's APIs for Threads & Comment.
- Update params for get_user_subscription function. It uses the same structure as we have in the get_user_threads.
* feat: automatically follow post while createing comments/responses
* feat: follow post when a comment or response is created
* test: updated tests
---------
Co-authored-by: Ayesha Waris <ayesha.waris@192.168.10.28>
Co-authored-by: Muhammad Adeel Tajamul <muhammadadeeltajamul@hotmail.com>
There was problem in filter_discussion_xblocks_from_response(). This
function was breaking the list response for the BlocksInCourseView by
returning a dict instead of list.
Currently the LTI provider implementation auto-creates a random user when
logging in, however, the LTI launch can include relevant user details such as
their email, full name and even a username. This change makes the LTI code
use the provided details if the "Use lti pii" setting is set in the Django
admin.
Adds a new Django setting called `LTI_CUSTOM_PARAMS` that allows extending the
list of optional LTI parameters processed by the platform. These parameters can
be used by plugins for deeper platform integration.
