The learning_sequences.use_for_outlines flag was recently added,
intended to serve the same purpose
as courseware.use_learning_seuqences_api. We do not need
both flags.
Furthermore, exposing either flag in the Courseware
Metadata API is neither necessary nor helpful, since
the easiest and quickest way for the Learning MFE to see
if the Learning Sequences API is enabled is to hit it,
and fall back to a different API if a 403 is returned.
This reverts commit 78f1e2b3bd.
TNL-8330
[MICROBA-1298]
* Remove a Segment certificate event that was, historically, only emit from the courseware.
The Segment event that was previously (only) issued in the courseware doesn't seem to be important or referenced anywhere we could see. Since this event only tracked certificate generation attempts from one (of multiple) paths to initiate certificate generation in v1, I didn't think the historical event data captured is complete. We approached our data teams and I determined this event was not of high importance. For this reason, I am suggesting we just stop using this event and remove the code responsible for sending it.
We will continue to track certificate creation/generation using the existing `edx.certificate.created` event.
Previously, it would 404. While accurate, it's not a great user
experience. Users can be offered invalid jump_to paths in the normal
course of things, if course content disappears or they lose access
to it.
In both cases, they might be offered a resume URL in the courseware
that would be to a now-invalid location.
With this change, that invalid link will at least give them
*something* (the first unit in the course) rather than an error
page.
This also (unrelatedly) fixes an exception when the learning MFE
outline page tries to render a course that contains sequences
with no children.
AA-867
[MICROBA-1307]
Before this change a user would not be auto refunded if they had a
certificate in a course with any status. This had unintended
consequences. This change updates the logic to only block auto refund
for statuses that we do not want to refund on such as downloadable.
Add a Waffle Flag. When enabled, the courseware pages of the
Learning MFE should use the Learning Sequences HTTP API instead
of the Course Blocks HTTP API in order to load course structure
data. We expect that this switchover will lead to performance
improvements and a more comprehensible system.
(We are putting the switchover behind a temporary flag in order to
enable debugging, incremental rollout, and comparison testing.)
The flag is exposed to the MFE via the Course API.
As of this commit, the new flag is not enabled in any environment,
and the MFE does not have any code to act on the flag's value.
So, this commit on its own should have no production impact.
TNL-8330
This is technically a revert of a revert that also includes some new
logic. The original PR was https://github.com/edx/edx-platform/pull/27770
and the revert PR was https://github.com/edx/edx-platform/pull/27973.
The new logic is to mock a request and create a module with user state
taken into account. We also put this into a celery task to help avoid
any potential concerns with recursing through children.
* feat: Course Apps API
This adds a new concept called course apps. These are exposed via a new
"openedx.course_app" entrypoint, which helps the LMS and studio discover such
apps and list them in a new rest api for the same.
These course apps will drive the pages and resources view in the course authoring
MFE. This system will track which apps are enabled and which are disabled. It
also allows third-party apps to be listed here by using the plugin entrypoint.
* Apply feedback from review
In order to allow the learning MFE's progress tab to show a
different UX for FBE exceptions (where some exams can still be
completed by audit learners), this commit adds access information
to each exam.
AA-829
[MICROBA-1179]
- Continue renaming/removal of code referring to the Certificate "white list".
The Certificates Django app `CertificateWhitelist` model is going away in an effort to make our codebase more inclusive. It is being replaced
with the `CertificateAllowlist` model. This PR continues to replace references to the Certificate "whitelist" with "allowlist" wherever
possible. There should be no change in functionality, nor are there any changes in appearance.
This PR changes the preview URL redirect from Studio. Before when a user clicked on the course preview button to check unpublished changes, the preview in the New Experience would show the most recently published version of the course. The unpublished changes that the user was hoping to view are no present. At the moment users have been publishing the content to check it then having to republish the old version if they did not like the changes. As a short-term fix, this PR redirects to the Legacy experience where the preview option previously worked. Now the user can see the unpublished changes. A long-term fix is still being explored. This change will impact the Course Author.
A common usage pattern is to make an exam that is restricted to a
particular enrollment track. Since there is no UI in Studio to do this
at the sequence/subsection level, course authors instead restrict every
unit in the sequence to that track (e.g. "verified"). The legacy
courseware experience could handle this, but the Course Blocks API does
not. It is likely that we'll want to permit toggling this at the
sequence level, but regardless of whether we do that going forward, we
still have to deal with this kind of content data in existing courses.
An entirely empty sequence is useless, and currently breaks the
Courseware MFE browsing experience. This commit introduces the first
part of that fix, invoking the new Learning Sequences API to remove
sequences that the user shouldn't be allowed to know about. The plan is
to switch over the entire course outline from the Course Blocks API to
the Learning Sequences API, and this is the first small step in that
direction.
This also creates CourseWaffleFlag learning_sequences.use_for_outlines
to control the gradual rollout of this feature. This will start as a
very limited rollout to address courses that show this specific bug
(TNL-8377).
New learning_sequences public API call: public_api_available
* fix: fixed atmoic block error in course_status_info
We are getting "An error occurred in the current transaction. You cant execute queries until the end of the atomic block."
error in get course status info on both versions i.e. 0.5 and 1. I was unable to reproduce it locally. But by looking
in django documentation and some other online helps I concluded that it might be because of some db intefrity error
that we didnt handle properly and now the cursor is broken for this transaction. Therefore i am making it non atomic
transaction. Since its a get request we can make transactions run independentantly.
LEARNER-8267
There are two distinct ways to store a city for users in edx-platform:
one directly in UserProfile.city, and another in UserProfile.meta.
Depending on configuration, both fields can be used. Though the
UserProfile.meta['city'] field is not set unless specifically configured,
so we choose this over the UserProfile.city field when generating the student
features report.
Additional details and discussion available on edx/edx-platform#23171
