Update and use case for the COURSE_CERTIFICATE_CONFIG_CHANGED event

[justinhynes]

Background

The Credentials IDA is responsible for storing course certificate configurations, which include data on when a certificate becomes available to learners and may be displayed on their Learner Record.

Currently, Credentials receives certificate configuration updates via Celery tasks and REST endpoints. When a course run is published, the system (edx-platform) checks whether the Certificate Display Behavior (CDB) or Certificate Available Date (CAD) has changed. If so, it emits the COURSE_CERT_DATE_CHANGE signal.

This signal is handled by the Programs Django app, which enqueues an update_certificate_available_date_on_course_update Celery task. When executed, this task makes a REST call to Credentials to update its records.

Problem

Instead of relying on Celery tasks and REST calls, we would like Credentials to receive this data via the Event Bus. However, there is currently no Event Bus event that supports passing CDB or CAD updates.

Proposal

The COURSE_CERTIFICATE_CONFIG_CHANGED event exists but is not currently used and is marked for deprecation. Instead of deprecating it, we propose an update and repurposing it.

We could introduce a new CertificateDisplayOptionsData class to encapsulate CDB and CAD details:

{
    "display_behavior": type=str,
    "available_date": type=datetime,
}

Then, modify the CertificateConfigData class to include display options data:

{
  certificate_type: type=str,
  course_key: type=CourseKey,
  title: type=str,
  signatories: type=List[CertificateSignatoryData],
  is_active: type=bool,
  display_options: type=CertificateDisplayOptionsData,
}

Last, emit the COURSE_CERTIFICATE_CONFIG_CHANGED event in the same location where the COURSE_CERT_DATE_CHANGE signal is currently triggered.

This approach would make the event more useful and align it with a use case for the Credentials IDA.

Appreciate any thoughts or concerns!

[robrap]

The COURSE_CERTIFICATE_CONFIG_CHANGED event exists but is not currently used ...

• Does this mean it isn't currently emitted, or there are no known listeners?
• Are you looking to both remove the deprecation and change its definition? Is the change in definition both when it would be triggered and what data is sent with it, or just the data?
• Are you basically asking if you can make a backward-incompatible change to the data without creating a new version because the event is currently unused (e.g. never triggered)?

[justinhynes]

Hi @robrap,

Does this mean it isn't currently emitted, or there are no known listeners?

It is not currently emit anywhere.

Are you looking to both remove the deprecation and change its definition? Is the change in definition both when it would be triggered and what data is sent with it, or just the data?

Remove the deprecation and change its definition. The use case I'm suggesting, coupled with the definition change, would give the event a concrete use case to start emitting and consuming it.

Are you basically asking if you can make a backward-incompatible change to the data without creating a new version because the event is currently unused (e.g. never triggered)?

I don't think this would technically be backward-incompatible as I'm only looking to add new information to it, without any other major changes to its composition. I'm asking if it's okay to add new info and suggesting a concrete use case where we would want to use this event.

[robrap]

Note that to add new information and keep it backward-compatible, you ordinarily would need to add the new data as optional. That said, if this event was never triggered, I think it would be ok to make the new fields required, because that is cleaner. It is technically not backward-compatible, but since no one is using the event, that is moot.

[justinhynes]

Ahh, I appreciate the clarification. That makes sense to me.