When computing the allowed roles for a spaceroot use the correct conditions.
Spaceroots require '@Subject.objectId Any_of @Resource.owners'.
Note: Updating or deleting the permissions on a spaceroot via
'v1beta1/drives/{driveid}/items/{itemid}/permissions/{permissionid}' does still
not work.
Return a 405 Status when UpdateSpace() or DeleteSpace() are not implemented
in the backend for a certain type of drive (e.g. the virtual mountpoint drives
created for shares).
Fixes: #7881
Resources on project space do not have a real owner assigned. A special
of the type USER_TYPE_SPACE_OWNER is returned as the owner. This type of
user can't be looked up via a GetUser request. So we skip that call for
this usertype.
This also fixes the behavior of 'sharedWithMe' for case when the owner
or creator of a share or shared resource can't be looked up in the 'users'
service. Previously cause the complete request to fail with an error message.
So a single share with an unresolvable owner caused 'sharedWithMe' to fail.
Now we log a warning but return all shares. Those where the owner or creator
couldn't be resolved will have the 'displayName' field of the user in the
'remoteItem.shared.owner' or 'remoteItem.shared.sharedBy' property left
empty.
Fixes: #8215Fixes: #8027
The outer parentreference should refer to the drive containing the mountpoint.
In our case this is the storagespaceid of the virtual share jail.
Also 'CreatedBy' should be the same as on the wrapped remote item. Not the share creator.
- remove unnecessary stat for accepted items
- only display permission actions if the role cannot be resolved
- add permission user and group displayName
This is an initial implementation of PATCH support on drives/{driveid}/items/{itemid}/permissions/{id}.
It focusses on updating user shares for now. It's possible to update the
expirationDate, roles and/or libregraphResourceActions.
Updating the permissions of a space root or a public link share is currently
not implemeted.
Neither 'BadRequest' (as expected in the unit test) nor 'Unauthorized' (as expected
in the API tests) seem correct here. We're no returning 'Forbidden' when an unprivileged
users issues a GetUsers request that it is not allowed to perform.
