POC: Modular permissions #679
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Rotheem
force-pushed
the
modular-permissions
branch
from
e838be1 to
d2c5224
Compare
Daihecyy
reviewed
May 7, 2025
Rotheem
force-pushed
the
modular-permissions
branch
from
6119bee to
a76dfea
Compare
Rotheem
force-pushed
the
modular-permissions
branch
from
a76dfea to
3cd1ca9
Compare
Rotheem
force-pushed
the
modular-permissions
branch
from
1ad63c3 to
4679af5
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #679 +/- ##
==========================================
+ Coverage 84.84% 84.85% +0.01%
==========================================
Files 193 200 +7
Lines 13889 14075 +186
==========================================
+ Hits 11784 11944 +160
- Misses 2105 2131 +26 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
NakoGH
force-pushed
the
modular-permissions
branch
from
f36789e to
c0d357a
Compare
cotanoine
reviewed
Nov 24, 2025
cotanoine
reviewed
Nov 30, 2025
Rotheem
force-pushed
the
modular-permissions
branch
from
22001ec to
31c2021
Compare
^ Conflicts: ^ app/core/groups/groups_type.py ^ app/core/memberships/endpoints_memberships.py ^ app/dependencies.py ^ app/module.py ^ app/modules/cdr/coredata_cdr.py ^ app/modules/cdr/dependencies_cdr.py ^ app/modules/cdr/endpoints_cdr.py ^ app/modules/cdr/utils_cdr.py ^ app/modules/centralassociation/endpoints_centralassociation.py ^ app/modules/raid/endpoints_raid.py ^ app/modules/sport_competition/dependencies_sport_competition.py ^ app/modules/sport_competition/endpoints_sport_competition.py ^ app/modules/sport_competition/utils/schemas_converters.py ^ app/modules/sport_competition/utils_sport_competition.py ^ app/utils/auth/providers.py ^ tests/config.test.yaml ^ tests/core/test_core.py ^ tests/core/test_memberships.py ^ tests/modules/cdr/test_cdr.py ^ tests/modules/sport_competition/test_purchases.py ^ tests/modules/sport_competition/test_sport_inscription.py ^ tests/modules/sport_competition/test_validation.py ^ tests/modules/test_flappybird.py ^ tests/modules/test_raid.py
Rotheem
force-pushed
the
modular-permissions
branch
from
c57eba9 to
b585845
Compare
cotanoine
approved these changes
Jan 1, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 :
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_XXXpermissions, 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
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)
💥 BREAKING CHANGE (fix or feature that require a new minimal version of the front-end)
😶🌫️ No impact for the end-users
Impact & Scope
Core functionality changes
Single module changes
Multiple modules changes
Database migrations required
Other:
Testing
1. Tested this locally
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 commentsNo documentation needed