Course topics are now created by traversing the entire course structure from top to bottom instead of starting at the sequential level and then moving up or down as needed.
This also introduces a lot of debug logs to pontetially find the reason why under some circumstances new units don't get processed and end up without a discussions topic.
These changes should improve the performance caused by the file I/O
when it's running in docker, using lru_cache to save thousands of calls to listdir
when running with a handful of themes defined in COMPREHENSIVE_THEME_DIRS.
[APER-1941]
We are aware of a product issue that causes a `certificate_available_date` (CAD) to be set for self-paced courses (and thus copied to the course-run's (course) certificate configuration) that causes an issue with learners' Program Records to be inaccurate. The stored CAD in Credentials is causing these certificates to be marked as "unearned" on the Program Record in Credentials, as the IDA believes the learner should *not* have access to them yet (but these certificates are available in the LMS).
A management command was recently introduced in Studio that can be used to clean/remove the `certificate_available_date` data from a course-run in Mongo. These updates aren't making it to the Credentials IDA because of an issue with our logic in the `update_certificate_visible_date_on_course_update` Celery task. This task assumes that we only want to send updates for *Instructor-Paced* courses that have a Certificate Display Behavior set to `end_with_date`. In reality, we need updates to pass to Credentials for _some_ self-paced courses with bad data.
This PR hopes to update our infrastructure to allow these updates to flow to Credentials.
* Improve logging for failed requests to the Credentials IDA's `course_certificates` endpoint when updating a course certificate configuration.
* Update docstrings and comments where appropriate
* Split the logic of the update_certificate_visible_date_on_course_update task into two tasks. The former task will continue to _just_ handle visible_date attribute updates. The latter (new) task will be dedicated to making the REST API call that updates the `certificate_available_date` data in Credentials.
* Update the `handle_course_cert_date_change` function wqhen the COURSE_CERT_DATE_CHANGE signal is received to queue both the "visible_date" and "certificate available date" Celery tasks.
* Update existing tests for the task changes.
This commit attempts to fix cases where dicussion topic links aren't created
during a provider change.
It does so by eliminating areas where there could be desynchronisation between
the configuration the course configuration in Mogo and the discussion config
in MySQL.
The topic creation code now uses the database version of the config which is
more recent.
This attribute is already deprecated for XBlocks in favour of directly
retrieving it like `block.scope_ids.usage_id.context_key`.
This commit also removes some redundant logging code which was omitted in the
Datadog removal in #19420.
This argument was officially used only by the ProblemBlock.
If you need to get the base URL for static assets in your XBlock, please use
`settings.STATIC_URL` directly, instead of `runtime.STATIC_URL`.
The IP chain code has moved to edx-django-utils—except for the legacy-IP code,
which is now in a new module. This will allow other IDAs to use the IP code.
Commit includes some adjustments to the toggle annotation.
Part of <https://github.com/openedx/edx-django-utils/issues/241>.
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.
