Remove more unused legacy ids from early ownCloud times.
This reduces the number of duplicate ids in the DOM.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Removed legacy "#dir" input element in the DOM.
Apps should use OCA.Files.App.currentFileList or
OCA.Sharing.PublicApp.fileList and call getCurrentDirectory() to
retrieve the current directory and changeDirectory() to change it.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
- Add visible-focus effect on each header entry
- Show focus outline when using focus-visible (keyboard navigation)
- Add polyfy for focus-visible since it's only very recently available
on webkit
- Change text for link to home button to describe the destination and
not the current page
- Improve focus effect in app sidebar navigation
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
In a file list files with a default action
have an href that will trigger the action.
This way ctrl-click and middle button click open the default action in a new tab.
In order to achieve this a new param `openfile` was introduced to the files app.
It will make the files app trigger the default action for the file in question.
This also allows linking to file content rather than just the details display.
Introduce fileList.getDefaultActionUrl()
to create a link with that param set.
It's overwritten in the trashbin fileList
so that anchors continue to have `#` as a href.
Fix the link generation for subfolders of public shares:
58a87d0 was the last commit that touched the linkTo function in public.js.
It included the params as arguments to the generateUrl function.
Turns out this completely ignores the dir parameter now.
The inclusion was reverted in other places
so revert it here as well.
Also change `dir` to `path` in the param as that is respected
when following the link.
Add Test for the new link url for files with default action.
Remove test for multiple selects with ctrl-click
as that is not what we are doing anymore.
Signed-off-by: Azul <azul@riseup.net>
Before, the file or folder was opened when clicking on the name span,
but not when clicking on the link that contains the name; clicking on
the link highlighted the file and opened the sidebar, just like clicking
on the file size or date. Now clicking on the link opens the file or
folder, so the unit tests that tested clicks on the link were changed to
test clicking on the file size instead.
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
The new 'Move and copy' operation from #6040 requires UPDATE permissions
on the selected files. However, READ would be sufficient to create a
copy of a file (if not viewed as a public share). For this reason this patch:
- changes the permission of the 'MoveCopy' action to PERMISSION_READ
- changes the label of the action depending on the permissions
- changes the available buttons in the Move/Copy dialog depending on the
permissions.
The same changes are done to the filelist view for bulk actions.
Signed-off-by: Roland Tapken <roland@bitarbeiter.net>
"FileList._updateDetailsView" expects either a file name (as a string)
or a file model (as an "OCA.File.FileInfoModel"), but when called
through "updateInList" an "OC.Files.FileInfo" object was given instead.
As the given attribute was not a model "_updateDetailsView" treated it
as a file name and tried to get the model for that file, which failed
and caused the details view to be emptied.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
All the tests in the "Renaming files" section added the test files,
although those calling "doRename()" added them by setting a path for the
file too. However, the path is ignored in the other tests, so adding the
files can be unified and moved to "beforeEach()".
This would be needed, for example, to show the details view for a file
before calling "doRename()".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When an empty area of a file row was clicked and the "Details" action
was executed "fileActions.currentFile" was not guaranteed to be set to
the appropriate object (it depended on the previous actions of the
user), so when it was used by "getCurrentMimeType()" and other
FileActions functions they may not work as expected. Now it is
explicitly set to the appropriate value before its use.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now a file gets its directory permissions only if it contained no
permissions (they were undefined or null), but not if its permissions
were set to "NONE".
Besides that, now file actions that do not require any permission on the
file to be performed can be used on files that have no permissions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When several files are selected and one of them can not be deleted the
"Delete" file action is not shown in the summary. This commit extends
that behaviour too to the other file actions in the summary ("Move or
copy" and "Download"), so now an action is shown in the summary only if
it can be executed on all the currently selected files.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The selection column is not only a visual column, but also a real column
of the file list table. Unlike other columns whose width is reduced in
space constrained screens the selection column must stay the same so the
tapping area is large enough to be easily usable
The selection column does not appear in the search results table, so its
contents have to be explicitly aligned with those of the main table
based on whether the main table has a selection column or not (using the
"has-selection" CSS class in the same way as the "has-favorite" CSS
class was being used when there was a column for favorite actions).
In the tests the ":visible" selector can no longer be used. That
selector matches elements with a width or height that is greater than
zero, but the dimensions calculated in the unit tests are not reliable;
the width of the link was zero before these changes, and now moving the
checkbox to its own column causes the height of the link to become zero
too, so it no longer matches the ":visible" selector even if it is not
hidden. As hidding and showing the link is based on its "display" CSS
property its value is the one checked now.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The favorite icon was shown on its own "column" (not a real column in
the table, but a visual column achieved through margins and left
positions). Now the icon was moved to the top right corner of the file
thumbnail, and the thumbnail and file name were moved to the left to
fill the space left by the "column".
To keep the markup in line with its visual representation (and to ease
the placing through CSS), the favorite mark is no longer prepended to
the row, but appended to the thumbnail instead. In the same way, the
thumbnail is no longer appended to the checkbox label, but to the link
with the name of the file instead (although the checkbox is still shown
at the bottom right corner of the thumbnail, and clicking on the
thumbnail still selects the file). In order to show the "busy" state on
a file the "icon-loading-small" CSS class is set to the parent element
of the thumbnail, so the thumbnail is also wrapped now by another div
with the same size and position as the label.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The sort comparator checks the "isFavorite" property of the FileInfo
objects to compare. That property is set when the file list is loaded
and the response from the server is parsed, and thus a freshly loaded
file list has the proper sorting for favorite files. However, the
property is not set in other cases, like when the FileInfo objects are
derived from FileInfoModels due to a file being marked as a favorite or
a text editor being closed, which causes the file to be sorted in the
wrong position.
There is no need to add the property in those situations, though; in all
cases the TagsPlugin adds a "tags" array property that contains an
OC.TAG_FAVORITE tag, so that tag can be checked instead of "isFavorite".
Moreover, although "isFavorite" was added by the main "_parseFileInfo"
function it did not really belong there but to the "FileInfoParser" from
the TagsPlugin; however, as that property now is not used anywhere it
was removed altogether.
A cleaner solution would have been to make the sort comparator
extensible by plugins like other behaviours of the file list and then
add the sorting logic related to favorite files to the TagsPlugin.
However, right now only the TagsPlugin would need to alter the main
sorting logic, and it seems like a corner case anyway. Even if it is
implemented as a plugin, favorite files is a core feature, so for the
time being it will be taken into account directly in the main sorting
logic; making the sort comparator extensible by plugins is defered until
there are other use cases for that.
Fixes#5410
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In some cases, an app may need to act on a detail view registered by
another app or the core, for example, to add extra elements to the
element of the detail view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixes: #4644
Without this patch the filelist would always reload. However since not
all the correct data was set yet it would often:
1. fireoff a propfind to ../webdav/
2. fireoff a propfind to ../webdav/<PATH>
When just opening the file list those are the same so the result is just
fine. However if opening a direct link it means that there is a race
condition on which finishes first.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
John Molakvoæ
luz paz
Vincent Petry
Carl Schwan
Robin Appelman
Louis Chemineau
Valdnet
Julius Härtl
Christoph Wurst
Azul
Tomasz Grobelny
Morris Jobke
Jan-Christoph Borchardt
Michael Weimann
Abijeet
Roland Tapken
Daniel Calviño Sánchez
Bjoern Schiessle
Bernd Stellwag
Thomas Citharel
Roeland Jago Douma