feat: add platform-level glob scope

[BryanttV]

Resolves: #268

Description

This PR adds platform-level glob scopes so role assignments can target all resources of a type across the entire platform, not just within a single organization or specific scope.

Problem

Org-level globs (course-v1:OpenedX+*, lib:DemoX:*) grant access within one org. Some use cases need platform-wide coverage (e.g., a role on all courses everywhere) without assigning per-org globs.

Solution

• Introduce PlatformGlobData and PlatformCourseOverviewGlobData for the course-v1:* pattern (all courses on the platform).
• Split scope registration in ScopeMeta:
  • org_glob_registry: org-wide patterns (renamed from glob_registry)
  • platform_glob_registry: platform-wide patterns
• Add IS_ORG_GLOB / IS_PLATFORM_GLOB flags where IS_GLOB is derived from both.

Additional changes

• Add new registry helpers: get_all_org_glob_namespaces, get_all_platform_glob_namespaces, get_all_registered_scopes)
• PlatformCourseOverviewGlobData included in SCOPES_WITH_ADMIN_OR_SUPERUSER_CHECK |
• In scopes REST API users with a platform glob see unfiltered course/library querysets (same as full platform access)

Related Pull Requests

• feat: add platform glob scope support openedx-platform#38660

Testing Instructions

To test these changes, you can check the REST API.

1. Use the /api/authz/v1/roles/users/ endpoint to add platform-level permissions:

   {
       "users": [
           "john"
       ],
       "role": "course_admin",
       "scopes": [
           "course-v1:*"
       ]
   }

2. Validate the permissions /api/authz/v1/permissions/validate/me

   [
       {
           "action": "courses.view_course_team",
           "scope": "course-v1:OpenedX+DemoX+DemoCourse"
       },
       {
           "action": "courses.manage_course_updates",
           "scope": "course-v1:edunext+RBAC+2026"
       },
       {
           "action": "courses.manage_advanced_settings",
           "scope": "course-v1:any-org+any-course+any-run"
       }
   ]

Response

[
    {
        "action": "courses.view_course_team",
        "scope": "course-v1:OpenedX+DemoX+DemoCourse",
        "allowed": true
    },
    {
        "action": "courses.view_course_team",
        "scope": "course-v1:edunext+RBAC+2026",
        "allowed": true
    },
    {
        "action": "courses.view_course_team",
        "scope": "course-v1:any-org+any-course+any-run",
        "allowed": true
    }
]

Example scope keys

Pattern	Type	Meaning
course-v1:*	Platform glob	All courses on the platform
course-v1:OpenedX+*	Org glob	All courses in org OpenedX
course-v1:OpenedX+Demo+2026	Concrete	Single course

Merge checklist

Check off if complete or not applicable:

• Version bumped
• Changelog record added
• 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, @BryanttV!

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.

[BryanttV]

Hi everyone! This PR is ready for review, however, I have a few questions related to this PR that I'd like to resolve. @mariajgrimaldi @MaferMazu @rodmgwgu @bmtcril

1. This is how it is returned in the /assignments endpoint. Should the org property be "*" since it applies to all organizations at the course level? Or should it be left blank?, Or have some other value?

   {
       "is_superadmin": false,
       "role": "course_admin",
       "org": "*",
       "scope": "course-v1:*",
       "permission_count": 29,
       "full_name": "John Doe",
       "username": "john",
       "email": "john@doe.com"
   }

2. In the /scopes endpoint, only library-specific or course-specific scopes are returned. Should we also return org-level and/or platform-level scopes?

[MaferMazu]

Hello @BryanttV, thanks for this PR.

Regarding your questions:

In the /scopes endpoint, only library-specific or course-specific scopes are returned. Should we also return org-level and/or platform-level scopes?

As a cold answer, I'll say yes, probably we would need that. But it could be out of scope of this PR. I'll open an issue about it.

This is how it is returned in the /assignments endpoint. Should the org property be "*" since it applies to all organizations at the course level? Or should it be left blank?, Or have some other value?

I think it is better to maintain the wildcard to be consistent when someone has permissions across the platform (for example, global staff), and it is easier to handle (because leaving it blank could mean other things).

Notes from my first review:

When I try to assign a user as a course_user on the platform, I get a bad request.

Request:

{
    "users": [
        "course_user"
    ],
    "role": "course_user", // The role to add users to
    "scope": "course-v1:*" // The scope to add users to
}

Answer

{
    "role": [
        "Role 'course_user' does not exist in scope 'course-v1:*'"
    ]
}

We should be able to apply all course roles over this platform course's global scope, right?

Another thing I found is that it is better to use @property def is_glob instead of cls.IS_GLOB = cls.IS_ORG_GLOB or cls.IS_PLATFORM_GLOB, because that could be insecure (the evaluation of the property will occur in runtime, meanwhile the attribute cls.IS_GLOB could be static thanks to inheritance).