When signing in from the LMS, the authentication request succeeds but
the user was never redirected to the dashboard. This is because of a
js error:
Uncaught TypeError: userCookie is null
userFromEdxUserCookie
http://maple.openedx.overhang.io:8000/static/js/student_account/utils.js:32
The error comes from the fact that the util.js code ignores the
EDXAPP_EDXMKTG_USER_INFO_COOKIE_NAME setting name. Instead the cookie
name is abritrarily prefixed by "stage-" or "prod-" depending on the
hostname. This seems to be primarily motivated by the definition of
edX.org staging/prod environment hostnames :-(
To resolve this issue, we decided that the actual cookie name was not so
important. Instead, the js code needs to not crash even when the cookie
is absent.
This issue was first reported here:
https://github.com/edx/edx-platform/pull/28170#issuecomment-890449885
Close https://github.com/openedx/build-test-release-wg/issues/104
Adds a check to make the UX in compliant with Coppa suggestions.
After this change only users older than 13 years are able to
cascade between their limited and full profile.
Fixes: VAN-753
This is really just the change to use the unicode copyright symbol
and then rerunning the pull translations logic (minus the transifex step)
to update the eo files. The other changes were just picked up as part of
running those scripts
We add 'courserun_key' (aka "course_id" though that's technically a
misnomer) as an optional parameter to the /event endpoint url. If it
is not present, it will still be parsed out of the url, if the url is
of the right format.
Additionally, Logger.log() in js adds this parameter to its /event
call, pulling it from the $$course_id global.
This provides opportunity for MFEs to (separately) provide the key
without concern about url parsing.
TNL-7752
[MICROBA-678]
When a certificate is in an unexpected state (i.e. notpassing with a
passing grade) this alert will allow the user to attempt to resolve the
issue on their own. It will run the code that checks the certificates
status. It requires that the course is configured to allow users to
Request Certificates though.
[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.
Not using `settings.PLATFORM_NAME` because sharing it with this script would need too much platform changes for this small error.
Removing the word "edX" makes the statement more accurate for other forks. Generally there shouldn't be any mention of "edX" in the code.
This change causes the activation link that’s emailed to a newly-registered user
to utilize a next query parameter. The impetus for this change is an edX Enterprise use-case:
we'd like newly registered Enterprise Customer admins and learners
to be directed to the Enterprise Learner Portal (or Admin Portal) upon account activation.
This is likely a broad enough use case to be valuable in other endeavors.
Previously the programs dashboard picked the first course run enrollment
for a course to display on the dash if the user had multiple. Now it has
a preference for the enrolled course run that earned a certificate if
there is one.
Facebook requires a callback when using the `.ui()` method now. I don't
know when this changed, but the share button is currently broken on
course certificates.
Facebook documentation of the `.ui()` method:
https://developers.facebook.com/docs/javascript/reference/FB.ui/
