[mariajgrimaldi]

Description

This PR applies ADR 0032 and ADR 0033 to the existing built-in definitions, which currently share four YAML files and two constant modules, so each definition moves to the applet that owns it without changing the compiled schema:

• content_libraries owns the library roles and permissions;
• course_authoring owns the course permissions and adds them to the course-team roles through role_extensions;
• course_team_roles defines the course-team roles together with the legacy compatibility permissions they list.

Moving the definitions also makes the YAML schema the only place that lists a role's permissions, so the Python constants change as follows:

• role constants such as COURSE_ADMIN are RoleData identifiers without permissions, and code that needs a role's permissions can call get_permissions_for_single_role;
• the *_PERMISSIONS lists and the unused COURSES_CREATE_COURSE constant are removed, since nothing in openedx-platform reads them;
• openedx_authz.constants.permissions and openedx_authz.constants.roles re-export each applet's constants, so existing import paths keep working.

Also, installations that already applied the released schema still have source links pointing to the shared files, so 0012_move_builtin_schema_sources_to_applets moves them to the applets that now own those definitions.

Since a role's permissions are now spread across several applets, the compiled schema is published as a readable snapshot in docs/references/compiled-schema.yaml, which lists each role's permissions grouped by the applet that adds them. A test compares the snapshot with the compiled schema, which confirms that the move changes nothing else and makes any later applet change show its effect on the roles in the same diff.

Testing instructions

1. On main, run python manage.py migrate and python manage.py load_authz_schema.
2. Check out this branch and run python manage.py migrate, which applies 0012_move_builtin_schema_sources_to_applets.
3. Run python manage.py load_authz_schema --dry-run and check that it reports "Authz schema unchanged; nothing would be written."

Merge checklist:
Check off if complete or not applicable:

• Documentation updated (not only docstrings)
• Fixup commits are squashed away
• Unit tests added/updated
• Manual testing instructions provided
• Noted any: Concerns, dependencies, migration issues, deadlines, tickets

[openedx-webhooks]

Thanks for the pull request, @mariajgrimaldi!

This repository is currently maintained by @openedx/committers-openedx-authz.

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.