Repository navigation
🐛(backend) fix restricted folders deletion, move and inheritance - #945
Open
kernicPanel wants to merge 6 commits into
Open
kernicPanel wants to merge 6 commits into
kernicPanel wants to merge 6 commits into
Conversation
Deleting the restriction entry from the parent folder is what the UI does when the owner of the restricted folder removes it. The entry was only detached and the folder stayed at the root, while the toast said it was deleted. The owner now trashes the folder itself, other users keep lifting the restriction out of their folder. The restriction entry is trashed along with its target so that a restore puts the folder back in place, but it must not show up in the trash next to the folder.
kernicPanel
force-pushed
the
fix/restriction
branch
from
October 29, 2026 17:35
17d3abc to
f20b558
Compare
Trashing a folder left the restricted folders of its subtree in limbo: still restricted but reachable at the root, and brought back into the tree when it was restored, even for users with no right on them. The restricted folders now follow the user who trashes the tree. Those the user owns go to the trash with the tree, like children, and come back with it. The others lose their restriction and stay at the root with their owners. Restored alone out of a trashed tree, a folder becomes a plain root rather than keeping a restriction stuck in the trash.
Moving a restricted folder to the root moved its restriction entry there, pointing at a folder that already lives at the root: the folder kept its restriction mark, and a first deletion only dropped the entry while a second one was needed to trash the folder. The owner of the folder now lifts the restriction instead, the folder being already a root. Nobody else can take a folder they do not own out of the tree this way.
Lifting a restriction only normalized the folder itself: an explicit role or link reach on a descendant, equal or inferior to what it now inherits, stayed explicit and survived the removal of the inherited one above. The normalization now walks the subtree top down, over the items that carry explicit settings.
The abilities of a restriction entry came from the folder holding it: an owner of that folder could favorite or move the entry of a restricted folder they cannot even open. Both abilities now also require being able to open the restricted folder, through an access or its link, the same check the entry already exposes as can_access.
A restriction entry counted the accesses of the folder holding it, so a restricted folder shared with nobody showed up as shared when its container was. The entry now reports the accesses of the restricted folder itself, a root whose direct accesses are all its accesses.
kernicPanel
force-pushed
the
fix/restriction
branch
from
October 29, 2026 18:19
f20b558 to
943696a
Compare
|
This branch has not been deployed
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
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
Acceptance testing of restricted folders turned up a set of backend bugs
around deletion, trash, move and access inheritance of the restriction
entries and their target folders.
Proposal
A restricted folder that loses its place in the parent tree becomes a
plain root folder. Who performs the action decides what happens to it.
trashes the folder itself, once, instead of leaving it at the root
folders they own go to the trash with the tree, like children, and come
back with it; the others lose their restriction and stay with their
owners. Restored alone out of a trashed tree, a folder becomes a plain
root
owner of the folder, and is refused to anyone else
the whole subtree, not only on the folder
the restricted folder
unshared restricted folder no longer shows up as shared
Frontend follow-ups, out of scope here: redirect on 403, context menu of
restriction entries (favorite should read
abilities.favorite), wording.