POC: Modular permissions
Description
Summary
Introducing permissions
Relying on hardcoded groups for access restriction is prone to be limiting at some point. We can't easily change which group owns a specific module and it is heavily dependent on Centrale's association structure.
This PR introduces a new concept : Permissions. Represented by system-wide unique string they are declared by modules and replace completely GroupTypes for endpoint restriction. A user must have the endpoint's specific permission to have access to it. A permission can be linked to a user through 2 ways :
- Linking a group to the permission and having the user in the group
- Linking an account type to the permission and having this account type for the user
Thus, a permission can be linked to multiple groups and/or account type, can be easily transferred and allow each Hyperion instance to adapt better to any school's association structure.
Improving visibility
The visibility system was introduced to restrict in-app access to module, however it was still falling short for direct API calls both in synchronization and flexibility. The visibility could be set on/off for certain account types or groups while the endpoint would still be restricting another group and only GroupType could be used for API restriction.
To address this issue, we use access_XXX permissions, this specific syntax will be recognized by Titan as a replacement for visibility. As permissions are fully modular and uniformized, both issues are resolved by replacing visibility by specific permissions.
Integrating auth restriction
Auth providers allow access depending on account types or GroupTypes, however as permissions delete GroupTypes there was a need to refacto this part. The chosen method is a set of specific permissions for auth manually added to the global permission list after the module discovery.
Changes Made
- [x] add permissions modification logic
- [x] declare modules' permissions
- [x] refactor all modules' endpoints restrictions with permissions check
- [x] refactor visibility with specific permissions
- [x] refactor auth access
Type of Change
-
[ ] 🐛 Bug fix (non-breaking change which fixes an issue)
-
[ ] ✨ New feature (non-breaking change which adds functionality)
-
[ ] 🔨 Refactor (non-breaking change that neither fixes a bug nor adds a feature)
-
[ ] 🔧 Infra CI/CD (changes to configs of workflows)
-
[x] 💥 BREAKING CHANGE (fix or feature that require a new minimal version of the front-end)
-
[ ] 😶🌫️ No impact for the end-users
Impact & Scope
-
[x] Core functionality changes
-
[ ] Single module changes
-
[ ] Multiple modules changes
-
[ ] Database migrations required
-
[ ] Other:
Testing
-
[ ] 1. Tested this locally
-
[x] 2. Added/modified tests that pass the CI
-
[ ] 3. Tested in a pre-prod
-
[ ] 0. Untestable (exceptionally), will be tested in prod directly
Documentation
-
[ ] Updated the docs accordingly :
-
[ ]
"Docstrings -
[ ]
#Inline comments -
[ ] No documentation needed
Codecov Report
:x: Patch coverage is 83.75286% with 71 lines in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 85.72%. Comparing base (f977db1) to head (ec4bd4e).
Additional details and impacted files
@@ Coverage Diff @@
## main #679 +/- ##
==========================================
- Coverage 85.89% 85.72% -0.18%
==========================================
Files 193 199 +6
Lines 14953 15106 +153
==========================================
+ Hits 12844 12949 +105
- Misses 2109 2157 +48
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.