Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

(draft)

Status

IN DEVELOPMENT

Migrations

YES


Description

The impetus for this is to fix the broken integration with Badgr.io backends

Separate Open edX BadgeClass slug from backend Badge Class id 

The integration with Badgr on Badgr.io is now broken.  The API are in  It should still work with the open source version of badgr-server but Concentric Sky tells me that a new release of this is forthcoming in December 2017 and will bring the badgr-server API in line with the Badgr.io site.  (Badgr.io seems to have implemented some kind of "forwarding" from existing Badge Classes with old style slugs to the new slug.  A new API call to create a Badge Class for slug 'openedx__coursefoo' will not create a Badge Class addressable by that slug, but older Badge Classes will still be found by a GET to an old-style slug).  

The main issue is that Badgr.io will no longer accept a custom slug when creating a Badge Class through the API.  It now populates the AutoSlugField with a UUID-based slug.  The LMS badges app "slugifies" the BadgeClass Name and Issuing Component values and passes that to the Badgr API as the requested backend Badge Class slug, expecting that this will be a way to look up the slug in the backend.  This no longer works.  The API request, will, however, return the assigned Badgr slug and id (IRI) in the Response so we can store this value.

I'm proposing to decouple Open edX BadgeClass slugs and backend Badge Class ids.  In the case of Badgr, the backend identifier is a Django slug storing a UUID, but to support other backends, we should just call this an 'id'.    ('Slug' is not a part of the Open Badges spec—it only specifies that Badge Classes have an IRI id.)   It does still make sense to maintain a "human-friendly" Django slug for the BadgeClass object, to make it easier to reference using the Django admin, especially for creating course group event configurations.  

The backend implementation (Badgr only for now) should expect an API call for creation of a backend Badge Class to return the Id.  We can store this backend Id in a new field on Badge Class.  For the Badgr backend we will store the value of Badgr slug.  

(I think it should be possible to specify separate backends/issuers per BadgeClass, but this could be done in a future phase.  You could argue that the BadgeClass object should be completely independent of backend, but I'm not sure the complexity of storing a lookup from BadgeClass to backend in another persistent object is worthwhile overhead.  ).

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 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.

  1. 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.  
  2. 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

The Open edX badges app has the concept of Issuing Component.  This will no longer be part of a backend id, but is a potentially useful concept for distinguishing between course-scoped (Issuing Component="openedx__course") BadgeClasses and possible other scopes (e.g., Issuing Component="openedx__xseries").  A potential future Studio UI for Badge Class creation might support the automatic assignment of appropriate Issuing Component values. 

To encourage the use of Issuing Component as a useful cross-Issuer BadgeClass identifier, I propose to append its value to the 'tags' field value in the backend.  The Open Badges spec v 2.0 supports a tags field which is an array of text values.

Has edX proposed a broader list of possible Issuing Component values?  If so, what are the possible values?


## Related PRs


List related PRs:


| branch      | PR   |

| ----------- | ---- |

| repo/branch | link |

| repo/branch | link |



## Todos


Do you think edX will need to perform the following?


* [ X] Product manager review

* [ ] UX/UI review

* [ ] Accessibility review

* [ X] Technical design review

* [ X] Documentation review  - documentation of changes to Badging will be outside of the PR



## Steps to Test or Reproduce


Outline the steps to test or reproduce your results.



## Impacted Areas in Application


Badges app, student Accomplishments.


## Development and Design Notes


How do you plan on implementing this proposal?



## Deployment Notes


Deployment will involve a mandatory data migration.  Otherwise, 

  • No labels