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.
Added oc:tags and oc:favorites in PROPFIND response.
It is possible to update them with PROPPATCH.
These properties are optional which means they need to be requested
explicitly
This adds a "backend" type filter to the index REST route which is a pre-requisite for https://github.com/owncloud/core/issues/12620
For example when calling `index.php/settings/users/users?offset=0&limit=10&gid=&pattern=&backend=OC_User_Database` only users within the backend `OC_User_Database` would be shown. (requires sending a CSRF token as well)
Depends upon https://github.com/owncloud/core/pull/12711
This change will expose the user backend via the REST API which is a pre-requisite for https://github.com/owncloud/core/issues/12620.
For example:
````json
[{"name":"9707A09E-CA9A-4ABE-A66A-3F632F16C409","displayname":"Document Conversion User Account","groups":[],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/9707A09E-CA9A-4ABE-A66A-3F632F16C409","lastLogin":0,"backend":"OCA\\user_ldap\\USER_LDAP"},{"name":"ED86733E-745C-4E4D-90CB-278A9737DB3C","displayname":"Hacker","groups":[],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/ED86733E-745C-4E4D-90CB-278A9737DB3C","lastLogin":0,"backend":"OCA\\user_ldap\\USER_LDAP"},{"name":"71CDF45B-E125-450D-983C-D9192F36EC88","displayname":"admin","groups":[],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/71CDF45B-E125-450D-983C-D9192F36EC88","lastLogin":0,"backend":"OCA\\user_ldap\\USER_LDAP"},{"name":"admin","displayname":"admin","groups":["admin"],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/admin","lastLogin":"1418057287","backend":"OC_User_Database"},{"name":"test","displayname":"test","groups":[],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/test","lastLogin":0,"backend":"OC_User_Database"}]
```
* this needs to be properly fixed by a proper organisation of the base.php
* introduced fixDIInit() in AllConfig that moves the injection
of DatabaseConnection to a later point in time
* problems mostly because of the autoconfig setup
* keep old static methods - mapped to new ones and deprecated
* removed deleteApp, getUsers, getApps because they are unused
* make AllConfig unit tests more robust against not cleaned up environments
* introduce SystemConfig to avoid DI circle (used by database connection which is itself needed by AllConfig that itself contains the methods to access the config.php which then would need the database connection - did you get it? ;))
* use DI container and use that method in legacy code paths (for easier refactoring later)
* create and use getSystemConfig instead of query() in DI container
Depending on the used environment the port might be appended to the host header resulting in an inaccessible instance when initially setting up on a system with a different HTTP or HTTPS port. (for example test:500)
To test this setup ownCloud under a different port with and without this patch. (heads-up: localhost is always white-listed, so use a different domain)
Currently there is no AppFramework way to modify cookies, which makes it unusable for quite some use-cases or results in untestable code.
This PR adds some basic functionalities to add and invalidate cookies.
Usage:
```php
$response = new TemplateResponse(...);
$response->addCookie('foo', 'bar');
$response->invalidateCookie('foo');
$response->addCookie('bar', 'foo', new \DateTime('2015-01-01 00:00'));
```
Existing cookies can be accessed with the AppFramework using `$this->request->getCookie($name)`.