When accepting a share via 'POST /v1beta1/drives/{driveId}/root/children'
return the newly created driveItem. This driveItem wraps the accepted
remoteItem representing the shared resource (similar to the
'sharedWithMe' response.
This also refactors some of the helpers for user lookup and CS3 share to
driveItem conversion so they can be more easily shared.
(cherry picked from commit 7edc2febba4cd039c885a748d8f0e70610c2a147)
In theory creating the driveItem to accepting a shared resource
can be done via '/v1beta1/drives/{drive-id}/item/{item-id}/children'
but there is also the simplified variant via
'/v1beta1/drives/{drive-id}/root/children' (aligned with the example
in the spec). For now we'll just implement the latter because accepting
a share will always be done via root of the sharejail drive.
(cherry picked from commit c8a89e92f1ad662b6931bd8089795228e8492ae6)
After some back an forth we agreed on keeping the routes defined
in a central place for now.
(cherry picked from commit e7985f42b6edf92f0a4344d4f3f8c5e28c23e276)
* Bump reva
Fixes: #8080
* fix(sharing-ng): align sharedWithMe driveItem IDs
The IDs of the driveItems returned by the 'sharedWithMe' endpoint
should match the ids returned by the webdav PROPFIND response on
the share jail.
Fixes: #8420
* Fix mockery setup for graph service
Add missing interfaces to .mockery.yaml. Use existing mocks from protogen
where possible. Remove remaining //go:generate call.
* Add mockery config for settings service
* Add mockery config for proxy service
Don't return a meaningless userid anymore for shares created from files or directories
in a project space. These resources don't have a real owner.
Fixes: #8314
- multiple shares for the same resource are now returned as a single driveItem
- the id for that driveItem is for now based on the resourceId of the shared item
{sharesstorageproviderid}${sharejailid}!{resourceid of shared item}
- each share is exposed as a separate permission on the remoteId
- the permission now has an invitation property which provides the id of the creator
of the share
- the client.synchronize flag is now exposed on the top-level driveitem. If at
least on share of a resource is in accepted state the client.synchronize flag
will be set to true.
- the UI.Hidden flag is now exposed on the top-level driveitem. If at least on
share of a resource is marked as hidden the UI.Hidden flag will be set to
true.
- the 'shared' property is no longer available (the relevant information from that
moved to the 'invitation' property of the individual permissions.
In order to be able to group shares received for the same resource in a single driveItem
the driveItem's ID needs to be unrelated to the underlying shares' ids. We decided to base
it off of the shared resource's id (currently
{sharesstorageproviderid}${sharejailid}!{resourceid of shared item})
* bump mockery, add test stub for oidc_auth.go
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* use .mockery.yaml for all mocks
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* drop legacy go:generate mockery
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* align mock placement
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
---------
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
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
