* Fixed group share searching for members of
multiple group. Issue #11808.
* Fixed group share searching, continued.
Avoid searching for empty group list in getItemSharedWithUser().
Broke tests in previous commit, #12030.
* Simler check for group count.
* Fix for https://github.com/owncloud/core/issues/24783 , described there
* Now it's #24272, 24783 was a duplicate. Previous change was also not very good. Now we don't create ZIP with a single file inside.
jquery.fileupload offers the [`pastezone`](https://github.com/blueimp/jQuery-File-Upload/wiki/Options#pastezone) functionality. This functionality is enabled by default and if somebody copy-pastes something into Chrome it will automatically trigger an upload of the content to any configured jquery.fileupload element embedded in the JS.
This implementation triggers some problems:
1. The pastezone is defined globally by default (🙈). So if there are multiple fileupload's on a page (such as in the personal settings) then stuff is going to be uploaded to all embedded uploads.
2. Our server code is not able to parse the data. For example for uploads in the files app we expect a file name which is not specified => Just an error is thrown. You can reproduce this by taking a file into your clipboard and in Chrome then pressing <kbd>CTRL + V</kbd>.
3. When copy-pasting some string from MS Office on the personal page a temporary avatar with said content is created.
Considering that this is anyways was never working at all and causes bugs I've set the `pastezone` to `null`. This mens that upload via copy and paste will be disabled.
Lesson learned: Third-party JS libraries can have some weird details.
A federated share can report unlimited quota as -3, so the
ajax/upload.php code needs to be adjusted to block uploads when the free
space is unlimited.
* fixes#22819
The old way fired a DELETE statement on each destruction of the
DBLockingProvider. Which could cause a lot of queries. It's enough
to run this every 5 minutes in a background job, which in the end
could result in file locks that exists 5 minutes longer - in the
worst case and for not properly released locks.
This makes the DB based locking a lot more performant and could
result in a similar performance to the Redis based locking provider.
The notification tests were not restoring the clock properly, but
indirectly helped other tests pass.
Since now we're restoring the clock properly, the other tests were fixed
to still work.
When receiving a shared file, the quota for that file counts in the
owner's storage, not the current user's storage.
To make it possible to overwrite the file even when the current user
doesn't have enough space, the quota check is deferred for such files.