Publish module grants in the permission manifest - #1
Merged
Conversation
The IAM seeds module access from this file and looks for a module_grants key per module. Nothing writes one, so it seeds none, and a session comes back with its permissions correct and no modules at all — which renders as an empty sidebar and a 403 on every screen. Access is two separate gates, may this role enter the module and may it perform this action, and only the second was being published. module_grants is derived from ROLE_GRANTS rather than listed by hand: any designation granted a permission in a module must be able to open that module, so writing the two out separately only creates a way for them to disagree. Also adds scope_permissions, for permissions enforced by narrowing a queryset rather than by refusing a request. There is no endpoint to find them in, so the manifest has to say so explicitly, and the unenforced-permission check now reads that list instead of reporting them as dead. Verified against a clean install: before, a student session resolves 6 permissions and modules []; after, the same session resolves 6 permissions and modules ['placement_cell'].
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Companion to Fusion_System_Administrator#90, which merged yesterday. That change
made
seed_iam_permissionsread module access from this manifest, keyed onmodule_grants. Nothing here writes that key, so onmaintoday the IAM seedsno module grants at all.
The symptom is not obvious from either side. A session comes back with its
permissions correct and
modules: [], which renders as an empty sidebar and a403 on every screen — so it reads as a permissions problem when it is the other
gate. Access is two separate checks, may this role enter the module and may
it perform this action, and only the second was being published.
What changed
module_grantsis derived fromROLE_GRANTSrather than listed by hand.Any designation granted a permission inside a module must be able to open that
module, so maintaining the two separately only creates a way for them to
disagree.
scope_permissionscovers permissions enforced by narrowing a querysetinstead of refusing a request. Holding one widens what you see; not holding it
shows you less. There is no endpoint to find them in, so the manifest has to
say so, and the unenforced-permission check now reads that list rather than
reporting them as dead code.
Verification
Full clean install — fresh clones, empty databases, restored dump — before and
after, same student account:
make checkis green: 407 tests, schema matches, import contracts hold.Note
Worth merging promptly —
mainis in the broken state until it lands, since theIAM half is already in.