Normally, the course API would return an access error_code of
`course_not_started` if the course has not started yet. This change
breaks that up into two codes:
* if the course has not started:
* return error_code=`course_not_started_enterprise_learner` if the
learner is enrolled as a subsidized enterprise learner.
* else, return error_code=`course_not_started`.
This supports a change to the frontend which will interpret
`course_not_started_enterprise_learner` differently and trigger a
redirect to the enterprise (B2B) learner dashboard instead of the B2C
dashboard.
ENT-8078
Datadog was removed 6+ years ago but some settings and related keys got
left behind. Get rid of them since we don't need them and also to
prevent people from assuming it's okay to hardcode datadog settings into
our codebase.
With this change, the platform users who access content via LTI will be
automatically linked to their platform account instead of the new (anonymous)
one. The following conditions need to be met:
* The `LtiConsumer` should be configured to auto-link the users via email.
* The LTI Consumer should share the user's email using the
`lis_person_contact_email_primary` parameter in the LTI Launch POST data.
This also replaces the one-to-one relationship of the `User` and `LtiUser`
with one-to-many. This way, multiple `LtiUser` objects can refer to the same
`edx_user`. With the auto-linking, multiple LTI Consumers can create
independent `LtiUser` objects with the same `edx_user`.
Co-authored-by: Piotr Surowiec <piotr@surowiec.it>
This flag was introduced to gate the rollout of moving the UI component for proctoring settings into the pages and resources view and was never cleaned up. At this point we should always be linking the the new page for proctoring settings.
When including `JwtAuthentication`, the auth_header becomes `JWT
realm="api"`. Without it, it is `None`. This changes the behavior of the
code in DRF and returns a slightly different auth response.
Relevant Code: 56946fac8f/rest_framework/views.py (L456C3-L456C3)
Learners want to have the usual course navigation when viewing a wiki,
so that they can go back to the course related to the wiki and browse
other tabs/sections of the course.
Wiki reads the course from the `request.course`. If it's not present,
i.e. None or not set on the request, it will not show the course
navigation UI.
It seems like `WikiAccessMiddleware` already has the code that parses
course id from the request (when the request is for a wiki view) and
sets the course for the request. However, it doesn't work in most
scenarios, because the course id is not in the it's normal format in
most requests that go to wiki.
For example, when a leaner clicks on a wiki tab from the course
overview, they are redirected to `/wiki/<wiki_slug>/` path. The wiki
slug is taken from course's `wiki_slug` field. This slug can be used to
figure out what course this wiki belongs to in most (not all) cases.
This commit adds code to the `WikiAccessMiddleware` that attempts to
find a course based on wiki slug, and in case of success, sets the
course to the `request.course`, so that wiki can display course
navigation UI.
