feat: add platform glob scope support

[BryanttV]

Resolves: openedx/openedx-authz#268
Resolves: openedx/openedx-authz#307

Description

This PR adds support for platform-wide scopes (PlatformCourseOverviewGlobData and PlatformContentLibraryGlobData) when resolving AuthZ permissions, so users with global access can see all courses (when the authz course-authoring feature flag is enabled) or content libraries.

Related PRs

• feat: add platform-level glob scope openedx-authz#289
• feat: add platform-level glob scope for content libraries openedx-authz#333

Testing instructions

Using Tutor:

1. Use the changes in feat: add platform-level glob scope openedx-authz#289 and feat: add platform-level glob scope for content libraries openedx-authz#333

2. Enable the authz.enable_course_authoring flag globally, or in the courses or organizations of your choice.

3. Create a new user.

4. Assign them course and content library permissions at the platform level using the openedx-authz endpoint ({{lms_domain}}/api/authz/v1/roles/users/), e.g.:

   Content Libraries

   {
       "users": [
           "john"
       ],
       "role": "library_admin",
       "scopes": [
           "lib:*"
       ]
   }

   Courses

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

5. Verify the course list in Studio. All courses with the flag enabled should appear.

6. Verify the content library list in Studio. All created libraries should appear.

Deadline

Verawood

[openedx-webhooks]

Thanks for the pull request, @BryanttV!

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

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.

[MaferMazu]

Hello @BryanttV, thanks for this PR.

Regarding the functionality, this works as expected! ✅

I review it, and it looks good, just a small comment.

And to verify the test pass, we should use the hash of your last commit in openedx-authz (then you can change it again to v1.16.0).

[BryanttV]

@MaferMazu, Thanks for the suggestion. I added a temporary commit to test the changes in openedx-authz, and the checks passed ✔️

[MaferMazu]

Thanks for addressing my comments @BryanttV. This looks good to me ✨

📌 We need to remember to change the hash to the tag when we merge the openedx-authz PR.

[MaferMazu]

@BryanttV, thanks for updating this PR.

Reading this PR again, I was wondering how checking the waffle flag by course will impact performance when a role assignment has platform scope, because we would check N courses in _get_course_keys_from_platform_scope.

What you implemented is a logic approach, but in terms of cost, perhaps we should check whether the waffle flag is enabled per platform (globally), since this global scope doesn't make much sense if the waffle flag is by course. What do you think?

Btw, the rest looks good to me.

[BryanttV]

Hi @MaferMazu! Thanks for your comment.

I've been reviewing it, and I think the behavior should be exactly as it is. Even if the flag is enabled globally, it should still check if any course explicitly disabled it, right? In that case, that course_key shouldn't be returned. Let me know what you think.

[MaferMazu]

Even if the flag is enabled globally, it should still check if any course explicitly disabled it, right?

We are not doing it for orgs. If someone has org permissions, we are returning all the courses withouth checking them individually.

But I understand what you said.

In my opinion, we can live with the idea of a user with a course role on a platform being able to see the entire course list, but not have access to some courses, because it is a weird use case, and as I mentioned before, it doesn't make much sense to check by course a platform role. But if we want to be closer to correctness, I suggest we rethink _get_course_keys_from_platform_scope because, as it is, we'll check the flag for all courses on the platform, which is expensive.

Something we could do is exactly what you mentioned: check if the global flag is true, and then search for a course with a waffle flag set to off. And if the global flag is off, then search by course. What do you think about this idea?

Note: My concern is that we should have a short circuit (something that helps us return something quickly) before that return, which will ask for all the courses on the platform.

[BryanttV]

We are not doing it for orgs. If someone has org permissions, we are returning all the courses without checking them individually.

Yes, but here we are validating the course waffle flag:

openedx-platform/cms/djangoapps/contentstore/views/course.py

Lines 839 to 842 in 22512ba

	course_keys.update(
	key for key in _get_course_keys_for_org_scope(org_keys)
	if core_toggles.enable_authz_course_authoring(key)
	)

However, I do think we should have a short circuit. Here is what I propose:

• If the global flag is enabled, we return all courses without checking the flag per course.
• If the global flag is disabled, then we do validate course by course.

What do you think?

[MaferMazu]

@BryanttV, that looks reasonable to me.

[BryanttV]

@MaferMazu, done, changes made!