The custom handler for "URL changed" events were added to reload the
file list whenever the sections for favorites and shares were opened;
this was used to fix the problem of not reloading the file lists when
opening them for a second time. However, besides that the handlers were
not really necessary, and as the root of the bug was fixed in the
previous commit those handlers are now removed.
The file list for tags uses the handler for a different purpose, though,
so that one was kept.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a section is open in the Files app a "show" event is triggered.
File list objects handle that event by reloading themselves, but only
if the file list was shown at least once. However, the file list objects
of plugins are created when the "show" event is triggered for the first
time for their section; as the file list objects register their handler
for the "show" event when they are created they never handle the first
triggered "show" event, as the handler is set while that event is being
already handled. Therefore, from the point of view of the handler, the
second time that a "show" event was triggered it was seen as if the file
list was shown for the first time, and thus it was not reloaded. Now the
"shown" property is explicitly set for those file lists that are created
while handling a "show" event, which causes them to be reloaded as
expected when opening their section again.
Note that it is not possible to just reload the file list whenever it is
shown; the file list is reloaded also when the directory changes, and
this can happen when the web page is initially loaded and the URL is
parsed. In that case, if file lists were reloaded when shown for the
first time then it could be reloaded twice, one with the default
parameters due to the "show" event and another one with the proper
parameters once the URL was parsed, and the files that appeard in the
list would depend on which response from the server was received the
last.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This fixes errors from LGTM like the following one:
Variable i is used like a local variable,
but is missing a declaration.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
This fixes some recommendations from LGTM:
Avoid automated semicolon insertion (90% of all statements
in the enclosing function have an explicit semicolon).
Signed-off-by: Stefan Weil <sw@weilnetz.de>
OCA.Sharing.SharedFileInfo was never defined and that stopped execution.
Interestingly, FF never showed me an error.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Now this is in core so the basics (that 99% of the app will want to
use) looks always the same.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When a "mouseup" event was triggered on any element except on the share
menu or its descendants the share menu was closed. The share menu toggle
is not a descendant of the share menu, so clicking on it when the share
menu was shown closed it by removing its "open" CSS class. However, once
that happened the click event was then handled by the share menu toggle,
which toggled the "open" CSS class in the share menu and thus added it
again. So, from the user point of view, nothing happened when clicking
on the share menu toggle if the share menu was open.
Now a "mouseup" event on the share menu toggle no longer closes the
share menu, and thus toggling the "open" CSS class when handling the
"click" event works as expected.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
fileInfo is composed of data from sharing, however additional data is
pulled when sidebar opens, e.g. the size. Then, existing data is
overwritten by data from the other source (files). The data points that
would be lost are not dirty however and still used, so we keep them.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
As "singleFileUpload" is used the "add" callback (which in turn calls
"addFileToUpload") will always be called with a single file. Therefore
there is no need to iterate over the files (and it is not done in the
other callbacks either, so this aligns the code with the rest of the
callbacks).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
There is no need to store the file name, as the "data" parameter given to
all the callbacks provides a "files" attribute with all the files that
the callback refers to; moreover, it will always be a single file due to
the use of "singleFileUploads" in the jQuery File Upload plugin.
This also fixes the loading icon not disappearing when several files were
uploaded at once. "singleFileUploads" causes the "add" callback to be
called once for each file to be uploaded, so "fileName" was overwritten
with the name of each new file in the upload set; when "fileName" was
later used in the "done" callback to find the file in the list whose
loading icon replace with the MIME type icon "fileName" always had the
name of the last file, and thus its icon was the only one replaced.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "done" and "fail" callbacks both update the item for the uploaded
file using "setFileIcon". "setFileIcon" updates the contents of the
"<li>" element for the file, but the "fail" callback was giving
"setFileIcon" an element generated by the template, so the resulting
HTML contained a "<li>" element nested in another "<li>" element.
However, generating the HTML is better done through a template, so the
template now receives the icon to show in order to be used by a
successful upload and a failed one, and "setFileIcon" was changed to
"updateFileItem".
Note that the mimeTypeUrl does no longer need to be escaped, as
Handlebars templates escape the needed characters automatically.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the "fail" callback is called, "errorThrown" is a property of the
data object instead of a parameter.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixes#4248
The magic introduced in #3686 caused the shared views not to be updated
properly. Thus we just overwrite the _onUrlChange method in the
sharedfilelist.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* we introduced this setting in the begining because our
avatar support caused some performance issues, but we
fixed them and should only provide one way how Nextcloud
looks
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* fixed size issues on main detail view and disappearing of share recipients
* Changes due to code comments
* Moved reloadProperties() to FileInfoModel
* Solved Scrutinizer issues
* Bugfix: undefined value used on error
* check if options are set for FileInfoModel.initialize()
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
- uses PUT method with jquery.fileupload for regular and public file
lists
- for IE and browsers that don't support it, use POST with iframe
transport
- implemented Sabre plugin to handle iframe transport and redirect the
embedded PUT request to the proper handler
- added RFC5995 POST to file collection with "add-member" property to
make it possible to auto-rename conflicting file names
- remove obsolete ajax/upload.php and obsolete ajax routes
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
add checkbox to toggle show/hide hidden files
persist show hidden setting
fix settings menu layout
test ApiController::showHiddenFiles
don't show hidden files by default
Store config in Backbone model and inject it into FileList
Filter files only temporarily when rending the file list
Fix file rename validation
This is for apps that use getDownloadUrl() to access the Webdav endpoint
for example for streaming.
Also happens when clicking on the download action of a file.
Note that the regular visible download URL is still the same.
The public page now uses the public.php/webdav endpoint.
Also enabled more file operations like rename, move, delete and create
folder from the public page, which are now all possible thanks to the
public.php/webdav endpoint.
When being on a link share and clicking "Add to your ownCloud" a double slash might be inserted in the URL if the entered ownCloud host ended with a slash. Results in a server error.
All reloadCallback must return either true for success or false in case
of failure / non-existing folder.
Some file lists only have a root folder (favorite, shares), so restrict
the path to that to avoid having a wrong path in the breadcrumbs.
This makes it possible for the recipient to still trigger the sidebar
and share tab to see information about the share.
In the case where the file is not shared and no permissions exists, no
action icon will be displayed.
Tab heads are not rendered if only one tab.
The tab contents is updated on-demand. This means that if a tab is not
visible it is not rendered at first. If the tab was already rendered
through switching, its model will not get updated until the next time it
becomes visible. This will prevent needless rerendering of invisible tab
contents, especially considering that some tabs might need extra ajax
requests.
The favorite icon in the sidebar now triggers the file action and also
updates itself according to the model's state when triggered from the
file row.
The thumbnail triggers the default action.
Currently only one FileInfoModel is used for the selection and state
synchronization between views.
FileList reload now auto-closes the sidebar.
In some corner cases, an outgoing share exists but sharing is not
allowed for the current user. This would cause the file list to break
because the static text could not be rendered as the owner was
undefined.
We need to set the size of the preview using the devicePixelRatio and use that as arguments when using the preview endpoint or that endpoint will use the default 36x36 and thumbnails will be blurry on high DPI devices
IE 9 and below do not provide window.btoa and there is currently no way
to generate base64 strings without introducting further dependencies.
So for now the solution is to fall back to the ugly picture mode for
text files whenever IE <= 9 is used.
`params` in the `OC.generateUrl` function call only replaces all specified occurences of a key just like the l10n PHP functionality does.
This means that to build a query string we have to use `OC.buildQueryString` instead of the params parameters.
Fixes https://github.com/owncloud/core/issues/16336 which is a regression introduced with 58a87d0bab of https://github.com/owncloud/core/pull/15652.
Without this fix downloading single files from a public shared folder is not possible.
Whenever an exception occurs during scan of a remote share, the share is
checked for availability. If the storage is gone, it will be removed
automatically.
Also, getDirectoryContent() will now skip unavailable storages.
From within a shared/public directory, when drilling down folders, some
users want to be able to download what they're currently looking at, not
the whole shared folder. The whole archive is always a click away anyway
since a user can click on the home button.
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.
Whenever a file is shared with others or with link, a delete button used
to be visible that triggered a direct deletion.
This button has been removed to avoid accidental deletion from people
who might believe it was an unshare button. Unsharing is still possible
inside the share dropdown.
FIXME: Ugly hack to prevent SVG of being returned if the SVG
provider is not enabled.
This is required because the preview system is designed in a
bad way and relies on opt-in with asterisks (i.e. image/*)
which will lead to the fact that a SVG will also match the image
provider.
Conflicts:
lib/private/preview.php
Added mountType attribute for files/folder to indicated whether they are
regular, external or shared.
The client side then adapts the "Delete" action hint text based on this
information.
Only the mount roots must have the delete icon hint adapted.
To make this detectable on the client side, the mountType can now
be null, "shared", "shared-root", "external" or "external-root".
This also gives room to icon customization on the client side.
Whenever an app needs to register an event late, it does that on the
original file actions object.
Since the file actions that the file list work on is a merged list, not
the original one, the registration event needs to be propagated there as
well.
In the "Shared with link" section, the share_with field can contain a
value when a password was set.
This fix prevents this value to be shown as it is not intended for the
end user.
Whenever file actions are modified, either by registering new actions or
when appending a new page of entries, the sharing app is now notified so
it can correctly refresh the sharing icon status.
Additionally, the core's loadIcons() method is also used to load the
existing shares and also refresh the sharing icons afterwards.
Whenever external share parameters were passed through the URL hash, the
URL hash will now be cleared.
In other cases, the hash needs to be left alone because it is used as
workaround for the lack of history API in IE8 / IE9
Removed getParamterByName() and use OC.Util.History.parseUrlQuery() that
does the same, including replacing the "+" with spaces.
Added section to only show link shares.
Please note that the filtering is currently done on the client side
which might not be the most efficient way of doing it.
Since the files app doesn't have the recipient information on load it
cannot initially render the recipients in the action icons.
For this reason the action icon will not be updated with the recipients
after changing the shares, for consistency.
Since OC.Share didn't have any array containing the list of shares for
the current file, OC.Share.currentShares has been introduced to contain
the full share item structure instead of the reduced one
OC.Share.itemShares.
The event "sharesChanged" is now passing OC.Share.currentShares, which
itself includes the display name to be displayed for the recipients in
the action icon.
- Fixed renaming and fileActionsReady event
- Added unit tests for shares list
- Fixed public page with defer
- Fixed file actions in sharing overview
- Fixed sharing counterpart list (10 entries max)
- Fixed file path attribute to be used in download action
- Fix sharing list headers
- OC.Share icons now operate on fileList instance
- Fix OC.Share.updateIcon when more than one list in DOM
Roeland Jago Douma
Julius Härtl
Michael Weimann
John Molakvoæ (skjnldsv)
Morris Jobke
Daniel Calviño Sánchez
Roeland Jago Douma
Stefan Weil
Christoph Wurst
Arthur Schiwon
Björn Schießle
MartB
Jan-Christoph Borchardt
Artur Neumann
Vincent Petry
Joas Schilling
Michael Jobst
Maxence Lange
Michael Jobst
Björn Schießle
Robin Appelman
Lukas Reschke
Piotr Filiciak
Erik Pellikka
prastut
Roeland Jago Douma
Joas Schilling
Thomas Müller
blizzz
Hendrik Leppelsack
Olivier Paroz
Espen Fjellvær Olsen
Georg Ehrke
Volkan Gezer
Robin McCorkell
Dan Jones
Joas Schilling
icewind1991
Lukas Reschke
Jörn Friedrich Dreyer