fschrempf
commented
12 months ago Hi, I'm currently trying out oCIS and in the long run I would like to migrate from Nextcloud + NC Groupfolders. The changes described above look like an equivalent for NC Groupfolder ACL permissions and this is what I'm currently missing for oCIS.
It would be great to see this implemented and if I can help in some way I would like to try and do so.
IMHO the question about the "conflict" between share permissions and space permissions described in the second image above is important. In NC this issue causes a lot of confusion as users can see the same content of a directory once as share and once inside the groupfolder (=space).
Would it be possible to prevent the conflict in the first place and do a check for overlapping shares and space permission for each affected user whenever shares/permissions are changed?
Another thing to consider is the use-case where we have a space with ("many") subdirectories and each subdirectory should be visible only to certain stakeholders. Here is an example:
Groups:
- Meeting Team (contains all members of the subgroups)
- Meeting Welcome Team
- Meeting Organisation Team
- Meeting Finance Team
Space:
Space "Meeting 2023" # should be visible to all groups
├─ Subdirectory "Shared" # should be writeable to all groups
├─ Subdirectory "Organisation" # should only be visible for group "Meeting Organisation Team"
├─ Subdirectory "Welcome" # should only be visible for groups "Meeting Welcome Team" and
│ # "Meeting Organisation Team"
└─ Subdirectory "Finance" # should only be visible for groups "Meeting Finance Team" and
# "Meeting Organisation Team"Given the conditions outlined in the first image above, I think the permissions would need to look like this:
Space "Meeting 2023"
│ * view-only permissions for "Meeting Team"
├─ Subdirectory "Shared"
│ * write permissions for "Meeting Team"
├─ Subdirectory "Organisation"
│ * deny all permissions for "Meeting Team"
│ * write permissions for "Meeting Organisation Team"
├─ Subdirectory "Welcome"
│ * deny all permissions for "Meeting Team"
│ * write permissions for "Meeting Organisation Team"
│ * write permissions for "Meeting Welcome Team"
└─ Subdirectory "Finance"
* deny all permissions for "Meeting Team"
* write permissions for "Meeting Organisation Team"
* write permissions for "Meeting Finance Team"For hiding subdirectories you need to use the parent group "Meeting Team" to first deny all permissions and then increase permissions for certain subgroups.
When scaling up to n subdirectories (each accessible only to one group) with m groups, we would get n * 2 permission rules.
If there is no group hierarchy available it looks different. Given groups like this:
- Meeting Welcome Team
- Meeting Organisation Team
- Meeting Finance Team
We would get:
Space "Meeting 2023"
│ * view-only permissions for "Welcome Team"
│ * write permissions for "Organisation Team"
│ * view-only permissions for "Finance Team"
├─ Subdirectory "Shared"
│ * write permissions for "Welcome Team"
│ * write permissions for "Finance Team"
│ * (inherited) write permissions for "Organisation Team"
├─ Subdirectory "Organisation"
│ * deny all permissions for "Welcome Team"
│ * deny all permissions for "Finance Team"
│ * (inherited) write permissions for "Organisation Team"
├─ Subdirectory "Welcome"
│ * deny all permissions for "Finance Team"
│ * write permissions for "Welcome Team"
│ * (inherited) write permissions for "Organisation Team"
└─ Subdirectory "Finance"
* deny all permissions for "Welcome Team"
* write permissions for "Finance Team"
* (inherited) write permissions for "Organisation Team"Note that "deny all" permissions are needed for each subdirectory and each group that has access to the space but not to the specific subdirectory. When scaling up to n subdirectories (each accessible only to one group) with m groups, we would get n * (m-1) permission rules.
To simplify this and make the rules more intuitive we could use something like an implicit "view-tree-only" permission. This means that someone that has access to a subdirectory of a space would automatically get the permission to see the directory tree above this subdirectory up until the root of the space (but none of the siblings on any level).
Space "Meeting 2023"
│ * write permissions for "Organisation Team"
│ * (implicit) view-tree-only permission for "Welcome Team"
│ * (implicit) view-tree-only permission for "Finance Team"
├─ Subdirectory "Shared"
│ * write permissions for "Welcome Team"
│ * write permissions for "Finance Team"
├─ Subdirectory "Organisation"
│ * (inherited) write permissions for "Organisation Team"
├─ Subdirectory "Welcome"
│ * write permissions for "Welcome Team"
│ * (inherited) write permissions for "Organisation Team"
└─ Subdirectory "Finance"
* write permissions for "Finance Team"
* (inherited) write permissions for "Organisation Team"I think this could greatly reduce the amount of explicit permission rules that are required and therefore make the whole thing much more simple to handle.
Sorry for the lengthy post and I hope this makes some sense at all to someone. ;)
micbar
fschade
felix-schwarz
butonic
Goal
⚠️ Note:
*needs deprecation notice 6 month prior for CERN
Images
Stories
Sharing
POST drive/{drive-id}/itemsandDELETE drive/{drive-id}/items/{item-ID}@fschade, https://learn.microsoft.com/en-us/graph/api/driveitem-delete?view=graph-rest-1.0&tabs=http, https://learn.microsoft.com/en-us/graph/api/driveitem-post-children?view=graph-rest-1.0&tabs=httpgrantedtoV2implementation with the unified roles instead of "editor, viewer, manager" https://github.com/owncloud/ocis/pull/7861 @fschadeLinks
quicklinkandinternal linkto spec https://github.com/owncloud/libre-graph-api/pull/131 @micbarUsers