Resources
...
For the first phase which is planned to release by the end of december 2015 due to restriction of time and extra effort required to deploy start of January 2016 we will be deploying credentials service an independently-deployable web application (IDA) we will be releasing credential as a self-contained and isolated lms app (openedx.core.djangoapps.credentials_service) with django admin for programs credentials authoring, an endpoint to support credentials generation and an an an endpoint to get learner credentials so in first phase the most of the credentials API will be used internally (not exposed to public). So in second phase we will export this app 'credentials_service' and deploy it as a separate IDA and have its API's exposed to public along with permissions..
Purpose
The purpose of this service is to continue awarding course certificates as we do today, and add support for issuing program (XSeries) certificates.
Milestones/Phases
New Credentials Service (LMS) Service as an IDA with Programs/XSeries Certificates generation/retrieval and authoring/administering through default django admin.
Deploy Credentials Service as an IDA and Support Courses & Programs/XSeries Credentials Authoring in Studio (through new credentials service). Make a django app 'credentials_adapter' for supporting both certificates and credentials systems for course certificates.
Migration of existing courses web and PDF certificates for certificates to credentials.
- Whitelisting / Credentials Instructor tools. Show all received certificates (for courses and XSeries) for a learner.
...
Continue support for awarding honor/verified/professional course certificates.
Continue support for allowing recipients to share achievements via social media (LinkedIn, Facebook, Twitter).
Add support for awarding programs (XSeries) certificates.
Migrate existing web and PDF certificates to any new system.
Preserve existing PDFs in S3.
Update dashboard links to point to web certificates, instead of directly to S3.
Add support for external verification of web certificates via verify.edx.org (SOL-1335, SOL-1298)
New system must support multi-tenancy—partitioning credentials by site/microsite (use django sites framework).
...
Every certificate has a template representing the rendered (HTML+CSS) certificate. Most certificates will use the same template—signatures, organization logo, course name—with variations for mode 'certificate_type' (e.g. honor, verified, professional). There is a case where the certificate templates can include other assets. Hence the 'CertificateTemplateAsset model', responsible for tracking assets for these special cases. Also for now certificates uses organization app for creating a template against a particular organization or related to one of its specific modes e.g. 'honor', 'verified' etc. This current feature allows instructor/admins to set an explicit template for the certificate at various level of depth. specific course mode override, course override, org override. then the base templates. This template override functionality will also carried over to the credentials.
The UserCredential model tracks which users have been awarded credentials. Only two statuses are supported at this time: 'awarded' and 'revoked'. To save the extra attributes e.g. 'grade' and 'whitelist' we have have a generic model 'UserCredentialAttribute'. For specificity of course related attributes we will use the prefix 'course' for the field 'namespace' e.g. 'course.grade'. The 'download_url' field will be used to distinguish between the course web certificates and course pdf certificates. This field will have the link for the PDF e.g. ff the UUID is 'abc123', the download URL should simply be 'https://<S3-HOST>/<UUID>/certificate.pdf'.
...
For integration we will have a simple django app "credentials" (openedx.core.djangoapps) which will serve to toggle credentials related functionality for both LMS and Studio and communicate with credentials service. This app will also be responsible for creating async credential task (celery task) for grading (checking eligibility) and sending request to credentials service in case of generating credentials for a course. In case of programs we don't need to check eligibility since programs service will use credentials endpoint with only eligible users. Also this app will expose an API (for usage by the "credentials_service") to provide necessary data related to user, course/program (their relation with the organization in case of a course).
For first phase we will have an other django app a separate IDA "credentials_service" (openedx.core.djangoapps) which will have all the core functionality for credentials and in late phase it will be moved to a separate IDA.
We will have another simple django app "credentials_adapter" (opened.core.djangoapps) which will have same view as certificates (this is to support both certificates and credentials during migration). The purpose of this app would be to chose between certificates or credentials system for underlying functionalities for course certificates since we will have web certificates courses in current certificates system too also we will have to support PDF certificates (deprecated).
...
Credentials program admin flow
Credentials course admin flow
...
For first phase this is not necessary because the new system will only handle the programs (xseries) credentials. Our current models can support almost all existing use cases.In second phase we will be migrating the credentials service to an IDA and since at that point we will have just the programs credentials so it will be less overhead (Reason for now moving to IDA in first phase: overhead of work with the devops and making all infrastructure in place to start communication between IDA and edx-platform will take time and also we have a deadline.). Once the migration is completed then we can use edx-rest-api-client to start communicating credentials IDA.
In next step we have to migrate the existing course certificates data to the new credentials system too. So until we have migrated all data from existing course certificates models to new credential service we will have a credentials adapter wrapper "credentials_adapter" in place which will check if that course has certs configuration in old certificates system or in new credentials system. So if a course related certs configuration is in old system then credentials adapter service will keep serving the certificates from old system and once a course related certs a migrated to new credentials system then credentials adapter can start serving that course certs from new credentials system. This credentials adapter will increase some overhead but this way we can avoid any downtime until we have migrated all course certificates data to new credentials system.
...
Product question: Currently the signatory, course override title and basic configuration are saved inside the course (mongo modulestore) so that’s way they are also part of the course import export. Do we need this functionality for new credentials system? If that’s the case then do we have the re-run scenario for programs?
Ans: This is being discussed on the credentials google docs.
...
Some basic analytics related to course certificates for migration point of view.
Web Certificates:
Total courses | Total cert issued | Min cert count | Max cert count | Avg cert count |
171 | 60599 | 1 | 4839 | 354 |
...