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
To ensure that pagination is working properly we need to make sure the
shares are always in the same order.
Sorting is first done by label (catches most instances)
If there is a user and a group with the same label we sort by shareType
If there are multiple users with the same label we sort those by
shareWith
Some private static functions in the OCS Share API
(files_sharing/api/local.php) take a params array with all the info
inside. This is bad for the limited type checking and is not clear.
To make sure clients have the correct and latest link add an url field
to all OCS Share API return statements on public link shares.
* Added unit tests
Previously the mount name was checked for uniqueness prior to inserting the
share. This caused problems, when two shares with the same name where done
or folder, mount point, local share with the same name was done, between
sending and accepting of the remote share
Beside some small improvements and bug fixes this will probably the final state for OC8.
To test this you need to set up two ownCloud instances. Let's say:
URL: myPC/firstOwnCloud user: user1
URL: myPC/secondOwnCloud user: user2
Now user1 can share a file with user2 by entering the username and the URL to the second ownCloud to the share-drop-down, in this case "user2@myPC/secondOwnCloud".
The next time user2 login he will get a notification that he received a server-to-server share with the option to accept/decline it. If he accept it the share will be mounted. In both cases a event will be send back to user1 and add a notification to the activity stream that the share was accepted/declined.
If user1 decides to unshare the file again from user2 the share will automatically be removed from the second ownCloud server and user2 will see a notification in his activity stream that user1@myPC/firstOwnCloud has unshared the file/folder from him.
Roeland Jago Douma
Thomas Müller
Morris Jobke
Joas Schilling
Lukas Reschke
Roeland Jago Douma
Björn Schießle
Joas Schilling
Arthur Schiwon
Jenkins for ownCloud
Bjoern Schiessle