[FC-0099] docs: add adr 0008 compatibility scheme with the current system

[MaferMazu]

This is the proposed migration strategy.

I highlight:

• We will have a gradual migration starting with libraries.
• We will maintain the functionality of libraries' authz, but with the new system.
• We will transform the existing explicit role assignments to the new authorization model, without modifying the previous table.
• We will use the authorization API system for the libraries' endpoints related to authorization.

[openedx-webhooks]

Thanks for the pull request, @MaferMazu!

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.

[mariajgrimaldi]

Can we go ahead and create the DEPR ticket, even if we don't have all the info yet? It's critical to let the community know we're moving gradually from one system to another pretty soon.

[mariajgrimaldi]

What did you find in your investigation about bridgekeeper? I made some decisions here, but I want to understand what this would look like in practice during the migration.

I think it'd be also useful to go over what the current authz framework is made of, maybe citing the OEP-66. so we have an overview of the starting point and our end goal.

[MaferMazu]

Regarding Bridgekeeper, I think we still need it because it is the easiest way we have to maintain context/attributes checks that are currently working in the system, and we'll need it with the new one. I opened an issue about that: #87

[mariajgrimaldi]

Can we with the current data migrate this entirely to our new policy? Would it be a 1:1 mapping? I think this question applies for the rest of the modifications. I understand each step of the migration is different and maybe some map 1:1 and others don't, but including that initial study as a mandatory step as part of the consequences makes total sense to me.

[MaferMazu]

Regarding roles, the map for libraries is almost 1:1 (for the new version, we have a new role). However, we'll have more granular permissions. For complete mapping comparison, you can check: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5252317270/Libraries+Roles+and+Permissions+Migration+Plan#Migration

As @bmtcril and you suggested, I added a section on subsequent migrations to provide a general step-by-step guide on how we should migrate to use the new authorization system.

[bmtcril]

This is looking good, just one comment

[MaferMazu]

@bmtcril @mariajgrimaldi @rodmgwgu Sorry for my late response. I have already applied your feedback. I would appreciate a re-review.

[rodmgwgu]

Overall, the approach looks good, however I have some questions that I think should be clarified in the document:

1. After the script migrates the existing permissions, what'll be the use of the old permission tables? would the data just stay there unused for historical reasons? or will there still be code paths that may access it?

2. What happens if someone edits the old permissions? will there be a live sync process? or will these changes be just ignored?

3. What happens if there are cases where the new authz approach doesn't map 1:1 to the old one? will both permission validations coexist for a while? (like check_new_authz() or check_old_authz())

[MaferMazu]

Thanks for those questions, @rodmgwgu. I added them to the Migration Document, along with the following answers, but they are a proposal. If you have a better approach, please don't hesitate to provide feedback to help us improve our approach.

After the script migrates the existing permissions, what'll be the use of the old permission tables? would the data just stay there unused for historical reasons? or will there still be code paths that may access it?

For a transitional phase (Ulmo release), I was thinking of checking: 'you have permission in the new system' or 'you have permissions in the old one' in the enforcement points. If we do that, we'll still use the table for checking the old permissions. And then, after the transitional phase, we should remove the old permission table, as we won't need it since we'll modify all the code paths that may access it.

What happens if someone edits the old permissions? will there be a live sync process? or will these changes be just ignored?

Yes, we should have a sync process.

What happens if there are cases where the new authz approach doesn't map 1:1 to the old one? will both permission validations coexist for a while? (like check_new_authz() or check_old_authz())

Yes, the idea is that both permissions coexist for a while.
The roles map almost 1:1 (we have a new role), but for permissions, we have more granularity.

[MaferMazu]

Only to leave the track of the decision. We are not going to have the sync between the old and new roles; only the migration process will occur.
For cases as "Library Creator", we won't sync them with course_creator roles, only verify the conditions with the new system.
And for other roles, the user interface available will be the one that uses the new system (the only place where we could edit the roles for the previous system is the Django Admin, and we won't perform the sync).

[rodmgwgu]

Looks good! thanks for clarifying my questions on the RBAC Weekly meeting.