Extend permission assignment possibilities

[nenadalm]

this pr includes #761

new featues:

• it is now possible to stop inheritance of advanced permission (there is "inherit" checkbox for that)
• it is possible to deny permissions to everyone by default, permission has to be granted using advanced permissions in that case (there is new "Default policy" select for this in settings)
• until now, there were admins that could manage permissions on files they had access to. There are new superadmins (currently it's only users in admin group - but multiselect can be added same way as for admins) that have read access to the whole group folder (recursively) so that if all permissions are denied by default, they can still manage them.

existing issues this will might solve:

• Allow stop inheritance of permissions #752
• ACL for all files in folder, but different ACL for parent folder (eq. delete permission) #738
• Denying permission for admin makes it impossible to recover folder #760
• Hide all subfolders expect one is explicitly shared #759
• Showing inherited ACL in sharing options #724
  • in case "Default policy" is set to "Allow access", nobody can access folders
  • inherited advanced permissions are shown

please check if this pr solves Your problems. We are evaluating if it solves ours. In case functionality is ok, it might be wise to do some performance optimizations - might look into it later if it works as expected.

[janpekar]

It solves problems for me. Creating nested groupfolders is no longer required.
I can create group folder and set Advanced permission for group, that has access which is not "inheritable" so subfolders hasn't that permission. For this to work is necessary "Allow access" feature because global group permissions set for group folder allow access for all members of that groups.

[juliusknorr]

it is possible to deny permissions to everyone by default, permission has to be granted using advanced permissions in that case (there is new "Default policy" select for this in settings)

I was wondering if we should do this on a per group level (similar to how the read/write/delete default permissions are set). We also should think about if we need to handle the root folder differently here, since otherwise you always need to add an ACL for the root itself first to make sure it shows up in the users home.

until now, there were admins that could manage permissions on files they had access to. There are new superadmins (currently it's only users in admin group - but multiselect can be added same way as for admins) that have read access to the whole group folder (recursively) so that if all permissions are denied by default, they can still manage them.

I'm not entirely sure if the current code properly prevents users to adjust ACLs if they have limited access to a path due to other ACL limitations. Splitting users who can manage ACL and admin users adds a new level of complexity here, so for now I'd like to stick with the approach that there is no limitation for users who can manage ACLs and give those full read access to avoid unexpected behavior here.

[nenadalm]

it is possible to deny permissions to everyone by default, permission has to be granted using advanced permissions in that case (there is new "Default policy" select for this in settings)

I was wondering if we should do this on a per group level

We need to deny access by default and since it's just different way of doing it, I don't mind. Should I change that?

In case of using different policy for different groups I think my mind would blow up when trying to set permissions, but I have no intentions on doing so :)

We also should think about if we need to handle the root folder differently here, since otherwise you always need to add an ACL for the root itself first to make sure it shows up in the users home.

Since it's consistent with other folders, I think it's fine.

Maybe if users have some permissions on sub folders/files then these users should have read access to root as well? If so, should this work also for other folders other than root? Say there is file /root/f1/f2/file and somebody adds read access to file to user? Should user have automatically read access on f2, f1 and root? I would prefer if root wasn't special folder - less things to keep in mind.

I'd like to stick with the approach that there is no limitation for users who can manage ACLs and give those full read access to avoid unexpected behavior here.

ok. I'll change that.

cc @janpekar

[jeltevdw]

What is the status of this pull request? It seems to be a very useful function.

[Prometheorum]

Does this pull request still have a chance to be merged? This PR would allow much easier managment of group folders with high member count and complex permission structures.

[fschrempf]

I don't think this PR has the potential to be merged in its current state. This doesn't mean that it doesn't add value. But rather than applying a pile of changes to cover multiple different issues, we probably want to work out the single points that need to be improved or fixed in the according issues and find solutions for each one separately.

We need to find solutions that don't add too much complexity and don't introduce too many (best: none) new user options that affect the overall behavior. Better fix the default behavior for all users instead.

One of the main points of this PR seem to be the issues mentioned in the description above. Let's discuss these topics there.

[fschrempf]

I'm closing this due to the reasons mentioned above and invite everyone involved to discuss the solutions in the linked issues, create new issues if required and come up with PRs that solve one problem at a time.