Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Added icon-change on drag
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed Navbar-closing in app when favorites-list is toggled on mobile
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Refactored Code
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Changed to alphabetical sorting
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed deletion of folder with identical names
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed ability to add files to the quickaccess
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed wrong path-generation when added from favorites-star
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed Element from navbar when favorite-star in detailview is toggled off
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Changed Quota-Text to prevent boundarybreaks
Reverted last commit
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed Bad url-generation in javascript for new quickaccessitems
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed vertical scrolling in sortable-list which leads to "hidden" navbar
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed unnessessary console logs
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed Bounds in custom sorting
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Reformatted code
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed horizontalscroll on sortable-list
Fixed "stuck element" where you could not switch back to the original ordering in the sortable-list
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Added FavoritesQuickaccess-Sidebar
Added Files-FavoritesQuickaccess-Toggle
Fixed CSS for SpacerElement
Removed Unnessessary Alerts and added Translations
Tried fixing initial Quick-Access Checkboxstate
Signed-off-by: fnuesse <fnuesse@techfak.uni-bielefeld.de>
Tried fixing initial Quick-Access Checkboxstate
Changed double-Quotes to single-Quotes
Revert webdavurl which was changed by mistake
Revert quota-icon which was changed by mistake
Changed the Folderhandling from custom-designed to nextcloud-NavigationManager-handling
Signed-off-by: fnuesse <fnuesse@techfak.uni-bielefeld.de>
Moved CSS-Spacerclass to apps.scss for global usage
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Renamed settings-caption in apps.scss to app-navigation-caption
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed old input-tag for showQuickAccess-state
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed old spacer element in files.scss
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Changed style of favorites-sublist and disabled the ability to disable files-quickaccess
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
1. Removes an unnecessary width
2. Content of the table header moving down on selection. Happening due to increase in height of header.
3. Invalid font-size for the actions menu.
4. Vertical position of the action menu
Signed-off-by: Abijeet <abijeetpatro@gmail.com>
When the browser reports a drag of items other than files (for example,
text) and then triggers a drop event with no files no error message
should be shown to the user, as in that case there would be no highlight
of the drop zone and no indication that the drop would be valid (except
for the mouse cursor); the error message should be shown only when
the drop event with no files follows a file drag.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The highlighting was removed in Firefox when the cursor was no longer
moving to handle the behaviour of reporting a file drag and then
providing no files in the drop event. That behaviour (which was only
present in Firefox 48 and 49) is already handled with the "dropnofiles"
callback, so that special handling is no longer needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a file is dragged from the desktop to the file list the file list
is highlighted, and when the file is finally dropped or the drag
operation is cancelled the highlighting is removed. In some cases, due
to a wrong implementation, a browser may end a file drag with a drop
with no files (for example, when a folder or text is dragged), which
would cause the highlight to not be removed. Now those cases are handled
with the "dropnofiles" callback, which restores the UI and also shows a
message to the user.
The error message is just a generic one, as in some cases it is not even
possible to know whether the problem came from a text drag or a folder
drag, and whether the problem appears or not depends on the browser,
version and even operating system.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The jQuery Plugin triggers the "dragover" callback when the browser
triggers the "dragover" event and the types in their DataTransfer
include a "Files" item. It also triggers the "drop" callback when the
browser triggers the "drop" event and the list of files in its
DataTransfer is not empty.
Unfortunately some browsers may trigger "dragover" events with a
DataTransfer that includes a "Files" item and then trigger a "drop"
event with an empty list of files. When that happens the actions
performed in the "dragXXX" callbacks could be left hanging if they were
expected to be finished in the "drop" callback (for example, if the drop
zone was highlighted during the drag to be then restored when the file
was finally dropped). This commit adds the "dropnofiles" callback to be
able to handle those situations.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"disableDropState" was set as the event handler in 8d4e5747f3, but
the duplicated code was accidentally added back in 786e858d23.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before any upload is submitted the upload is registered in a list of
known uploads; this is needed to retrieve the upload object at several
points of the upload process. When a chunked upload is submitted first a
directory to upload all the chunks is created and, once that is done,
the chunks are sent; in order to send a chunk the upload object needs to
be retrieved from the list of known uploads.
When all the active uploads were finished the list of known uploads was
cleared. However, an upload is not active until it actually starts
sending the data, so while waiting for the upload directory to be
created the upload is already in the list of known uploads yet not
active. Due to all this, if the active uploads finished while another
pending upload was waiting for the upload directory to be created that
pending upload would be removed from the list of known uploads too, and
once the directory was created and thus the chunks were sent a field of
a null upload object would be accessed thus causing a failure.
Instead of removing all the known uploads at once when the active
uploads finish now each upload is explicitly removed when it finishes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The jQuery File Upload plugin triggers the "stop" event once there are
no more files being uploaded (even if some of them were added when
another upload was already in progress). Therefore, the progress bar
should be hidden in the "fileuploadstop" callback.
In some cases the "stop" event is not triggered and thus the progress
bar is not hidden once no more files are being uploaded. This is caused
by a race condition and it will be fixed in another commit; except in
buggy cases like that one (that need to be fixed anyway) it is safe to
hide the progress bar in the "fileuploadstop" callback.
In any case, note that the callbacks in "fileuploaddone" may be called
after the "stop" event was triggered and handled when using chunked
uploads. In that case once all the chunks are uploaded the assembled
file is moved to its final destination, so its promise could be resolved
after the "stop" event was triggered. Therefore a different approach
would be needed to keep the progress bar visible until the chunked
upload is truly finished, but for the time being the current one is good
enough.
Before this commit the progress bar was being hidden when the first
upload finished, either successfully or with an error, no matter if
there were other files being uploaded too.
The progress bar was being explicitly hidden also when the upload was
cancelled. When an upload is cancelled all the single uploads are
aborted, which triggers a "fail" event for each of them. However, the
"stop" event is always triggered when no more files are being uploaded,
so it is triggered too once all the single uploads were aborted. As all
the single uploads are immediately aborted in a loop when the general
upload is cancelled it makes no difference to hide the progress bar when
the first single upload is aborted or when all the single uploads were
aborted, so the progress bar is no longer explicitly hidden in the
former case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
There were two routes apps/files/ajax/download.php but apparently also
apps/files/download.php I could not find any use of it.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The div that contains the elements related to the creation of new files,
and thus the upload button, is always present in the DOM; it is hidden
or shown based on the folder permissions by adding or removing the
"hidden" CSS class. However, as the other CSS classes for the div are
"actions" and "creatable" and a "display: flex" rule was defined for
".actions.creatable" below the "display: none" rule for
".actions.hidden" the last one took precedence and the div ended being
always visible, even if the "hidden" CSS class was set. Now the rules
for the ".actions.hidden" selector are defined below the rules for the
".actions.creatable" selector and thus the "display: none" rule is
applied as expected.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Menu and home are not always visible; home is always visible, but menu
is shown only when needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"getTotalWidth" is not more accurate; it is simply not clamped.
Moreover, "width/outerWidth" could be used in tests too, and also even
if "getTotalWidth" could be used in tests while others not that would
not be something to be stated in the API documentation, but in a
comment.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
After the changes in the previous commit "_showCrumb" no longer shows
the menu, only the same crumb that was hidden by the last call to
"_hideCrumb". Therefore, if the crumb was hidden because it did not fit
there is no need to try to show it again, as it will still not fit.
Moreover, the calculated width for a hidden element is not always
accurate; in some cases the calculated width is lower than the actual
width (it happens, for example, when using a background image like the
"Share" icon), which causea the crumb to be shown even if there is not
enough room, which in the end causes the siblings to overflow the
contents.
No unit tests for this one, though; you will have to trust me on this,
sorry ;-)
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The crumb for the menu was shown like any other crumb when calling
"_showCrumb", but it was also shown when other crumbs were hidden
without taking into account the available width. This caused several
related problems, like the breadcrumbs taking too much space when the
menu was sometimes shown after the rest of the crumbs were adjusted to
the available width, or the menu being shown instead of the last crumb
even if there was room for it when the available width was increased.
Now the menu is always hidden before starting the resizing of the crumbs
to ensure that whether it was previously shown or not does not affect
the result. In a similar way, the menu will no longer be shown by
"_showCrumb", as it is not a regular crumb that has to be shown simply
if there is enough room. The menu is now shown as soon as any other
crumb is hidden; this ensures that the menu width will be taken into
account in further width checks. As when _updateMenu" is called it no
longer needs to take care of showing the menu this fixes the issue
revealed when fixing the test setup in the previous commit.
Finally, this implicitly fixes the failure in the breadcrumbs tests when
run on Firefox, as it was caused by the menu interfering in the
calculations of the other crumbs when increasing the width.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "Shows only items not in the breadcrumb" test was failing when run
on Firefox, but not on PhantomJS. This was caused by the differences in
the starting width between both browsers and an incorrect setup of the
test (the width set for the crumbs was overriden when the breadcrumbs
were rendered again, and the breadcrumb was resized to 300 from an
indeterminate initial width).
Now the crumbs are rendered and then its width, padding and margin are
set to a known value. Then it is resized to 1000px, which ensures that
there will be enough room for all the crumbs and thus the menu will be
hidden, and finally it is resized to 300, which causes the middle crumb
to be hidden and the menu to be shown.
Note, however, that the test now always fails, no matter if it is run on
PhantomJS or on Firefox; if the menu crumb is hidden when "_updateMenu"
is called it will show it, but it will also wrongly try to add the menu
itself to the menu. As the "crumb-id" of the menu crumb is "-1" this
causes the last regular crumb to be added to the menu. This will be
fixed with other related issues in the next commit.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When calculating the total width of the crumbs only its padding was
taken into account; now the margin is too. In a similar way, before
showing a crumb only its width was taken into account; now its padding
and margin are taken into account too.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This ensures that the resize tests do not depend on the values set in
the CSS files.
Note that this change causes a test to fail with Firefox, but not with
PhantomJS. This is due to a difference in the starting width used by
Firefox and by PhantomJS, and it will be fixed in a following commit.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the parent element of the breadcrumbs was resized to a larger width
and the siblings of the breadcrumbs expanded to fill all the available
width some crumbs could be hidden even if there was enough room for
them. The reason was that the width of the siblings being used to
calculate the available width for the breadcrumbs was the expanded width
of the siblings. Now as many crumbs as possible (that is, fitting in the
parent, no matter the siblings) are first shown so the expanding
siblings are compressed before calculating the available width.
Due to the lack of support for flexboxes in PhantomJS the related unit
test is skipped; it has to be run in other browser, like Firefox.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Other apps could add elements to the controls outside the creatable
actions div (for example, the button to switch to the gallery), so the
widths of all the visible siblings of the breadcrumbs have to be taken
into account in the size calculations.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
There are some differences in width handling between the browsers used
to run the tests, most likely due to their support (or lack of) of
certain CSS features: PhantomJS requires "width" to be set (probably
because it does not handle flex displays and treats it like a block, so
"min-width" does not matter in this case), while Firefox requires
"min-width" to be set (otherwise the children of "#controls" could be
compressed due to its use of flex display and the elements would end
with a different width than the one needed for the tests). Due to all
that the width of the breadcrumb siblings must be specified in the tests
using both "width" and "min-width".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
There is no need to call "setDirectory" again in resize tests; it is
enough to simply resize them (and isolates them better to just test the
resizing behaviour).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "usedWidth" attribute was not used elsewhere outside the "_resize"
method, so it was replaced with a local variable. Moreover, it was also
renamed to a more suitable name ("availableWidth").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Setting the width of the parent element of the breadcrumbs and then
explicitly calling "_resize" is enough to test the resizing behaviour.
This makes possible to remove the "setMaxWidth" method and its related
code, which was used only for testing purposes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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 the favourite icon in the details view is clicked the "Favorite"
action is triggered. However, if the action name given to
"triggerAction" is not found then the "Download" action is triggered
instead. As the "Favorite" action is not available in some file lists
(like "Recents") the "Download" action was executed instead in those
cases, which was a strange behaviour. Now the favourite icon is
hidden if its action is not available.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The selected files summary shown in the multiselect header has a margin
to align it with the names of the files in the contents of the file
list. However, on very narrow screens, and depending on the verbosity of
the language, the summary can overlap with the actions when the
selection contains files and folders. To try to mitigate this, besides
showing only the icons for the actions, the summary margin is removed
too in very narrow screens.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
On narrow screens only the action icons are shown in the multiselect
header of the file list. In that case the padding of those icons is
increased to provide a larger touch area (the padding used is the same
as in the inline actions of the file list).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixes#7539
Also fixes overlap of text on mobile devices by resorting to just icons on lower resolutions.
Signed-off-by: Abijeet <abijeetpatro@gmail.com>
Some parts of the file list contents (file name and actions) had a
higher z-index than the file list multiselect header. That header is
fixed in place, so when the file list contents were scrolled and those
parts with a higher z-index overlapped the multiselect header they were
fully visible. Now the z-index for the multiselect header has a higher
value (the same used in the controls bar) to ensure that the contents
are shown behind the header.
Fixes#7540
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>
Clicking on an empty space in a file row causes the details view to be
shown. As it is a user initiated action on the file list now it is done
by triggering the Details action instead of directly calling
"_updateDetailsView"; the result is the same in both cases, but using
the action is more consistent (clicking on the file name triggers the
default action, and clicking on the inline actions triggers those
actions) and also makes possible to use the "beforeTriggerAction" and
"afterTriggerAction" listeners.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In the same way that other elements can know when a FileAction is
registered or a default action is set this commit makes possible to be
notified before and after a FileAction is executed.
This is achieved by wrapping the registered action handler in a custom
function that notifies the listeners before and after executing the
handler itself. Due to this approach only FileActions registered through
"registerAction" trigger the events, although that is not a problem as
this is how the actions should be added to the FileActions anyway.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a file from the file list is dragged a drag shadow (a copy of the
file row that follows the cursor position) is created. The drag shadow
element is created as a direct child of the body element, so it needs a
higher "z-index" than the one used for the file list to be visible.
In narrow screens the "#app-content" uses a "z-index" of 1000 in order
to be visible over the "#navigation-bar" when they overlap, so the
"z-index" of the drag shadow must be at least 1000 to be visible over
the file list.
Instead of updating the hardcoded "z-index" it was removed and replaced
by CSS rules for ".dragshadow" elements to ease theming.
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>
In case of error, instead of a generic error message, an upload will
display whichever message is returned in the Sabre Exception, if
applicable.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This commit adds chunked uploads in the Web UI (for authenticated users,
but not for public uploads). To do that the server endpoint used by the
uploader is changed from WebDAV v1 to WebDAV v2. The chunking itself is
done automatically by the jQuery-File-Upload plugin when the
"maxChunkSize" parameter is set; in "fileuploadchunksend" the request is
adjusted to adapt the behaviour of the plugin to the one expected by
"uploads/" in WebDAV v2.
The chunk size to be used by the Web UI can be set in the
"max_chunk_size" parameter of the Files app configuration. By default it
is set to 10MiB.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The Details and the Favorite actions do not require any permission on
the files to be performed.
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>
Now that the checkbox was moved to its own column clicking on the
thumbnail should behave like clicking on the file name. To achieve this
the left position was replaced with a padding, so the element is kept at
the same place while extending its clickable area to cover the
thumbnail.
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 "has-favorites" CSS class is no longer used after moving the
favorite mark to the top right corner of the thumbnail, so there is no
need to add it to the table.
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 checkbox is not shown always with full opacity, though, in order to
reduce the visual noise (specially later, once the checkbox is moved to
its own column).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is a preparatory step for a following commit in which the position
of the favorite icon and the checkbox will be swapped; in that new
design the favorite icon is no longer expected to be an action but just
a simple mark on whether the file is favorited or not (the action is
expected to be triggered then only from the file actions menu).
The favorite icon is now fully shown or completely hidden depending on
whether the file is favorited or not. As the icon is just informative
but no longer an action now it does not change when hovered or focus. In
the same way, the alternative text when the file is not favorited now it
is not "Favorite" (an action) but "Not favorited" instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The new FileAction for the menu is essentially the same as the old
inline FileAction, except for the rendering; in this case the FileAction
is shown in the menu in a standard way, so there is no need to provide a
custom renderer (although the menu entry text and icon change depending
on whether the file is currently a favorite or not, but that can be done
just with displayName and iconClass functions).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Icon class function properties make possible to render a different icon
class depending on the context of the file action.
Inline file actions had support for them already and called them passing
the file name and context of the file action as parameters. Due to this
the FileActionsMenu passes those parameters too to icon class functions
instead of just the context like done for display name functions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The helper funtion did not handle the response correctly and basically
only returned the last share with tags.
This is a simple rewrite. That is still understandable. Loops maybe more
than strictly required. But preformance is not the issue here.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If the estimated upload time is bigger than 4 hours it shows the text
"Uploading..." because the time then doesn't give any good hint to the
user anyways.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Just fetch the first 10kb. This should be more than enough in 99% of the
cases. And avoid downloading a 10mb text file just to display a tiny
portion.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
The unit of `data.bitrate` is bit, but the argument unit of
`humanFileSize` function is byte, so it should be divided by 8.
Signed-off-by: Yaojin Qian <i@ume.ink>
The upload remaining time is always 'a few second' whatever a big or a
small file uploading.
This commit fixes it. The `new Date().getMilliseconds()` only return a
three digits number. When time arrived the next second, the millisecond
start from ZERO again. So `new Date().getTime()` is the righe choice.
And remaining time variables shoule be initialized when the file starts
uploading, otherwise the remaining time of a new upload will always be
'Infinity years' until you refresh the page.
Signed-off-by: Yaojin Qian <i@ume.ink>
The post-render event makes possible to modify the
MainFileInfoDetailsView element once it has been rendered, which is
needed by OCA.SystemTags.FilesPlugin to add the "Tags" label to the file
details, while the pre-render event makes possible to detach added
elements if needed before the MainFileInfoDetailsView is rendered again,
as that removes the events from the child DOM elements even if they
belong to other views.
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>
Whenever a file list is already initialized and was hidden when
switching to another file list in the navigation bar, if the user comes
back to this list it gets redisplayed. At this point the list needs to
be refreshed to be able to reflect any potential file changes done from
the other lists.
The Files app active view is set to "files" in silent mode to avoid an
unneeded load of the "/" directory. However, this also prevents the
details view from being automatically closed, so it has to be explicitly
closed by the Goto plugin; the approach used is the same that would have
been used by OCA.Files.App._onNavigationChanged if not silenced.
Fixes#1448
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Calls to `sinon.stub(obj, 'meth', fn)` are deprecated and therefore
replaced by `sinon.stub(obj, 'meth).callsFake(fn)` as instructed by
the deprecation warning.
This makes the js unit testing output readable again.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* fix mess with menus and actions in the files app
* reduces amount of !important usages
* keeps the behaviour on mobile as well as on desktop
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
The local link is a clever thing and the clients should support this imho but it might not be clear to all users. For one, the term 'local link' is a bit odd. Local with respect to what? It links directly to the file or folder, so direct link seems to make more sense to me. And we should explain the difference with a public link. So this PR:
* renames local link to direct link
* adds a short explanation, noting it only works for users who have access to this file/folder.
As other links are called public link you could also consider calling this 'private link', I suppose. But the links we sent by mail to ppl could also be called 'private link' (they are for one user, who git it by email) so I think it might be confusing. What do @nextcloud/designers think?
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
John Molakvoæ (skjnldsv)
fnuesse
fnuesse
Nextcloud bot
Arthur Schiwon
Roeland Jago Douma
Robin Appelman
Morris Jobke
Kevin Ndung'u
Abijeet
John Molakvoæ
Daniel Calviño Sánchez
Blaok
Julius Härtl
Roeland Jago Douma
Jan-Christoph Borchardt
Sagorika Das
Joas Schilling
Marin Treselj
Roland Tapken
Julius Härtl
Vincent Petry
Thomas Müller
Tobias Kaminsky
Bjoern Schiessle
Lukas Reschke
Christoph Wurst
Bernd Stellwag
Markus Staab
rakekniven
Chon Kou
Thomas Citharel
Bekcpear
Patrik Kernstock
Phil Davis
Christoph Wurst
Jos Poortvliet