Restricted access - #756
Open
kernicPanel wants to merge 30 commits into
Open
Conversation
kernicPanel
force-pushed
the
restricted-access
branch
7 times, most recently
from
July 6, 2026 13:24
e8d21cc to
001fd58
Compare
kernicPanel
added a commit
that referenced
this pull request
Jul 6, 2026
The soft delete assertion sat inside the pytest.raises block and never ran, hiding a wrong expected message. Indexer error tests now keep a single raising invocation inside the block so the failure source is unambiguous. Flagged by Sonar on PR #756.
kernicPanel
added a commit
that referenced
this pull request
Jul 6, 2026
The soft delete assertion sat inside the pytest.raises block and never ran, hiding a wrong expected message. Indexer error tests now keep a single raising invocation inside the block so the failure source is unambiguous. Flagged by Sonar on PR #756.
kernicPanel
force-pushed
the
restricted-access
branch
from
July 6, 2026 16:26
c48a165 to
1cc98ba
Compare
kernicPanel
added a commit
that referenced
this pull request
Jul 6, 2026
The soft delete assertion sat inside the pytest.raises block and never ran, hiding a wrong expected message. Indexer error tests now keep a single raising invocation inside the block so the failure source is unambiguous. Flagged by Sonar on PR #756.
kernicPanel
force-pushed
the
restricted-access
branch
from
July 6, 2026 16:27
1cc98ba to
94113e5
Compare
kernicPanel
marked this pull request as ready for review
July 6, 2026 16:33
kernicPanel
added a commit
that referenced
this pull request
Jul 6, 2026
The soft delete assertion sat inside the pytest.raises block and never ran, hiding a wrong expected message. Indexer error tests now keep a single raising invocation inside the block so the failure source is unambiguous. Flagged by Sonar on PR #756.
kernicPanel
force-pushed
the
restricted-access
branch
from
July 6, 2026 16:45
94113e5 to
1d95fb3
Compare
kernicPanel
added a commit
that referenced
this pull request
Jul 7, 2026
The soft delete assertion sat inside the pytest.raises block and never ran, hiding a wrong expected message. Indexer error tests now keep a single raising invocation inside the block so the failure source is unambiguous. Flagged by Sonar on PR #756.
kernicPanel
force-pushed
the
restricted-access
branch
2 times, most recently
from
July 7, 2026 14:10
ee6b94a to
8d0b54d
Compare
kernicPanel
added a commit
that referenced
this pull request
Jul 7, 2026
The soft delete assertion sat inside the pytest.raises block and never ran, hiding a wrong expected message. Indexer error tests now keep a single raising invocation inside the block so the failure source is unambiguous. Flagged by Sonar on PR #756.
kernicPanel
force-pushed
the
restricted-access
branch
from
July 7, 2026 16:04
66fe632 to
fee9799
Compare
kernicPanel
added a commit
that referenced
this pull request
Jul 7, 2026
The soft delete assertion sat inside the pytest.raises block and never ran, hiding a wrong expected message. Indexer error tests now keep a single raising invocation inside the block so the failure source is unambiguous. Flagged by Sonar on PR #756.
kernicPanel
force-pushed
the
restricted-access
branch
from
July 7, 2026 16:17
fee9799 to
7d0b98d
Compare
kernicPanel
added a commit
that referenced
this pull request
Jul 7, 2026
The soft delete assertion sat inside the pytest.raises block and never ran, hiding a wrong expected message. Indexer error tests now keep a single raising invocation inside the block so the failure source is unambiguous. Flagged by Sonar on PR #756.
kernicPanel
force-pushed
the
restricted-access
branch
from
July 7, 2026 16:27
7d0b98d to
0d0bcbc
Compare
kernicPanel
marked this pull request as draft
July 7, 2026 16:32
kernicPanel
force-pushed
the
restricted-access
branch
from
July 8, 2026 05:26
0d0bcbc to
1dc030a
Compare
Pure move of Item.get_abilities into the role backend so every permission decision sits behind the same facade.
Each ability now reads as a named rule on ItemAbilities, fixing the Sonar S3776 complexity of the former monolithic function. Per-action properties also sketch the vocabulary a future ABAC engine will implement, one check per action.
Sonar S3516 flags validate() because every return yields the same attrs value. Merge the restricted early return into an if/else with a single exit and move the ancestors validation to a helper to keep cognitive complexity low; behavior is unchanged.
The soft delete assertion sat inside the pytest.raises block and never ran, hiding a wrong expected message. Indexer error tests now keep a single raising invocation inside the block so the failure source is unambiguous. Flagged by Sonar on PR #756.
TreeModel.parent() uses .last() which follows Meta.ordering (created_at). After a move(), the grandparent created later is returned instead of the direct parent. The parent path is known statically, so look it up by equality instead of scanning ancestors.
Allow folders to be marked as restricted. A DB constraint prevents setting is_restricted on non-folder items.
A shortcut materializes the original location of a restricted folder moved to the tree root. The OneToOne target enforces a single shortcut per folder and a DB constraint ties the target to the shortcut type.
Only an explicit owner can toggle restriction on a folder. A folder needs a parent to host its shortcut on activation, while an already restricted folder lives at the tree root and must stay deactivatable.
Restriction is structural: the folder physically leaves its parent so inheritance stops applying without any query-level cut. A shortcut materializes its origin location. Explicit link reach is kept and defaults to restricted only when it was inherited.
The folder returns under its shortcut's current parent and the shortcut disappears. Without a live shortcut the folder stays a detached root. Inheritance applies again through the tree structure.
Explicit roles granted during restriction that are now covered by inheritance are dropped, so the sharing screen does not keep dead entries. Superior roles and roles without inherited counterpart stay.
The reach kept from the restriction period is reset to inherit when the reattached parent already grants as much or more. A more open explicit reach survives, matching the role normalization rule.
Owners activate and deactivate restriction on folders via PATCH, gated by the restrict ability. The serializer keeps working on the instance returned by the toggle since the item physically moves.
Shortcuts expose their target's id, title and a can_access flag so the frontend can grey out entries pointing to folders the user cannot open. The children listing prefetches the viewer accesses to keep the query count flat, and the tree includes shortcut entries.
A restricted folder lives at the tree root but its members reach it through the shortcut when they can open the containing folder. The listing hides the root in that case so the folder shows up in a single location, and keeps it for members without container access.
Deleting a shortcut removes the entry from the containing folder without trashing anything. An owner excluded from the target acts on the container only and can neither destroy, declassify nor read it: the folder keeps its accesses, stays restricted, and surfaces in its members' top-level listing.
Trashing a folder must not drag restricted folders with it: their shortcuts are removed before the subtree is marked deleted, so each target survives untouched for its members while the rest of the branch goes to the trash as usual. Restoring the ancestor does not bring the shortcuts back.
An explicit owner trashing a restricted folder leaves no entry pointing into the trash. The folder restores as a detached root, still restricted, reachable by its members from their listing.
Shortcuts are tree entries, not content: they never match a search, never reach the search index, and leave no entry in an exported archive. The target itself is indexed and exported through its own root, so users excluded from a restricted folder cannot find its content through search or an ancestor export.
Creating a child folder with is_restricted chains creation and activation atomically, so the folder starts as a restricted root with its shortcut in place. Only owners of the parent may use it: a lower role would promote itself to owner through restriction. Shortcuts themselves can never be created directly.
kernicPanel
force-pushed
the
restricted-access
branch
from
August 13, 2026 16:43
d9eec74 to
47721ed
Compare
|
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
4 participants
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.
Purpose
Closes #731.
Let a folder owner restrict a folder so that only its explicit members
keep access, cutting the roles and link reach inherited from the tree.
This replaces the previous approach of this PR (cutting inheritance with
query-level exclusions) following review: the boundary had to be
reimplemented in every access-related query, and any forgotten spot
leaked content — link reach was already missing from the visibility
filters. The branch was rebuilt from main.
Proposal
A restricted folder physically becomes a root of the tree, so
inheritance stops by construction and every existing and future query
is correct without knowing about restriction. A new
shortcutitemtype materializes its original location.
is_restrictedfield andshortcutitem type targeting a restricted rootrestrictability: explicit owners only, activation needs a parent, deactivation always possiblePATCH {"is_restricted": bool},targetpayload on shortcuts (can_accessdrives the greyed entry), shortcuts in the tree endpointparent()resolved by exact path after a moveFrontend follow-up needed: render the
shortcuttype (opentarget.idwhen
can_access, greyed otherwise) and the activation/deactivationwarnings.