[alezconsultant]

Description

Bumps openedx-core from 1.18.0 to 1.20.0. The change is limited to the pinned version in uv.lock, requirements/edx/base.txt and requirements/edx/development.txt, regenerated with make upgrade-package package=openedx-core. The set of openedx-core dependencies is unchanged, so no other package moves. uv.lock also gains the manylinux2014 wheel entries PyPI now lists for grimp 3.18, which is already pinned at that version.

The two new releases bring three changes in openedx-core:

• openedx/openedx-core#900 (v1.19.0, for [BE] Enforce one root Competency Criteria Group per competency in the database openedx-core#872): the database now holds exactly one root CompetencyCriteriaGroup per competency. The model gains a derived scope_code column with a unique constraint, set on root groups only, so a second root for the same competency fails on insert instead of relying on a row lock in the API layer. A group's tag, parent and course are immutable after creation. Ships migration openedx_learning.0017_criteria_group_scope_code, which first checks for competencies with more than one root group (live or archived) and raises DuplicateRootCriteriaGroupsError naming each one before it changes the schema, then adds the column, backfills existing roots, and adds the constraints.
• openedx/openedx-core#911 (v1.20.0, for [BE] Add filtering to GET Competency Criteria & Groups openedx-core#682): GET /api/cbe/v1/competencies/<tag_id>/criteria-groups/ accepts an optional course_keys query parameter, a comma-separated list of up to 100 course run keys. When present, the response holds the groups above any course (such as the root) plus the complete subtree of each named course run, in the order requested. The response also gains criteria_count (criteria returned) and total_criteria_count (all non-archived criteria for the competency before scoping). Omitting the parameter returns the same groups as before plus the two counts. Studio already mounts openedx_learning.urls under api/, so the parameter is available in Studio with no change here.
• openedx/openedx-core#912 (v1.20.0): adds AGENTS.md with repository guidelines for LLM coding agents. This is documentation only, with no code change.

User roles affected: Course Author (competency criteria authoring). Operators run one new migration.

Supporting information

• openedx-core releases: https://github.com/openedx/openedx-core/releases/tag/v1.19.0 and https://github.com/openedx/openedx-core/releases/tag/v1.20.0
• Tickets: [BE] Enforce one root Competency Criteria Group per competency in the database openedx-core#872 and [BE] Add filtering to GET Competency Criteria & Groups openedx-core#682

Testing instructions

1. Check out this branch and install the requirements (uv sync, or pip install -r requirements/edx/development.txt).
2. Run ./manage.py cms migrate openedx_learning. It applies 0017_criteria_group_scope_code, and ./manage.py cms showmigrations openedx_learning lists it as applied.
3. In Studio, as a user with write access to two course runs and view access to a competency taxonomy, attach a criterion from each course run to the same competency with POST /api/cbe/v1/competencies/<tag_id>/criteria/.
4. Send GET /api/cbe/v1/competencies/<tag_id>/criteria-groups/ with no query string. The response has both course runs' groups and criteria, and criteria_count equals total_criteria_count.
5. Send the same request with ?course_keys=<course run A key>. Only the groups above any course and course run A's subtree come back, nothing from course run B appears in groups or criteria, and total_criteria_count still reports the full count.
6. Send the same request with ?course_keys=not-a-course-key. The response is a 400.
7. In a Django shell (./manage.py cms shell), create a second root group for a competency that already has one: CompetencyCriteriaGroup.objects.create(tag=<that tag>). It raises IntegrityError on the scope_code unique constraint.

Deadline

None.

Other information

• Includes one migration, openedx_learning.0017_criteria_group_scope_code. On a database that already holds more than one root group for a competency, migrate stops with DuplicateRootCriteriaGroupsError listing the tag and group ids before any schema change, so a rerun after removing the extra root is clean. Only deployments that track master with existing competency criteria data can have such rows; no named release installs openedx_learning yet.
• uv.lock is at lock revision 5, which uv 0.13.x writes. Regenerating with an older uv (for example 0.10.x) rewrites marker ordering across the whole file, so use a current uv for the next bump.
• This change does not depend on any other open PR.

Related to openedx/openedx-core#872 and openedx/openedx-core#682

🤖 Generated with Claude Code

[openedx-webhooks]

Thanks for the pull request, @alezconsultant!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform-oncall.

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.