Add Program Certificate events

[justinhynes]

Hey folks! I'd like to propose some new events related to Program certificate generation and revocation. Program certificates are generated and maintained by the Credentials IDA.

Internally at 2U, we have external services that are interested in knowing when a program certificate is awarded to a learner. We don't have an immediate use case for a revocation event, but It would feel incomplete (at the time of writing this issue) to only add an event for awarding a program cert. This seemed general enough that others in the community may care about these types of events and that it would be useful to have as part of the openedx-events ecosystem.

I had rejected the idea of trying to reuse the existing CERTIFICATE_CREATED and CERTIFICATE_REVOKED events as the event data today is closely coupled to course certificates. I thought that trying to make the existing event work for both course and program certificates could be potentially confusing, thus having dedicated events for the lifecycle of program certificates made more sense.

With this in mind, I propose:

• A new PROGRAM_CERTIFICATE_AWARDED event
• A new PROGRAM_CERTIFICATE_REVOKED event

These new events would be part of the learning architecture subdomain but would have their own dedicated topic.

Example definition for the PROGRAM_CERTIFICATE_AWARDED event:

Description: Emit when a program certificate is awarded to a learner
Type: org.openedx.learning.program.certificate.awarded.v1
Name: PROGRAM_CERTIFICATE_AWARDED
Data: ProgramCertificateData

Example definition for the PROGRAM_CERTIFICATE_REVOKED event:

Description: Emit when a program certificate is revoked from a learner
Type: org.openedx.learning.program.certificate.revoked.v1
Name: PROGRAM_CERTIFICATE_REVOKED
Data: ProgramCertificateData

These events would require two new data classes:

class ProgramData:
    uuid [type str]
    title [type str]
    type [type str] (this is the program type/slug -- microbachelors, micromasters, professional, etc.)

class ProgramCertificateData:
    user [type UserData]
    program [type ProgramData]
    uuid [type str]
    certificate_available_date [type datetime, default None] (yagni?)
    status [type str]
    url [type str, default None?] (functional link to the program cert)

The UserData class already exists and would be reused to capture PII and non-PII data about the learner.

An example of the event data for a PROGRAM_CERTIFICATE_AWARDED event would be:

{
  "program_certificate": {
    "user": {
      "id": 0123456789,
      "is_active": true,
      "pii": {
        "username": "jdoe12345",
        "email": "jdoe@email.com",
        "name": "John Doe"
      }
    },
    "program": {
      "uuid": "fc8bd2c6-2043-4888-93a4-9e02033f4467",
      "title": "History of Cats",
      "type": "microbachelors",
    },
    "uuid": "bb5e395f-b630-4862-b57c-96b3bfdebe5a",
    "certificate_available_date": "2023-07-19 13:45:47.542770",
    "status": "awarded",
    "url": "https://credentials.blah.something/credentials/bb5e395fb6304862b57c96b3bfdebe5a/",
  }
}

Thanks for any thoughts and considerations on the topic!

[justinhynes]

Based on a conversation in the Open edX Slack, I thought I would add a comment on how I see the events being used once implemented.

These events would be produced by the Credentials IDA. I am hoping to see the certificates functionality extracted from the LMS to Credentials and I (personally) don't want to add any new certificate clutter/features/functionality to the monolith.

[robrap]

Thanks @justinhynes. I'm going to use this ticket (for now) to discuss whether the new events should go on a separate topic or not.

The outdated best practice used to be one event type per topic. We opened https://github.com/openedx/openedx-events/issues/78 to discuss, and ultimately implement the ability to write multiple event types to the same topic for the purpose of ordering, because they were working on a single object.

Here we are proposing additional event types for program certificates where order matters for a given program cert, but probably not against the other certs. Additionally, these events are being produced from a different service, so I think we'd probably want a separate program-cert related topic.

We can see what others think, and then maybe we can add some clarity to our docs on when to reuse and when not to reuse a topic.

Thoughts?

[justinhynes]

@robrap My thoughts were something along the lines of...

"Well, this is a certificate event and we already have a place for certificate events... so let's send them there" -- admittedly without much more thought beyond that. I thought this would keep configuration simple but unsure of the other implications. For example, should we have a performance concern if one topic potentially has more consumer/producers than others?

My initial thought was to have separate topics because my brain compartmentalizes them easier, I think it is easier in terms of cognitive load and understanding, but dismissed it early. I agree that this is another place where order matters, and agree that the order doesn't matter compared against course certificates.

I am happy to pivot (and already mostly convinced) towards having a dedicated program certificate topic for managing these events.

[robrap]

Thanks @justinhynes.

• I can't say with certainty that I'm leaning in the best direction, but my current thinking is that we stick to one event type per topic in general, and create lifecycle topics when several related events must be ordered together. I also would like us to keep to one service producing to each topic, except for some exceptional cases.
• So, if you are ok with it, for now let's go with a new topic.
• That said, this is a highly reversible decision. We can always produce the event to multiple topics in the future if we get anything wrong and need to transition to a different topic.

How does this sound to you?

[justinhynes]

This sounds absolutely reasonable and I'll plan on having dedicated topics for program certificate events. Thanks for weighing in!

[justinhynes]

Closing as the events have been implemented (awhile ago).