CompetencyMasteryStatus and StudentCompetencyStatus data models

[jesperhodge]

Description

This PR is the base branch for the reviewable stack that implements the two of #642's four
models that do not depend on #641: CompetencyMasteryStatus, the lookup table of the three
mastery ranks (AttemptedNotDemonstrated, PartiallyAttempted, Demonstrated), and
StudentCompetencyStatus, the top-level table recording a learner's current mastery status for
one competency (a Tag), one row per learner per tag, updated in place rather than appended.

Supporting information

• Implements part of Mastery status lookup + learner progress models #642 (parent ticket [BE] Implement CBE core data models (CompetencyTaxonomy, criteria, learner status) #613). The remaining part of Mastery status lookup + learner progress models #642 is the part B stack,
  which starts at StudentCompetencyCriteriaStatus and StudentCompetencyCriteriaGroupStatus data models jesperhodge/openedx-core#20 and is out of scope here.
• Design rationale: ADR-0002 Decisions 5, 6 and 7; ADR-0003 Decision 5; ADR-0004 Decisions 4 and 6.

Note

Implemented by an AI agent (Claude Code), with a human directing the work and reviewing the
code and decisions.

How to review this PR

Review the stack on my fork, bottom to top. Do not review this PR directly — its own diff is
empty: it holds an anchor commit that GitHub requires to open a PR with commits ahead of main.

Order	PR	What it adds
1	jesperhodge#16	An empty anchor commit. The conversion of cbe/models.py into a models/ package that it used to carry landed via #800.
2	jesperhodge#17	CompetencyMasteryStatus, the mastery-rank lookup table, and its seed migration.
3	jesperhodge#18	StudentCompetencyStatus, the top-level learner mastery table.

Each PR targets the one below it; #16 targets this PR's branch (642-stack-base-branch), which
itself targets main. Review comments belong on the part that owns the code.

How to merge

1. Use github's "Stacked PR" feature on the jesperhodge/openedx-core fork to merge the 3 PRs into this base branch once they are reviewed and approved.
2. Merge this PR into main once the stack above is fully merged into its branch.

Migration numbering

This PR's migrations are 0008_competency_mastery_status, 0009_seed_competency_mastery_statuses and 0010_studentcompetencystatus, which follow #641's 0007 on main. #847 also adds a migration 0008, and #820 adds a 0002. Whichever of these PRs merges second renumbers its migrations after the other, because Django rejects a migration graph with two leaf nodes.

Testing instructions

Confirm no migration drift:

python manage.py makemigrations --check --dry-run openedx_learning   # expect: no changes detected

By hand, the two behaviors most worth confirming are the "one row per learner and tag" constraint
and that a Tag in use cannot be deleted out from under a recorded status:

from django.contrib.auth import get_user_model
from django.utils import timezone
from openedx_learning.models import CompetencyMasteryStatus, MasteryStatus, StudentCompetencyStatus
from openedx_tagging.models import Tag, Taxonomy

User = get_user_model()
user = User.objects.create(username="learner1")
taxonomy = Taxonomy.objects.create(name="T", export_id="t")
tag = Tag.objects.create(taxonomy=taxonomy, value="Writing")
now = timezone.now()

CompetencyMasteryStatus.objects.count()   # 3, seeded by the migration
demonstrated = CompetencyMasteryStatus.objects.get(id=MasteryStatus.DEMONSTRATED)

# created/modified are caller-supplied, not automatic — pass both on every create().
record = StudentCompetencyStatus.objects.create(user=user, tag=tag, status=demonstrated, created=now, modified=now)
StudentCompetencyStatus.objects.create(user=user, tag=tag, status=demonstrated, created=now, modified=now)
# IntegrityError: unique constraint on (user, tag)

attempted = CompetencyMasteryStatus.objects.get(id=MasteryStatus.ATTEMPTED_NOT_DEMONSTRATED)
StudentCompetencyStatus.objects.create(
    user=user, tag=Tag.objects.create(taxonomy=taxonomy, value="Reading"), status=attempted,
    created=now, modified=now,
)
# IntegrityError: check constraint — AttemptedNotDemonstrated is not allowed at the top level

tag.delete()   # ProtectedError: a status row still points at this tag
user.delete()  # succeeds, and takes the status row with it
StudentCompetencyStatus.objects.filter(pk=record.pk).exists()   # False

CI's MySQL job is the one that matters for the check constraint above; SQLite enforces it too,
but MySQL is the backend #642 was written against.

[openedx-webhooks]

Thanks for the pull request, @jesperhodge!

This repository is currently maintained by @axim-engineering.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[jesperhodge]

Closing in favor of a draft PR from the top of the stack instead of a base-branch placeholder — see the replacement PR for the #642 mastery-status stack.

[jesperhodge]

Reopening — reverting the top-of-stack approach in #832 back to this base-branch PR at the bottom of the stack.

[jesperhodge]

I think the PR description is ready now

[mgwozdz-unicon]

@ormsbee Since Jesper is out sick, I've opened #852 superseding this PR to get this across the finish line.

[mgwozdz-unicon]

#852 has been merged.