[alezconsultant]

Description

Adds the openedx-platform half of openedx/openedx-core#694: a new run of a course gets its own copy of the source run's content tags and competency criteria.

rerun_course calls the new content_tagging.api.copy_course_tags_and_criteria(source_course_key, destination_course_key) after it sets the initial permissions and before it marks the rerun as succeeded. The author therefore sees the new run only after the copy has finished. If the copy raises, the existing failure handling in rerun_course marks the rerun as failed and deletes the cloned course, so the author can retry with the same run.

Behavior

• Tags of every taxonomy on the course and its blocks are copied with tag_object, so they are editable on the new run and the source run's tags are unchanged.
• A taxonomy that is not enabled for the new run's organization is left out, together with the criteria that depend on it, and one warning per taxonomy is logged. The rerun still succeeds.
• The competency criteria are copied by copy_competency_criteria_for_course_rerun from openedx-core.
• The catalog CourseRun row for the new run is created if it is missing, because criteria groups reference that row. The course publish handler creates the row when it has run, so this creation covers a rerun in which it has not. The row gets the cloned course's display name, cut to the 255 characters the title column holds, and the course's language when it is one of ALL_LANGUAGES. In a test with the course-published signal enabled the row already existed when the copy ran; a live rerun was not observed.
• The copy takes no user and consults no permission, so the author needs no permission beyond the one to create the run.
• The tag copy and the criteria copy share one transaction, so a failure leaves neither behind.

Dependencies

This needs an openedx-core release that contains copy_competency_criteria_for_course_rerun. The requirements bump is added to this PR once that release exists.

Testing

pytest openedx/core/djangoapps/content_tagging/tests/test_api.py -k CopyCourseTagsAndCriteria and pytest cms/djangoapps/contentstore/tests/test_tasks.py -k RerunCourseTaskTestCase.

Manual testing

1. In Studio, open a course, tag a subsection with a competency from a competency taxonomy, and tag another block with a tag from a regular taxonomy.
2. On the Competency Management page, add a mastery rule for that competency on the tagged subsection.
3. From the Studio home page, create a rerun of the course and wait for it to finish.
4. Open the new run. Its blocks carry the same tags, and the tags can be edited.
5. On the Competency Management page, the competency shows a second course-level group for the new run with the same rule, and the source run's group is unchanged.
6. Remove a tag or archive a rule on the new run, and check that the source run still has it.

Known limits

• If a rerun fails after the copy has been saved (for example while copying videos), deleting the cloned course also deletes its CourseRun row, and the copied criteria groups and criteria are deleted with that row. The copied tags remain, as they do after any course deletion. A retry with the same run creates the CourseRun row and the criteria again and applies the same tags, so it ends with one copy.
• tag_object sends its tag-changed events inside the transaction, so a copy that rolls back has already sent events for the new run's blocks. The cloned course is deleted in that case.
• Tags of a free-text taxonomy are not copied. Such a tag is text typed by an author on one block and has no Tag row, and the copy reads tags with get_all_object_tags, which returns only tags that have one. Copy and paste, duplicate, and export already behave the same way.
• If a source block carries several tags from a taxonomy that now allows one tag per object, the rerun fails and is marked failed, as duplicate and copy and paste do on the same block. The source block's tags have to be corrected before the course can be rerun.

Related to openedx/openedx-core#694

🤖 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.

🔘 Update the status of your PR

Your PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate.

---

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.