feat: preliminary signal definition

[mariajgrimaldi]

Description:
This PR adds the first 8 definitions of the Open edX events, they will be used in the Open edX platform.

JIRA: Link to JIRA ticket

Dependencies:
Depends on #8

Testing instructions:

With the event STUDENT_REGISTRATION_COMPLETED:
In your Open edX devstack

1. Go to lms shell make lms-shell
2. Install openedx-events specifying the events definition branch:
   pip install git+https://github.com/eduNEXT/openedx-events.git@MJG/events_definition#egg=events_definition
3. Change the Open edX platform branch to MJG/post_register_event
4. Connect your custom receiver to the signal as follows:

from openedx_events.learning.signals import STUDENT_REGISTRATION_COMPLETED

@receiver(STUDENT_REGISTRATION_COMPLETED)
def callback(**kwargs):
....

We'll add soon an example using our plugin openedx-basic-hooks!

Reviewers:

• @felipemontoya
• @andrey-canon

Merge checklist:

• All reviewers approved
• CI build is green
• Version bumped
• Changelog record added
• Documentation updated (not only docstrings)
• Commits are squashed

Post merge:

• Create a tag
• Check new version is pushed to PyPI after tag-triggered build is
  finished.
• Delete working branch (if not needed anymore)

Author concerns: List any concerns about this PR - inelegant
solutions, hacks, quick-and-dirty implementations, concerns about
migrations, etc.

[mariajgrimaldi]

Hey @ormsbee, I hope you're doing good! I know you’re swamped, but we want to let you know how our advances are going. We've moved forward with the implementation of what was discussed in PR #4. It consists of three pull requests:

1. Events tooling PR feat: add necessary tooling for Open edX events  #7: necessary tooling to manage events. Here we implement the class used to send events.
2. Data attributes for events PR feat: add data attributes definition for learning subdomain #8: definition of the events arguments.
3. Events definition PR feat: preliminary signal definition #18: definitions of some of the events proposed.

We're planning on taking the library with this PR upstream, after merging #7 and #8, as a way of exemplifying how events are used. So feel free to tag anyone interested!

[ormsbee]

Thanks @mariajgrimaldi! @feanil: ^

[ormsbee]

This framing seems a bit model-centric (as opposed to event). vs. calling this something like UNENROLLED.

[mariajgrimaldi]

You're right, maybe we could use COURSE_UNENROLLMENT_COMPLETED?

[ormsbee]

Do you need the state that it changed from?

[ormsbee]

(genuine question–I really haven't thought about what folks are looking with this use case at all)

[robrap]

Have you considered how these will be documented? Inline annotation documentation has the benefit of being close to the code, and would allow documentation to be added immediately along with the event definitions.

See toggles documentation as an example: https://edx.readthedocs.io/projects/edx-toggles/en/latest/how_to/documenting_new_feature_toggles.html

Thanks.

[mariajgrimaldi]

Excellent suggestion! We'll give it a go!

I'll tag you when it's ready!

[feanil]

This naming mismatch is throwing me off a bit. Does it make more sense for the key to be student instead of user?