OCS Sharing API v2

[rullzer]

The current OCS Sharing API v1 is in need of successor.

• Sharing 2.0 #19331 Adds multiple share providers. This means that a simple generic ID is no longer sufficient. And we will switch to an id like 'providerId:shareId'.
• There current Share API is focused around shares the user initiaded. There is no way to get information about a path shared with me. To know the maximum permissions I can give when resharing (GET SHARES for a FILE with RESHARES=true does not return Shares owned by other users if the current user does not own any Share on the file #21779)
• The current share API has no pagination.
• The current output of the share API is cluttered and contains way to much unneeded info

We should design an API that fits the new needs of all the clients (web, desktop and mobile).

[PVince81]

Do I understand it well that most important part of this is making the reshare permissions properly available to the clients ?

Are there other requirements from the clients ?

@davivel @SergioBertolinSG @jvillafanez

[rullzer]

For the clients yes. But the id=>string is important to properly allow 3rdparty share providers

[PVince81]

• date format improvement: OCS Share API Date improvements #17166

[davivel]

@PVince81 , another information that I find useful from a received share is the identification of the sharer. The web UI shows it clearly when the "share" icon is pressed, no matter if the user then reshares or not.

Anyway, this is maybe more specific of #21179...

[PVince81]

@rullzer didn't you add these lately ?

[davivel]

@rullzer , @PVince81 , I closed #21779 in favor of #21855. I think it's clearer.

[PVince81]

• make it possible to get shares by file id instead of path: new attribute ? This could improve performance as the backend won't need to resolve the path, but then it also needs to check whether the user is allowed to access that file...

[PVince81]

• update share must accept setting multiple values at once, not a single one (like a real REST API)

[PVince81]

• be more REST-compliant
  • have consistent parameter names for both request and response: "expireDate" vs "expiration" ...
  • when doing a PUT/POST, return the whole list of attributes like with GET
  • a PUT is supposed to resend to full entity, all attributes (luckily the current API doesn't complain if we do so)
  • optional: implement PATCH method to only send a few of the attributes (like setting password, etc)

[PVince81]

Currently, this call

% curl -X GET 'http://root:admin@localhost/owncloud/ocs/v2.php/apps/files_sharing/api/v1/shares?path=abc&subfiles=true&format=json'

is the only way to quickly get the share status for files within a folder.
This is already used by the mobile client and possibly desktop client to be able to display status icons.

However it can be wasteful when a single file/folder is shared with 100 users, in which case it returns 100 entries all pointing at this file/folder.

Ideal would be to have a summary mode, either as extra attribute "groupresults=true" or "summary=true" or a separate endpoint to query such status.

• summary mode / grouping of results by path to save response size

[rullzer]

Before any sharing we want to know the max permissions:

• If a file is read-only for us we can't share it read-write.
• If resharing is now allowed
• ....

We should have an endpoint that returns the proper permissions for a path. Combined with a specific share type.

• Add endpoint to request the max share permissions of a path for a specific type.

[rullzer]

Currently when we disable the Sharing API we just don't return anything.
We should return a 403 or something.

• Proper status code when OCS Share API is disabled.

[rullzer]

• Allow 'notify by e-mail' stuff.

[rullzer]

Before any sharing we want to know the max permissions:

• If a file is read-only for us we can't share it read-write.
• If resharing is now allowed
• ....

We should have an endpoint that returns the proper permissions for a path. Combined with a specific > share type.

• Add endpoint to request the max share permissions of a path for a specific type.

Possible solution in #22834
It uses webdav but that is cleaner anyway IMO

[rullzer]

#22834 is in

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)