-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow ACL Permissions don't overwrite Deny permission #438
Comments
I think that it's intended that Deny overrules Allow. But I also miss the possibility to stop the inheriting of permissions without having to deny them. It would be nice to be able to just not give the permissions without having to deny them. |
Any update on this? Having the same issue. |
Advanced permissions currently cannot allow permissions that are denied in the "normal" permissions. To get the behaviour you have to allow the permissions to the group in the group settings and then deny them using advanced permissions on the root of the folder. You can then re-allow the permission for any child folder |
looks like it works in this way, not sure if it's intended or it's just a workaround |
I tried this but it's not working. In the "Settings > Group folder" setup I added the groups with read access. Then I went to the root folder and clicked on the share icon. I disabled read access for a group using advanced permission rules and then further down the tree, I enabled the read permission, but the users in the group could not see that folder. |
If a user doesn't have read permissions on a folder there is no way for him to see and of the contents inside of it, and thus adding read permissions back in a subfolder is useless since the user will never be able to reach the subfolder in the first place |
OK that's fine if that's the way it is. I just tried to do what you described in your previous post and it didn't work. |
@miketranagfa I think you're right. It doesn't work the way @icewind1991 describes it. I just tried to do the same and the problem is just as described. Even if the user has full access in the "normal" permission settings, it is not possible to overwrite a "deny" further up the directory tree with an "allow" further down in the tree of the "advanced permissions". |
Same problem with me |
This would be a very useful feature to have. I expected, that I can add read permission on a subfolder and the recipient would then see the same path to that subfolder instead of having the subfolder now directly in his home folder. Would this be possible to implement? Or add an option to "Share with original Path". |
agree with @pgassmann, this behaviour cause our clients (and internal team) with different levels of access a lot of problems. |
@pgassmann |
@wiswedel @fri-sch @emilianocapasso I created a new Issue with my thoughts on how I would like it to function. #655 |
I just ran into the same problem and had to find this issue in order to understand the behaviour and how to achieve what I desired. I vote for overwriting a "deny" further up the directory tree with an "allow" further down in the tree of the "advanced permissions". My scenario is:
to achieve my desired behaviour. This use case won't interfere with what #655 is about (read permission). |
@olaldiko looks like a different issue, please open a new one. About the original issue, Ill close as a wontfix. It is a design decision that deny restriction is higher. We wont fix it in the foreseable future. If you come up with a ux idea on how to address this, feel free to open a new issue. |
I have a problem with the granular permissions:
Using this configuration:
and adding these permission in a subfolder:
from the other side (the test group) I'm see this permissions instead
The text was updated successfully, but these errors were encountered: