[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.
We have had numerous support tickets/bugs related to special exams
not properly displaying completeness (see https://openedx.atlassian.net/browse/AA-773 for
details). Along with a corresponding edx-proctoring PR, this will now
submit completions for all completable children within a special
exam upon the exam being completed for the first time (as dictated by
the logic in the edx-proctoring PR).
[MICROBA-1012]
- update python files to reference the allowlist instead of whitelist
As part of the Certificates v2 work, and in an effort to make the codebase more inclusive, we are moving away from using the term "whitelist" in favor of "allowlist". This PR is part of our renaming efforts across the Certificates Django app, and other Django apps that make use of Certificates functionality.
[MICROBA-1075]
- Adds a new `edx.certificate.revoked` event to the LMS.
- Refactor of our certificate revocation functions in the GeneratedCertificate model.
This new event will be emit when a GeneratedCertificate with the status of `downloadable` is revoked (through the `invalidate(), mark_notpassing(), or mark_unverified() functions). Event will have a `source` field that will allow us how our certificates are being revoked from learners and can be broken down in the following way:
*Invalidate*
- allowlist_removal
- certificate_generation
- certificate_regeneration
- certificate_service
- certificate_invalidation_list
- bulk_certificate_regeneration
*mark_notpassing*
- certificate_generation
- notpassing_signal
*unverified*
- certificate_generation
[MICROBA-1209]
Part of the modulestore cleanup/removal in the certificates app. The function `list_with_level_from_course_overview` was temporary. Cleaning this up. Modifying the original `list_with_level` to accept a course-id/course-key as it doesn't actually need the entire course object.
* Update `list_with_level` function to accept a course run id/course-key
* Remove `list_with_level_from_course_key` function (and update any functions using it to use `list_with_level` again)
[MICROBA-1238]
* remove unused `course` argument from `generate_user_certificates` function in the certificates app
* remove unused `course` argument from `regenerate_user_certificates` functioni n the certificates app
* remove `course` argument if passed in edx-platform apps outside of the certificates app
[MICROBA-1178]
- remove modulestore usage in `generation_handler.py`
- add duplicate functions that utilize a CourseKey or CourseOverview to remove dependence on modulestore (this will be cleaned up (if possible) at a later part of this refactor)
- add python API function to `content`/`course_overview` app that will retrieve a single CourseOverview (rather than a serialized list of dicts of CourseOverview data)
This helper is used by the LMS, CMS, _and_ `openedx.core`,
so let's move it to `openedx.core` to reduce import complexity.
The following files no longer import from LMS:
- cms/djangoapps/contentstore/management/commands/edit_course_tabs.py
- lms/djangoapps/ccx/migrations/0006_set_display_name_as_override.py
- openedx/core/djangoapps/ccxcon/api.py
- openedx/core/djangoapps/verified_track_content/models.py
- openedx/features/course_experience/plugins.py
Note: The LTI XBlock has a dependency on this import path (!?);
a fix can be found here [1].
- [1] https://github.com/edx/xblock-lti-consumer/pull/154
We have been bucketing all users into the relative dates experiment
since May 18, 2020. We no longer need to keep this as an
ExperimentWaffleFlag and can convert to a CourseWaffleFlag (so it
continues to support exemptions).
A variety of updates were made to improve the toggle documentation:
* Added comments to help ensure that the waffle(), waffle_switches(),
waffle_flags() anti-pattern won't be contagious (copied).
* Some minor toggle_description updates.
* Removed empty toggle_target_removal_date annotations for
non-temporary toggles.
* Removed empty optional toggle_warnings annotations.
* Removed empty optional toggle_tickets annotations.
* Removed deprecated toggle_category, toggle_status,
and toggle_expiration_date annotations.
* Fixed some indents, use cases, and implementations.
ARCHBOM-1721
* MST-682 Add external_user_key to the student profile CSV
This is a request from some Masters school partners. They would like to download the student enrolled list with the Masters external_user_key data referenced. This way, the schools can properly match the students enrolled in the course with the students enrolled through Masters enrollment system
[MICROBA-1011]
- When creating bulk allowlist entries make the tool use the `is_on_allowlist` certificate API function over accessing the CertificateWhitelist model methods directly
- When creating bulk allowlist entries make the tool use the `create_or_update_allowlist_entry` certificate API function over using CertificateWhitelist model/Django ORM directly
[MICROBA-1025]
- Update management command to use the same logic that the Instructor Dashboard uses
- Fix bug in management command where processing stopped when encountering a user that did not exist
- Add more logging
- Add and update tests where needed
django-not-configured is an error raised by pylint (with
the pylint-django plugin) when it's not correctly configured.
We should not be applying lint amnesty for such a violation.
[MICROBA-1038]
- Today, we check if a learner is actively enrolled in a course-run before we add or remove them from the Instructor Dashboard allow list. We ran into an issue where we couldn't remove an entry from the list because the learner is no longer actively enrolled in the course-run. Update instructor dashboard logic to only check enrollment status when _adding_ a learner to the allow list.
[MICROBA-1024]
- Move some of the recently added logic from the instructor app to the certificates app
- Attempt to not use other certificate models directly in the code I am touching, moving this logic to certificates as well.
[MICROBA-908]
- When adding a learner to the allowlist we now check if they have an invalidated certificate on the blocklist
- Refactor some pieces of the Certificate Invalidation flow
- Make it so an error message is displayed when trying to add someone to CertificateInvalidation list if they already appear on the Allowlist
- Add support to pass back and display an error message to Instructor Dashboard UI if a learner already appears on the certificate invalidation list when attempting to create certificate exceptions in bulk
- Add python tests for backend changes
- Disable xss linting warnings in certificate_bulk_whitelist.js (checked with security group first)
