If a user deletes a group share we create a special share entry. To the
API this is just a normal group share for that user with permissions 0.
But we should not return this.
Now that we support multiple managers we communicate shares to the
outside as 'providerId:shareId'. This makes sures that id's are unique
when references from the OCS API.
However, since we do not want to break the OCS API v1 we need to
somewhat hack around this.
When we switch to OCS API v2 (which we should when we support more
custom providers). We will change the id to always be the fullShareId.
Fixes#21639
When lowering the remote search it break remotes that have uppercase
letters like foo@example.com/ownCloud/
Backends do the mathcing so they should also make sure that the search
string is converted to the format they require.
Currently the `getPath` methods returned `NULL` in case when a file with the specified ID does not exist. This however mandates that developers are checking for the `NULL` case and if they do not the door for bugs with all kind of impact is widely opened.
This is especially harmful if used in context with Views where the final result is limited based on the result of `getPath`, if `getPath` returns `NULL` PHP type juggles this to an empty string resulting in all possible kind of bugs.
While one could argue that this is a misusage of the API the fact is that it is very often misused and an exception will trigger an immediate stop of execution as well as log this behaviour and show a pretty error page.
I also adjusted some usages where I believe that we need to catch these errors, in most cases this is though simply an error that should hard-fail.
The data from the share_external is not to much. Thus we enrich this
data with info from the filecache.
This allows endpoints using this to actually show usefull information.
The filecache might not be up to date but that is a sacrifice we need to
make in terms of speed. Else the number of remote PROPFINDS grows
lineary with the number of remote shares wich will make this endpoint
practically unusable.
* list incoming remote shares at 'remote_shares'
* get per share info at 'remote_shares/<ID>'
* delete remote share with a DELETE to 'remote_shares/<ID>'
Since this extends the API we now properly parse the date. We only
accept valid ISO 8601 Dates (YYYY-MM-DD).
Currently this only works for link shares (it is just ignored for other
shares). Since we do not have user/group/federated expiring shares yet.
* Tests added
Thomas Müller
Roeland Jago Douma
Morris Jobke
Joas Schilling
Lukas Reschke
Roeland Jago Douma
Björn Schießle