Sharing NG #6993
Comments
exalate-issue-sync
bot
added
p3-medium
Type:Epic
micbar
added
Topic:API
Platform:Desktop
Platform:iOS
Platform:Android
Platform:Web
Category:Enhancement
|
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:
Space: Given the conditions outlined in the first image above, I think the permissions would need to look like this: 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 If there is no group hierarchy available it looks different. Given groups like this:
We would get: 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 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). 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. ;) |
Lifecycle of a sharelibregraph API spec for the sharing ADR in #6995 When following a share lifecycle, the following OCS requests can be replaced with these libregraph counterparts: List shares on a resource (includes sharing options)OCS: web calls two endpoints:
ms graph: {
"value": [
{
"id": "collaborative-share-id",
"roles": [
"write"
],
"grantedToV2": {
"user": {
"displayName": "Albert Einstein",
"id": "4c510ada-c86b-4815-8820-42cdf82c3d51"
}
},
},
{
"id": "public-link-share-id",
"roles": [
"read"
],
"link": {
"webUrl": "https://cloud.example.com/s/CMXOrzoFODpHKsS"
}
}
]
}libre graph: for now we stick to two kinds of permissions:
{
"value": [
{
"id": "collaborative-share-id",
"roles": [
"write"
],
"grantedToV2": {
"user": {
"displayName": "Albert Einstein",
"id": "4c510ada-c86b-4815-8820-42cdf82c3d51"
}
},
},
{
"id": "public-link-share-id",
"roles": [
"read"
],
"link": {
"webUrl": "https://cloud.example.com/s/CMXOrzoFODpHKsS"
}
}
]
}Search for recipient (not part of this PR)OCS: Note: There is a difference between Create a share with user or groupOCS: ms graph: sharing wit a user is done by posting an POST /drives/{drive-id}/items/{drive-item-id}/invite
{
"requireSignIn": true,
"recipients": [
{
"email": "[email protected]"
}
],
"roles": [
"read"
]
}response: {
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(permission)",
"value": [
{
"@odata.type": "#microsoft.graph.permission",
"id": "r_mJa3kBqBtkotIl8tWt9nVA2L1",
"roles": [
"read"
],
"shareId": "s!BFB3CkuhRCbBgmcZvWieFTBrBGQ",
"expirationDateTime": "0001-01-01T00:00:00Z",
"hasPassword": false,
"grantedToV2": {
"user": {
"id": "[email protected]"
}
},
"invitation": {
"email": "[email protected]",
"signInRequired": true
},
"link": {
"webUrl": "https://1drv.ms/f/s!BFB3CkuhRCbBgmcZvWieFTBrBGQ"
}
}
]
}It seems the response does not use libre graph: sharing wit a user is done by posting an POST /drives/{drive-id}/items/{drive-item-id}/invite
{
"requireSignIn": true,
"recipients": [
{
"objectId": "4c510ada-c86b-4815-8820-42cdf82c3d51"
}
],
"roles": [
"read"
]
}response: {
"value": [
{
"id": "8c5ed185-1fcb-4c5a-8569-b9ed04293204",
"roles": [
"read"
],
"grantedToV2": {
"user": {
"id": "4c510ada-c86b-4815-8820-42cdf82c3d51"
}
},
}
]
}jfd: multiple recipients can be sent in the same request. Each will receive a dedicated permissions object with their own id. WChen an error occurs a 207 multistatus response will be returned, similar to https://learn.microsoft.com/en-us/graph/api/site-follow?view=graph-rest-1.0&tabs=http#response-1 which shows an examplo where one of the entries contains an error POST /drives/{drive-id}/items/{drive-item-id}/invite
{
"recipients": [
{
"objectId": "4c510ada-c86b-4815-8820-42cdf82c3d51"
},
{
"objectId": "f7fbf8c8-139b-4376-b307-cf0a8c2d0d9c"
}
],
"roles": [
"read"
]
}response: {
"value": [
{
"id": "81d5bad3-3eff-410a-a2ea-eda2d14d4474",
"roles": [
"write"
],
"grantedToV2": [
{
"user": {
"id": "4c510ada-c86b-4815-8820-42cdf82c3d51",
"displayName": "Albert Einstein"
}
}
]
},
{
"id": "b470677e-a7f5-4304-8ef5-f5056a21fff1",
"error": {
"@odata.type": "#odata.error.main",
"code": "invalidRequest",
"message": "The user id that is provided in the request is incorrect",
"innerError": {
"code": "itemNotFound",
"errorType": "expected",
"message": "Unknown user id b470677e-a7f5-4304-8ef5-f5056a21fff1 ",
}
}
}
]
}Shared by meList shares created by the currently logged in user Shared with others (not part of this PR)Includes shares in project spaces that can be managed by the current user because he is a manager of the space. He does not need to be the creator of the share. Note: the OCS Hint: There is a difference in the concept of shares. In OC10 shares are tied to a user. In OCIS they are tied to a space. The Owner/All managers of a space can collaboratively manage all shares in a personal/project space. Shared with meAs the recipient you want to get a list of all driveItems that have been shared with you.
{
"value": [
{
"id": "u-u-id-of-mountpoint",
"name": "November-December Ad Proposals.pptx",
"size": 100984,
"parentReference": {
"driveType": "personal",
"driveId": "u-u-id-of-drive-containing-the-pointpoint",
"id": "parent-u-u-id"
},
"remoteItem": {
"id": "u-u-id-of-shared-driveItem",
"name": "November-December Ad Proposals.pptx",
"size": 100984,
"parentReference": {
"driveType": "personal",
"driveId": "u-u-id-of-drive-containing-the-item"
// no "id" because recipient is not allowed to see parent
},
"permissions": [
{
"@UI.hidden": false,
"id": "92f276ac-827a-40c1-9d9c-bb41a628ce71",
"roles": [
"write"
],
"grantedToV2": {
"user": {
"displayName": "Jörn Dreyer",
"id": "c12644a14b0a7750"
}
}
}
]
}
},
{
"id": "7fd82e03-09af-4b38-8d36-c7f7ec83cd99",
"name": "Marketing Term Successes International.xlsx",
"size": 17776,
"parentReference": {
"driveType": "personal",
"driveId": "u-u-id-of-drive-containing-the-item"
// no "id" because recipient is not allowed to see parent
},
"permissions": [
{
"@UI.hidden": false,
"id": "477731b4-56a6-4f58-9530-2e08bdf52df5",
"roles": [
"write"
],
"grantedToV2": {
"user": {
"displayName": "Jörn Dreyer",
"id": "c12644a14b0a7750"
}
}
}
]
},
{
"id": "a7d033f9-6093-43bb-91a7-bc82265e6a7f",
"name": "Irrelevant Marketing Term Successes International.xlsx",
"size": 176536587,
"parentReference": {
"driveType": "personal",
"driveId": "u-u-id-of-drive-containing-the-item"
// no "id" because recipient is not allowed to see parent
},
"permissions": [
{
"@UI.hidden": true,
"id": "5277be2e-db85-4d11-9a6c-28853142f279",
"roles": [
"write"
],
"grantedToV2": {
"user": {
"displayName": "Jörn Dreyer",
"id": "c12644a14b0a7750"
}
}
}
]
}
]
}jfd: we cannot put the Accept/Reject a share / an inviteOCS:
"parentReference": {
"driveId": "c12644a14b0a7750",
"driveType": "personal"
},libre graph: mount shares in the share jail by creating a driveItem using a {
"name": "Einsteins project share",
"remoteItem": {
"id": "{drive-item-id}"
}
}This request can check if the current user has access to the given drive item and will 'mount'/ accept it with the name "Einsteins project share". In theory we could add a remoteItem anywhere in a drive like in OC10, but it is a product decision to collect them in the dedicated virtual share jail drive. The mountpoint can be deleted/rejected by sending a Create a public linkms graph POST /drives/{drive-id}/items/{drive-item-id}/createLink
{
"type": "view",
"scope": "anonymous"
}response: {
"id": "{permission-id}",
"link": {
"type": "view",
"webUrl": "https://1drv.ms/f/s!AlB3CkuhRCbBgmde472f8-qxYdg",
"application": {
"id": "4c1ad100"
}
}
}Update shares / linksms graph: libre graph: PATCH /drives/{drive-id}/items/{drive-item-id}/permissions/{permission-id}
{
"link": {
"type": "edit"
}
}response {
"id": "{permission-id}",
"link": {
"type": "edit",
"webUrl": "https://1drv.ms/f/s!AlB3CkuhRCbBgmde472f8-qxYdg",
"application": {
"id": "4c1ad100"
}
}
}For links we ignore the role and instead set the link type. ms graph has a lot predefined: https://learn.microsoft.com/en-us/graph/api/listitem-createlink?view=graph-rest-beta&tabs=http#link-types
Delete shares / linksOCS Further readingIt follows the MS Graph API, documented here:
Listing shares incoming / outgoing shares:
interesting sidenote
|
|
@TheOneRing @felix-schwarz @jesmrec @michaelstingl I posted a typical share lifecycle. The details of the new API are getting clearer day by day now. I am really looking forward. We will get there 😄 |
|
can you explain what the endpoint
should do in the sharing ng context? |
|
You will get a list of drive items with an array of permissions https://owncloud.dev/libre-graph-api/#/me.drive/ListSharedByMe
Public links are not created via the invite endpoint. Please check the swagger Ui https://owncloud.dev/libre-graph-api/#/drives.permissions/CreateLink
Because they are the same like on OneDrive and we currently see no need to make that dynamic. The current efforts focus on shifting all responsibility to the server and make hatdcoded client side role mappings obsolete.
There are APIs to list roles and role permissions. The swagger ui provides a lot of explanations and examples. https://owncloud.dev/libre-graph-api/#/roleManagement/ListPermissionRoleDefinitions They will not be configurable in the first iteration. But that has no impact on the API, because they should not be configurable at runtime. |
Thanks! Looking at the provided example below, is {
"value": [
{
"id": "78363031-03ef-4eda-84a2-243a691a13cd",
"createdDateTime": "2020-02-19T14:23:25.52Z",
"eTag": "aQzEyNjQ0QTE0QjBBNzc1MCExMzc5LjQ",
"lastModifiedDateTime": "2021-09-03T14:09:25.503Z",
"name": "March Proposal.docx",
"parentReference": {
"driveId": "1991210caf",
"driveType": "personal"
}
I understand that public links should be created via
Right now, the iOS app can internally use roles for public links and user/group shares - and use the same UI code for public links as for user/group shares because the current/OC10 API uses the same permission model and endpoint as user/group shares. The way I understand the proposed new API now (and please correct me if I'm wrong), public links and user/group shares no longer share a common permission model or semantic, but there's now distinct concepts for the two:
Advantages I'd have seen in adopting roles for public links as well would have been that
|
I see. From the server POV shares and public links are different. So i would not advise to treat them like they are the same. Biggest differences:
The main entity is a driveItem, which is a file or a folder. The id of the driveItem is always the fileID. The permissions are a sub entity of the driveItem, and the permission id is equivalent to the shareID. |
|
To clarify for the short term:
Long Term changes on the CS3 API:
|
Goal
*needs deprecation notice 6 month prior for CERN
Images
Stories
Sharing
sharedByMeresponse #7703 @rhaferPOST 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" feature: add beta drive listing endpoints to the graph api #7861 @fschadeLinks
quicklinkandinternal linkto spec feat(api): Add link type internal and quicklink properties libre-graph-api#131 @micbarUsers
The text was updated successfully, but these errors were encountered: