Prevent self-lockout with advanced permissions

[ctueck]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.

Our common pattern for group folders is: a wider group (all staff) has full access to the folder by default. Another group (managers, subset of staff) has the right to manage advanced permissions and occasionally wants to create sub-folders with full rights for managers (or certain other users or subgroups) only, and limited or no rights for the wider staff group.

When the intention is to give no rights (i.e. not even read) to the wider group, it all works well as long as the manager first adds an advanced permission rule to give themselves full access, and then creates a rule to deny access for the wider group. But...

We have had a few instances of managers locking everyone, including themselves, out of a sub-folder by first creating a deny-all rule for the wider staff group.

I understand it's logical that it happens, but the current workings make this mistake quite easy to happen. And as the folder becomes entirely invisible, this can only be fixed via occ commands.

Describe the solution you'd like

Would it be reasonable to consider users who have the right to manage advanced permissions as kind of super-users for that group folder and always entitle them to full access regardless of any advanced permission settings?

Describe alternatives you've considered

Two other alternatives that came to my mind:

1. If a user has no read permissions for a file or folder, but read permission for the containing folder, they can still see the file/folder but not enter/open/download it. (And should be able to manage advanced permissions provided they have that privilege.) This would not prevent the mistake, but make it easy and straight-forward for regular users to recover from it. Also, this would be more in line with regular Unix-like permissions logic - maybe this would actually be the better alternative.

2. Implement some kind of warning before someone creates a rule that would make the file disappear for them (or everyone). But this might be unnecessarily complex. It's also questionable whether it should be possible (via the GUI) to create a rule that makes a file/folder inaccessible and hidden from everyone to such an extent that even oneself cannot get it back, at least not via the GUI/without resorting to an occ command.

Additional context

Running NC 27.1.5 and groupfolders 15.3.4

I tried to check for any duplicate/closely related issue, but didn't find any and hope I didn't miss something.

[github-cli]

just a user reading this...

just chiming in an idea to add for alternative #1: you could do exactly that but only for user/groups set under Advanced Permissions (so those that could alter the setting). You could even have an option to turn this behavior on/off for the advanced permission groups.

[github-cli]

oh and the root issue seems to be
#1212
?
basically within a subfolder, allow wins against deny only if both are explicitly set
explicitly set always wins over inherited and only then does allow win over deny

if that behaviour would be changed to treat explicitly vs inherited the same, the issue would be gone as well in the described case (though locking yourself out would still be possibleif only one group has the advanced permissions or all others are already deny.
this can be "fixed" easier then by simply adding another group (even temporarily) to the root folder with allow, which would overrule everything again.

[provokateurin]

This is very similar to #1339, so closing as a duplicate.