...
We will need to implement a data migration for existing BadgeClass objects to populate the new backend id field since the slug field is no longer a reliable future-proof identifier. The migration will involve a call to the backend API.
Change how course completion badges are found
Currently, when a user is granted a certificate, a course complete badges is looked up by querying by a slug that must be in a very specific format derived from a hash of the course key and mode. If a user tries to set up a BadgeClass manually via the Django Admin and picks a common sense slug, course completion badge awarding will fail. The only way a Badge Class would be created with a slug in that format currently needed is if it is automatically created after a certificate event, in which case the Badge image must used will be a generic image for an enrollment mode. Most users outside of edX will wish to manually create their Badge Classes and use their own badge image specific to a course or educational goal. Many will wish to first create a Badge Class in the backend first, then copy over the details to the LMS Django admin.
I propose several things to address these use cases and the current problems.
- Currently, BadgeClass objects are unique by combination of course id, issuing component, and slug. Instead I propose that a slug should be continue to be unique on its own, and that one BadgeClass per combination of course id and course mode should be allowed. It makes sense Course A could have a separate badge for honor students and verified students. Or, with a blank mode field, all Course A certificate earners should be awarded the same badge.
...
- When a certificate is awarded for a course, the matching BadgeClass should be found by the course id combined with the student's enrollment mode
...
- . Slug would not be used as a lookup unless passed explicitly.
Change how course group, completion, and enrollment badges are found
Currently, lookups to the course group, courses completed and enrollment configuration objects are filtered on Issuing Component = 'openedx__course'. I'm not sure that's necessary. With my proposed changes, a Badge Class slug will be unique and can be used as the key for which slug to award. Requiring a specific Issuing Component value is redundant in terms of ensuring uniqueness.
Use AutoSlugField (will require adding this package as a requirement) to auto-generate
Store Issuing Component as tag on backend Badge Class
...