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
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
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
- Remove the REDIRECT_TO_COURSEWARE_MICROFRONTEND waffle flag.
- Add a new COURSEWARE_USE_LEGACY_FRONTEND waffle flag that directs
all learners to the legacy courseware experience.
- Skip two failing a11y tests which fail due to the new default of
the courseware MFE.
TNL-8279
[MICROBA-678]
This patch will update the text on the course dashboard when a learner
successfully earns a certificate and that certificate is available. It
also adds to the Outline API for the Outline in the Learning MFE so that
the same changes can be made there.
[MICROBA-678]
Added cert availability date to the API used to get certificate status
by the learning MFE to support updated messaging.
Updated the cert availability messaging in the Coruse Dashboard,
including a text color change.
The /jump_to/ LMS endpoint is used in a number of places
to direct users to courseware. It currently only redirects to
Legacy courseware URLs, which then conditionally may
redirect to the Learning MFE.
Two issues with this:
1. Performance Impact: In most cases, going to Legacy first
is just an extra redirect.
2. Confusion for Privileged Users: Neither course nor global
staff are auto-redirected from the Legacy experience to the
MFE. Thus, these priviliged users confusingly never see the
MFE by default; they must always manually click into it.
This commit makes it so that /jump_to/ directs
users to whatever the default courseware experience is
for them. For staff of courses active in the new experience,
this will impact (at a minimum) the "View Live"
links in Studio, all links on the old and new LMS
course outline, and the "Resume" links on the course
dashboard. Learners should see no difference other than
a performance improvement when following courseware links
from the LMS.
This also adds an optional 'experience=[legacy|new]'
query param to /jump_to/, allowing us to specifically
generate Legacy courseware URLs for the
"View in Legacy Experience" tool.
TNL-7796
Exposed the Date header on the outline api so clients can accurately compute times relative to the dates returned by the API; this was previously done with the course API (#26979)
Browser time is notoriously unreliable for this, especially for a Learner-facing countdown call-to-action based on the access expiration date. (REV-2126)
Using the Date header for this allows the client to make use of information that is already sent, does not require additional calls nor modifying the API, and could be generalized to more or all our APIs without modifying them.
In preparation for switching LMS/Studio over
from serving legacy courseware URLs in certain
places (for example, resume_course_url) to serving
learning micro-frontend URLs.
TNL-7796
This feature uses the first_day_of_streak, last_day_of_streak and last_streak_celebration fields to determine whether the user should see a celebration.
AA-304
