As part of the implementation of this ADR, we determined that we needed
to make some of the endpoints that return JWTs able to produce
asymmetric JWTs as needed, since asymmetric JWTs are a requirement
in certain cases. This ADR update notes this additional consequence.
The new mechanism for marking that a unit has discussions is to use the
discussion_enabled flag instead of adding a discussion block. This change
adds code that is run during the course rerun process to mark any existing
units that have a discussion block as discussible using the new mechanism.
It doesn't touch the existing discussion blocks.
If the new discussions configuration experience is globally enabled, this
will also switch from the legacy provider to the new provider. It analyses
the course for any discussion blocks that have been added to graded
subsections, and if that is the case, it also automatically enables
discussions in graded subsections (which are otherwise disabled for new
courses by default).
[APER-1968]
We don't have a good way to understand if grade data in Credentials is out of sync with the LMS. Grades are sent to Credentials via a REST API call originating from an asynchronous Celery task on the LMS side. This PR updates our Celery task `send_grade_to_credentials` to include sending the `modified` DateTime value of a grade record to the Credentials IDA. Updates will be made on the Credentials side to accept and store this data as part of the UserGrade instance.
* Updates the `send_grade_to_credentials` task to include passing the grade's `modified` DateTime info as part of the request data to Credentials
* Updates the `CourseGradeBase` class to include an optional `last_updated` field. This will store the `modified` date of a PersistentCourseGrade instance when a grade is read through the CourseGradeFactory.
* Update existing log statement to use format strings where possible.
This removes user-facing Studio edit support for Old Mongo courses
(courses that have a CourseKey of the format {org}/{course}/{run}).
This does not affect our normal courses, which have CourseKeys
starting with "course-v1:".
After this commit:
* Old Mongo courses will continue to appear on the Studio course
listing page, but are not clickable.
* Any attempt to directly access an Old Mongo course in Studio via URL
fail with a 404 error.
* Course certificates will still be available for Old Mongo courses.
* Old Mongo courses will continue to be returned by CourseOverviews
and get_course_summaries() calls.
We decided against removing Old Mongo courses from the listing entirely
because that would require very expensive CourseOverviews query to
filter them out. Making that query more efficient would involve a
database migration to add appropriate indexing, which is something else
that we are looking to avoid. CourseOverviews are used everywhere in
the system, so we want to avoid changing how they work so that we can
minimize risk.
This is part of the Old Mongo Modulestore deprecation effort:
https://github.com/openedx/public-engineering/issues/62
Tracks a discussion topics' section and subsection in a new context field so that we have access to that information when the topic's section/subsection/unit has been deleted. This is then used when a topic is deleted to append the section and subsection name to the topic title.
ADR: https://github.com/openedx/edx-platform/pull/29928
[APER-1922]
We are converting the legacy UI of the `records` app in the Credentials IDA (credentials.edx.org/records/, credentials.edx.org/records/programs/{uuid}, etc.) to a new MFE. Today, the Program Dashboard and the legacy (non-MFE) profile page have buttons that route learners to the Credentials IDA pages. We need to (optionally) introduce a way to route learner's to the new MFE instead.
- Introduces a new configuration setting called `LEARNER_RECORD_MICROFRONTEND_URL` (defaulting to None). This will be used by the LMS to store the base URL of the new MFE (e.g. records.stage.edx.org).
- Introduces a new waffle switch named `USE_LEARNER_RECORD_MFE`. This will be used to control whether routing learner's to the new MFE is enabled from the LMS's side.
- Updates the existing `get_credentials_records_url` function to add additional logic that will determine if we need to build a link to the legacy FE or the new MFE
- Adds tests for new and existing behavior. There were no existing unit tests for the utility function that I updated.
This PR changes the default behaviour of the discussions experience by making the previous "unit-level
visibility" the default mechanism for configuring discussions.
Prior to this PR, under the new discussions configuration experience, all units would automatically get
assigned a discussion topic and have discussions enabled for them (other than units in graded or exam
subsections). However, if authors wanted they could enabled a custom visibility mode which would allow
toggling discussions on or off on a per-unit level.
This PR makes this custom visibility mode the standard behaviour (and eventually, only behaviour)
and enables discussion for all units by default. This replicates the behaviour that already existed,
however, now gives authors control over disabling discussions for individual units by default.
It also removes the ability to disable discussions for all units (while still keeping course-wide
discussions) enabled.
The current logic for showing discussion providers makes it hard to switch
from the legacy to the new provider. This commit changes the conditions in
which different providers are shown, and which provider is used as default.
Before this commit, the new provider would be hidden if the legacy provider
was in use and vice-versa. So both would only be shown if neither legacy
nor the new provider were in use (i.e. an LTI provider was in use).
Now, all providers are always displayed to global staff. If the waffle
flag for the new provider is set
(`discussions.enable_new_structure_discussions`), then new provider is
always displayed, and the legacy provider is hidden unless it's currently
in use.
If flag is not set, then the new provider is always hidden unless it is
used by a course.
Finally, the default provider now depends on the flag above. If it is
set globally, then the default provider is the new provider, otherwise
the legacy provider remains the default provider.
We already add the user id (imperfectly) to many requests.
However, when a user starts off unauthenticated, it is not
possible to correlate to those requests. Adding the raw
IP chain provides that possibility. See new custom attribute
ip_chain.raw.
The decision to provide Restricted Applications expired
JWTs was superseded by another ADR. This commit simply
adds clarity around that change.
Co-authored-by: Phillip Shiu <pshiu@users.noreply.github.com>
As part of dissolving our sub-projects in edx-platform, we are moving this package under the xmodule directory.
We have fixed all the occurences of import of this package and also fixed all documents related references.
This might break your platform if you have any reference of `import capa` or `from capa import` in your codebase or in any Xblock.
Ref: https://openedx.atlassian.net/browse/BOM-2582
