* Display changes in file versions tab view and detailsView
* versions tab enhancements
enhanced js test file
removed css superscript attribute for version size
* Replaced spaces with tabs
* Use DI to load console commands from the apps - class name to be defined in the info.xml
* Load commands from info.xml
* Fix unit test
* Allow Di magic for IMountManager
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This reverts commit 3731b2a006eca1e96d4087212a5e779c85a002e4.
Revert "[tx-robot] updated from transifex"
This reverts commit 94d91113f1206161b00bbc28da00aaf80bcd0a3e.
Revert "[tx-robot] updated from transifex"
This reverts commit e7cc8bac1e.
Revert "[tx-robot] updated from transifex"
This reverts commit 59fc3ff45a.
Revert "[tx-robot] updated from transifex"
This reverts commit 6a89a63d2e.
Revert "[tx-robot] updated from transifex"
This reverts commit b0bad03234.
* Move background job registration of Federation to info.xml
* Move background registration of Files app to info.xml
* Move background job registration of files_sharing to info.xml
* Move background job registration of files_trashbin to info.xml
* Move background job registration of files_versions to info.xml
* Move background job registration from user_ldap to info.xml
When calling `\OC\Files\View::copy` we should also keep the version to ensure that the file will always have the correct version attached and can be successfully decrypted.
To test this the following steps are necessary (from https://github.com/owncloud/core/issues/22781#issuecomment-191328982):
1. setup a new ownCloud 9.0 beta2
2. enable encryption
2. upload a docx (5.7MB large)
3. upload the same file again and overwrite the existing file
4. I can download the original file and the first version
5. I restore the first version
6. restored version can no longer be downloaded with the error described above
The manual cache operation in `\OCA\Files_Versions\Storage` is unfortunately necessary since `\OCA\Files_Versions\Storage::copyFileContents` is not using `\OCP\Files\Storage::moveFromStorage` in the case when an object storage is used. Due to the workaround added in 54cea05271 the stream is directly copied and thus bypassing the FS.
$view->getUidAndFilename($filename); returns the federated cloud id in case of
a federated share. But in this case we need the local user who "owns" the file
which is the current logged in user in case of a federated share
The path attribute contains the path relative to the owner's home
folder, not the one from the recipient, which is useless for the client
and needlessly discloses the owner's original path.
The requested already has access to the full path of the file, so no
need to add it to the response.
* versionSize is calculated anyway in the expire job - > dropped
* offset/neededSpace was needed for expiry before the file is moved to the versions -> now this is included already in the currently used space because the expiry job is defered to a point in time after the version creation
* fixes#21108
Adding group Db to federation tests and ldap tests
Add group DB to Test_UrlGenerator
Adding group DB to trashbin and versions tests
Adding group DB to Test_Util_CheckServer for pg
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.
