* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Allows apps to register version backends for storage types
The existing versions backend is wrapped in a "legacy" backend.
Signed-off-by: Robin Appelman <robin@icewind.nl>
A revert triggers a move in the DAV client, and the DAV client expects a
DAV error message to be provided by the server in case of failure; if
no error message is given the client ends trying to get an attribute
from an undefined object and "crashes".
Besides that, if the revert fails the "done" callback of the promise
(the first parameter of "then") is never called, so a "fail" callback
should be used instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In Jasmine 2.5 the "it" function takes an optional parameter that should
be called when the async work is completed (returning a promise was
introduced in Jasmine 2.7, so it is not supported yet in the tests). If
the parameter is not declared then the next test is executed without
waiting for the asynchronous work in the previous one to finish, which
could cause that asynchronous work to finish while a different test is
being run.
Note that if that happens the test could still work as expected if it
relied only in local variables. However, in the case of the successful
revert tests, the stubs being checked are not the ones created when that
test was initialized, but the ones created when the next test, the
failed revert test, was initialized and the previous variables were
replaced (although the model itself calls the proper stubs, as they are
set through parameters in function calls).
Besides all that, the checks in the failed revert test were never
executed due to a different problem which will be fixed in the next
commit.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
added quit option in notif in app.js
added quit option in notif in file-upload.js
added quit option in notif in fileinfomodel.js
added quit option in notif in filelist.js
added quit option in notif in filelist.js
added quit option in notif in tagsplugin.js
added quit option in notif in statusmanager.js
added quit option in notif in external.js
added quit option in notif in versionstabview.js
added quit option in notif in notification.js
changes according to the latest review.
timeout removed since there is a button to close it
translation capability added
typo fixed
test files updated
small errors fixed
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* Properly expire ext storage versions
System-wide external storages have no real owner so the current user is
used as owner. However when running cron.php there is no current user,
so no expiry can be done.
This fix adds an user argument to the expire() function to tell for
which user to expire files. This information is anyway always available
now through the expire command job.
* Move version expire setupFS into the expire function
* Add comment about not tearing down in version Storage::expire()
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
* 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
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.