openedx / openedx/openedx-platform
Add CCX creation event signal to edx-platform
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 8.2k
- Forks
- 4.4k
- Avg merge
- 6d 18h
- Merged PRs (30d)
- 42
Description
Context
CCX creation is a significant lifecycle event that often requires integration with external systems or platform-specific workflows.
Today, edx-platform does not expose a clear, dedicated signal that indicates when a CCX has been created.
Problem statement
Currently, there is no first-class signal emitted specifically for CCX creation. As a result:
Integrations must rely on:
-
Ad-hoc hooks
-
Overloaded signals
-
Or duplicating logic across multiple code paths
There is no consistent or reliable way to react to CCX creation across:
-
Extensions
-
Plugins
-
External services
This makes CCX lifecycle integrations brittle and difficult to maintain.
Proposal
Introduce a dedicated signal that is emitted when a CCX is successfully created.
The signal should:
- Fire exactly once per CCX creation
Be emitted from a single, canonical location in the CCX creation flow
This would allow extensions and plugins to reliably subscribe to CCX creation events without duplicating logic.
Why this is viable
-
Low risk: signals are passive and do not alter core behavior
-
Backward compatible: no existing functionality is removed
-
Extensible: enables integrations without hardcoding platform-specific logic
-
Aligns with existing patterns: edx-platform already uses signals for other course lifecycle events
Additional context
A draft implementation has been proposed in:
https://github.com/openedx/edx-platform/pull/37897
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the draft implementation in PR 37897 and tracing the CCX creation flow it changes. Done means a dedicated signal is emitted exactly once from one canonical creation location, with coverage for that behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100