- Add bootstrap utility function to lms-base-v1 CSS
- Moved coaching sass to edx.org theme
- Banner feature flag and MB program gated
- Fixes previous issue of changes specificity in button selector by
resetting the style inside the component's class
Previously code was only showing banner for enterprise
learners. This patch would remove this restriction
and is available to all edX learners provided that
'enable_secondary_email_feature' is switched on.
PROD-1477
Instead of requiring views like the dashboard to know about plugins so
they can include their data in the context, this allows plugins to
define a mapping between a view and a function where the function
returns a dictionary of new context for the view. Each view would have
to purposefully enable this additional context before it could be used.
This will allow new content to be added to the pages without updating
the core with a combination of a plugin to add new context, and a theme
override of that page to use the new context.
Moves the existence check for secondary (recovery) email to validate
method. If the email already exists, silently remove it from the set of
data to be updated. This parallels the existing behavior for updating
the primary email.
ENT-1913
Rather than to create or update the account recovery record when the
Account Settings page is updated, defer updating until the new
recovery email is confirmed
ENT-2607
This completes the work started in https://github.com/edx/edx-platform/pull/19453
to use the LMS login and registration for Studio, rather than Studio
providing its own implementation.
LMS login/registration are being used for the following reasons:
1. LMS logistration properly handles all SSO integrations.
2. A single logistration is simpler to maintain and understand.
3. Allows Studio to work more like all other IDAs that use LMS
logistration.
The original switch to use LMS logistration for Studio also added the
toggle `DISABLE_STUDIO_SSO_OVER_LMS` to provide the community some
additional time for switching. This commit removes this toggle, which
at this point means all deployments will use the LMS logistration.
This change requires sharing cookies across LMS and Studio. Should that
prove to be a problem for certain Open edX instances, there are
discussions of possible alternative solutions.
See https://github.com/edx/edx-platform/pull/19845#issuecomment-559154256
Detailed changes:
* Fix some Studio links that still went to old Studio signin and signup.
* Remove DISABLE_STUDIO_SSO_OVER_LMS feature toggle.
* Remove old studio signin and signup pages and templates.
* Fix url name "login", which had different meanings for Studio and LMS.
* Use the following settings: LOGIN_URL, FRONTEND_LOGIN_URL,
FRONTEND_LOGOUT_URL, and FRONTEND_REGISTER_URL.
* Redirect /signin and /signup to the LMS logistration.
* Add custom metric `uses_pattern_library`.
* Add custom metric `student_activate_account`.
* Add Django Settings to allow /signin, /signup, and /login_post to be
disabled once ready.
This work also relates to ARCH-218 and DEPR-6.
ARCH-1253
Learners are not allowed to make an attempt of the procotored exam if
they verify their identity near to proctored exam date.To make them,
aware about their expiry date, modification are done to the status card
so that user experience will be improved.
PROD-769
The enrollmentStatusHash cookie value was created in commit f0030334
as an optimization, in order to determine whether the marketing site
needs to refresh the list of a student's enrolled courses with a
call to the LMS. To ensure that this value was kept up to date,
commit d7a7bcc1 reset the user's cookies every time they go to the
learner dashboard page (which used to be the next page loaded after
you enrolled in a course). This didn't just reset the
enrollmentStatusHash though -- it recalculated all the cookie
values, as if you had just logged in.
A number of things have changed since then:
1. Enrolling in a course now goes to that course's info/navigation
page, rather than going to the student dashboard.
2. It doesn't appear that the value of enrollmentStatusHash is
actually being examined anywhere -- it's set in a cookie on the
LMS and read/written by the edX marketing front end code, but
the value is never looked at to make any decisions.
3. The introduction of add_email_marketing_cookies (which triggers
off of the CREATE_LOGON_COOKIE signal) has made cookie resets
far more expensive, as there is a blocking call to Sailthru if
you have that enabled in EmailMarketingConfiguration (which
edx.org does). This can add over two seconds to the server
processing time for the student dashboard at certain times of
day.
Given this, I'm removing both the call to resetting the cookie on
the student dashboard page, as well as setting the value for
enrollmentStatusHash.
