This changes the "Sign out" link on Studio to point to Studio's own logout
view, which clears the session and then redirects to LMS's logout page. The
LMS logout page then skips loading the Studio logout because it is seen in
the Referer header.
This change also brings Studio better into line with how other IDAs perform
their logouts.
Background:
After the rollout of Studio OAuth, logouts initiated on Studio failed to
actually log out Studio (but all other IDAs were logged out). This was
because the LMS logout view loads the logout pages of other IDAs but skips
any that is a *prefix* match on the Referer header, and browsers now often
send a truncated version of the Referer for privacy. Therefore, Studio was
always skipped when coming from Studio.
The fix is to make sure that Studio has already performed its logout by the
time the LMS logout page is loaded.
One wrinkle here is that the LMS logout view is activated by `/logout`, but
the correct logout view (provided by auth_backends) is activated by
`/logout/` -- with a trailing slash. This is fragile and unfortunate, but
can be cleaned up when we later remove other leftovers of Studio's previous
ability to handle logistration.
ref: ARCHBOM-1897
We use the `notify_credentials` management command to keep certificate-
related data in the LMS and Credentials service in sync. We can run it
with specific arguments (user_ids, course_keys, etc.) when we notice a
data discrepancy; and it is run regularly by a Jenkins job with the
`--auto` flag every ~4 hours to keep things up-to-date.
Because we probably never want to notify credentials of of ALL the
GeneratedCertificates, the celery task must be given some arguments
to filter down to the relevant certificates. Running the management
command with the `--auto` flag (as the Jenkins job does) adds
`start_date` and `end_date` arguments of 4 hours ago and now,
respectively.
The handle_notify_credentials celery task then takes those arguments and
looks for any GeneratedCertificates that have been modified within the
given time range by checking the GeneratedCertificate modified_date.
It will send the current data for those certificates to credentials.
However, we also want to notify credentials about certificates that have
an associated CertificateDateOverride that has changed within that time
range: added, updated, or deleted. But changes to a
CertificateDateOverride won’t affect the GeneratedCertificate’s modified
date, and therefore wouldn’t be included in the list of certs cent to
credentials.
This commit adds a check for changed CertificateDateOverrides and
includes their associated GeneratedCertificates in the list of certs. We
use the CertificateDateOverride’s history model for this check so that
we can include certificates whose override was deleted.
MICROBA-1489
Current State (before this commit):
Studio, as of today doesn't have a way to restrict a user to
create a course in a particular organization. What Studio
provides right now is a CourseCreator permission which gives
an Admin the power to grant a user the permission to create
a course.
For example: If the Admin has given a user Spiderman the
permission to create courses, Spiderman can now create courses
in any organization i.e Marvel as well as DC.
There is no way to restrict Spiderman from creating courses
under DC.
Purpose of this commit:
The changes done here gives Admin the ability to restrict a
user on an Organization level from creating courses via the
Course Creators section of the Studio Django administration
panel.
For example: Now, the Admin can give the user Spiderman the
privilege of creating courses only under Marvel organization.
The moment Spiderman tries to create a course under some
other organization(i.e DC), Studio will show an error message.
This change is available to all Studio instances that
enable the FEATURES['ENABLE_CREATOR_GROUP'] flag.
Regardless of the flag, it will not affect any instances that choose
not to use it.
BB-3622
Currently, if a learner manually loads a sequence page that would
normally be skipped for them because it is hidden-after-due, the
sequence renders anyway.
This commit tells the frontend when it should not show a sequence
because it's hidden.
AA-1000
original behavior does pass the empty name through to
_update_full_name rather than just considering that as full name not
set. That's a little weird but outside the scope of this work so I've
preserved it by checking is not None rather than just using full_name
as a boolean.
MST-1015
BREAKING CHANGES:
- `CORS_ORIGIN_WHITELIST` now requires URI schemes.
- Added new list `CORS_ORIGIN_WHITELIST_WITH_SCHEME` which contains all links of `CORS_ORIGIN_WHITELIST` with schemes and load the desired list after checking installed version.
- For more details, visit this: https://github.com/adamchainz/django-cors-headers/blob/main/HISTORY.rst#320-2019-11-15
Reverting because of errors seen in proctoring. The error from splunk:
File "/edx/app/edxapp/venvs/edxapp/lib/python3.8/site-packages/edx_proctoring/views.py", line 590, in get
data['onboarding_release_date'] = effective_start.isoformat()
AttributeError: 'NoneType' object has no attribute 'isoformat'
The effective date is coming from learning_sequences, which ultimately
comes from edx-when.
created CustomPagesCourseApp class
feat: created custom pages course app plugin
created CustomPagesCourseApp class
added CUSTOM_PAGES_HELP_URL to lms and cms settings
added entry point to setup.py
feat: added toggle to ENABLE_CUSTOM_PAGES in lms and cms settings
feat: removed the option to enable/disable the availability of custom pages course apps.
* feat!: Add data model for course app API
The current course apps API makes individual queries to determine if a course app is enabled, which can be inefficient. With this change we now have a Django model that contains this information, allowing us to make bulk queries about all the course apps for a course in the API.
It also adds a new signal handler that initialises the status of all course apps in a course on course publish.
* Use celery tasks and a management commands to make cache async
* Review feedback
* update log messages
use separate celery task for each course task
The new filter, called `permissions`, allows callers to filter courses
per access granted to the specified username. Callers can now filter
courses per roles, actions, etc.
