This moves all course runs that use certificates over to V2 of course certificates, and disables the option for a course run to use V1 of course certificates.
MICROBA-1082
* feat: [BD-26] add the is_proctored value to SequenceMetadata API
* feat: add temporary flag for enabling/disabling proctored exams
* fix: change creation date
* fix: fix text indents
* fix: [BD-26] Remove redundant duplicated test.
Co-authored-by: Sagirov Eugeniy <sagirov19@gmail.com>
Co-authored-by: Igor Degtiarov <igor.degtiarov@raccoongang.com>
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).
- Remove the REDIRECT_TO_COURSEWARE_MICROFRONTEND waffle flag.
- Add a new COURSEWARE_USE_LEGACY_FRONTEND waffle flag that directs
all learners to the legacy courseware experience.
- Skip two failing a11y tests which fail due to the new default of
the courseware MFE.
TNL-8279
[MICROBA-678]
This patch will update the text on the course dashboard when a learner
successfully earns a certificate and that certificate is available. It
also adds to the Outline API for the Outline in the Learning MFE so that
the same changes can be made there.
Code in ./common/lib/xmodule/xmodule should
be imported as `from xmodule`, since `xmodule`
is a locally-installed package.
This is weird, but as long as it is the case,
we should be consistent.
(In BOM-2584, I propose moving the files to
./xmodule, which would quell this confusion.)
[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.
We had been pre-escaping display names like 'Math & Science' as
'Math & Science" in the REST API itself - which meant that
consumers like MFEs that do their own escaping displayed the wrong
thing.
It's better for the API to just leave the string as-is. As far as
I know, this only affects the gradebook and progress pages, both
of which do their own escaping of the result from the API already.
AA-808
The get_course_members API returns a dict of users associated with a course.
This is a potentially expensive operation on a large course, so there is a
control in place to limit its cost. If a course has more than
settings.COURSE_MEMBER_API_ENROLLMENT_LIMIT enrollments, then the function
raises an OverEnrollmentLimitException.
This API was added to help implement the LTI 1.3 Names and Roles Provisioning
service.
Jira references: [BD-24] [BB-2726] [TNL-7330]
Pull request: #25843
Co-authored-by: Giovanni Cimolin da Silva <giovannicimolin@gmail.com>
* Badgr integration fix
Badges are no longer created on the Badgr side with a given
'slug'. Instead, a slug(v1) or an entityId(v2) will be generated
for each badge on the Badgr side and we will need to use that
value to check if a certain badge matching a BadgeClass on our side
exists and/or to create assertions for it.
This commit introduces a new field to the badgeclass:
'badgr_server_slug' by cherry-picking the following commit from
3309aab2a2eb00d28c5ca3d3145c8dddb15e6159
- TTK-18543: fix Badgr Server
connection (https://github.com/teltek/edx-platform/pull/46)
This commit also modifies the cherry-picked commit by making the newly
added field optional since the BadgeClass is not neccessarily always used
with the Badgr backend.
Co-authored-by: mrey <mrey@teltek.es>
* Implement OAuth2 tokens flow for BadgrBackend
* Use Badgr v2 API
Co-authored-by: mrey <mrey@teltek.es>
[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
