This adds a toggle to allow operators to prevent user registration and login via username/password authentication, forcing the platform to only support login and registration using third-party auth such as SAML.
Co-authored-by: Umar Asghar <mrumarasghar@gmail.com>
When determining completion status to show on the vertical, we take
into account if the problems are graded and scored (have a score
and weight). Now we take that into account in regards to showing the
banner inside the vertical too
The learner records feature had to be enabled/disabled via site-specific
configuration models, which is inconvenient for platforms that want to
disable this feature globally. Here, we introduce a
ENABLE_LEARNER_RECORDS feature toggle in the lms/cms settings that makes
it possible to disable this feature on all sites. Because this feature
toggle is set to True by default, this will not modify the behaviour of
existing platforms.
The change to masquerade in the courseware view allows the proper
viewing of the xblock from the perspective of the masqueraded user.
In this case, it allows a staff user masquerading as a learner to see
their shift dates calls to action inside the MFE (the old view already
had this set up). The second change allows the staff user masquerading
to reset the schedule of the learner being masqueraded via the CTAs
As part of AA-500, we added a completeness check to showing the
banner since we didn't before. As part of AA-260, we now take into
account if a learner has more attempts left on a problem (regardless
of completeness) and allow them to shift their dates to try again.
Specifically, send data versions of course_expired_message and
offer_html.
The rendered HTML is still being sent for now, until the learning
MFE is updated to consume the data objects.
Replaces the deprecated CachedFilesMixin with ManifestFilesMixin.
Also sorts xmodules and xblocks js bundles to make theme assets
compilation hashes consistent across different machines.
This should prevent the issues we've seen recently where cms modules are
imported by the running lms process, resulting in two celery instances
being created and tasks intermittently being registered to the wrong
instance (and therefore effectively lost.)
In commit ab6bf348d4/PR #25822 we tried to ensure that only one or the
other of the instances was created by adding a startup check.
Unfortunately, there's an external shared library that refers directly
to the lms celery, causing a startup failure in cms, so we had to revert
it. Rather than waiting to fix that library, this commit collapses
the two instances together so that there is only ever one.
