test creating comments with numeric user ids
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
fix creating comments when file is accessible to users with numeric ids
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
tests for systemtags related to numeric user ids
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
fix systemtags event with numeric user ids
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
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 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>
Currently, the theming app assumes it's in the serverroot. However, with
Nextcloud's flexibility regarding configurable app paths, this is not a
safe assumption to make. If it happens to be an incorrect assumption,
the theming app fails to work.
Instead of relying on the serverroot, just use the path from the
AppManager and utilize relative paths for assets from there.
Fix#8462
Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
* adds a 107 error code together with the hint of the exception
* logs the exception as warning
* fixes#7946
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Exposing the encrypted property is required for E2E. However, there is
no need to expose this on files as then it is server side encryption
(which the clients don't care about).
Better to not confuse the output.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The clipboard icon in shared links appears either directly on the link
input field or, if any social sharing app is enabled, in a menu. The
clipboard icon uses the same CSS rules as other icons (like the
information icon) to be posioned on the end of the input field, and
those rules have to be "cancelled" when the icon is shown in the menu.
Fixes#7990
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
without recursion we have issues with internal states. paged search status
are set to false, cookies are not being set. In the end we have endless
requests which pile up enormously with a high initial offset.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
The message is not helpful anyway for an admin, and oftentimes is just
valid (e.g. when searching with an offset beyond users in LDAP).
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
To show the password in plain text "showPassword" adds a text input
after the password input and swaps their visibility depending on whether
the password has to be shown in plain text or not. In a similar way,
"strengthify" by default adds the strength bar after the input element
it was called on. Due to this, if "showPassword" is called before
"strengthify" on the same password input then the strength bar ends
between the password input and the text input, and when the text input
is shown it appears below the strength bar.
To fix this now the strength bar is added after the text input in those
places in which "strengthify" was called after "showPassword" on the
same element.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"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>
This fixes a regression caused by 9b668d0, where the css filters to
preview color inversion of the app menu was applied by default. This
commit makes the css filters sensitive on what the current state of the
app menu is.
Signed-off-by: Julius Härtl <jus@bitgrid.net>
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>
Fixes#7184
The SyncJob can be very resource intensive. Since it requests all users
on the system to create the system addressbook. In order to do this it
creates a vcard for every user and updates the addressbook.
There is no need for this job since the proper signals are emitted and
handled in the carddav backend to update the addressbook live.
Worst comes to worst there is always the occ command to bring the
address book in sync again.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When the checkbox was moved to where the favourite icon was shown before
the layout of the file list was modified. The checkbox is no longer a
descendant of the ".filename" element, so it is no longer removed by the
"External storages" file list.
However, even before the checkbox was moved, explicitly removing it was
not the best approach, as file list rows could still be selected using
"Ctrl/Shift+click". This did not provide much value, as the selection
header has no actions; it simply states the number of selected elements.
The proper way to disable the selection is by setting "_allowSelection"
to false in the file list instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the checkbox was moved to where the favourite icon was shown before
the layout of the file list was modified. The first column is no longer
the file name, so neither the thumbnail nor the name link were found.
Due to this the thumbnail was not set to the appropriate icon, and the
dummy event handler was not removed from the name link, so clicks on the
name were basically ignored. Now the selectors are based on the
".filename" CSS class instead of relying on the column position.
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>
The share menu toggle and some share menu items included an 'href="#"'
attribute, so they were handled as internal links by the browser, which
changed the current anchor when they were clicked. However, there was no
real need to change the anchor in those cases, and it could interfere
with other apps (for example, the PDF viewer sets the current anchor to
"#pdfviewer" when it is shown and it hides itself when that anchor is
modified). According to the HTML 5 spec the "href" attribute is not
mandatory for "a" elements, so they were removed.
Other options would have been to change the elements from "a" to "div"
or something like that, but that would have required changes to the CSS
rules too, or to prevent the default event handling for those elements
through JavaScript, which would have been a workaround instead of the
proper solution.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
Arthur Schiwon
Robin Appelman
Roeland Jago Douma
Nextcloud bot
rakekniven
Morris Jobke
Daniel Calviño Sánchez
John Molakvoæ (skjnldsv)
Julius Härtl
Kyle Fazzari
Marin Treselj
Roeland Jago Douma
Joas Schilling
Julius Härtl
Bjoern Schiessle
Abijeet