When Talk is enabled the menu for link shares now shows a checkbox to
protect the password by Talk (that is, to show the "Request password by
Talk" UI in the authentication page for the link share).
Although in e-mail shares protecting the share with a password and
protecting the password by Talk are mutually exclusive actions (as when
the password is set it is sent to the sharee, so it must be set again
when protecting it by Talk to be able to verify the identity of the
sharee), in the case of link shares protecting the password by Talk is
an additional step to protecting the share with a password (as just
setting the password does not disclose it to anyone). As such, the
checkbox is shown only when there is a password set for the link share
(even if the field itself for the password is not shown, like when they
are enforced in the settings).
Note that the icon set for the field, "icon-passwordtalk", does not
currently exist; it is the same used for e-mail shares, and it is needed
simply to get the right padding in the menu.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Hiding the download does not depend on other settings and it does not
affect other settings either (for example, it would be possible to hide
the downloads yet make the share editable), so a simple checkbox was
added to the menu. However, note that this option is only available for
files, but not for folders.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
humanFileSize: add test with locale
humanFileSize: use canonical locale
humanFileSize: skip test w/o toLocaleString support
humanFileSize: stub getCanonicalLocale
OC.getCanonicalLocale: cover undefined case
humanFileSize: fix getCanonicalLocale stub
Signed-off-by: Claas Augner <git@caugner.de>
No more weird eval to construct a plural function.
We just use the plural function from symfony.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The check is based on the HTTP status returned by the URL, and different
URLs may return different status (for example, DAV returns 207, while
a service like WebFinger would return 200), so the expected status needs
to be set depending on the URL.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Improved the speed of isOpcacheProperlySetup() (instant return instead of continuing when we're already failed), added a check for the opcache extension itself. Potentially fixes#9410
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
The ids of permission checkboxes for shares were generated using the
"shareWith" field of the share. The "shareWith" field can contain spaces
(as spaces are allowed, for example, in user or circle names), so this
could cause the id attribute of the HTML element to contain spaces too,
which is forbidden by the HTML specification.
It is not just a "formal" issue, though; when the list was rendered, if
the id contained a space the selector to get the checkbox element was
wrong (as it ended being something like
"#canEdit-view1-name with spaces") and thus the initial state of the
checkbox was not properly set.
Besides that, "shareWith" can contain too single quotes, which would
even cause the jQuery selector to abort the search and leave the UI in
an invalid state.
Instead of adding more cases to the regular expression to escape special
characters and apply it too when the ids are created now the ids of
permission checkboxes for shares are based on the "shareId" field
instead of on "shareWith", as "shareId" is expected to always contain
compatible characters.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, whenever a pending operation (getting the suggestions,
confirming a share or selecting a recipient) finished the working icon
was hidden and the confirm button was shown again, even if there were
other pending operations (the most common case is typing slowly on the
input field, as several operations to get the suggestions could pile if
the server response is not received fast enough). Now, the working icon
is not hidden until the last pending operation finishes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a share is confirmed the suggestions are got to check if there is
an exact match. Usually the suggestions were already got with the same
parameters in order to fill the autocomplete dropdown, so to avoid a
superfluous request now the last suggestions are reused when got again,
although only if the same parameters as the last time are used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Besides confirming a share by clicking on the confirm button now it is
possible to do it by pressing enter on the input field.
Clicking on the confirm button implicitly hides the autocomplete
dropdown. On the other hand, pressing enter on the input field does not,
so the autocompletion must be disabled and closed when the confirmation
begins and then enabled again once it finishes. Otherwise the
autocomplete dropdown would be visible and it would be possible to
interact with it while the share is being confirmed.
The order in which the input field and the autompletion are disabled is
important. Internally, the autocompletion sets a timeout when the input
field is modified that requests the suggestions to the server and then
shows them in the dropdown. That timeout is not cancelled when the
autocompletion is disabled, but when the input field loses its focus and
the autocompletion is not disabled. Therefore, the input field has to be
disabled (which causes it to lose the focus) before the autocompletion
is disabled. Otherwise it could happen that while a share is being
confirmed the timeout ends, so an autocompletion request is sent and
then, once the share is successfully confirmed and thus the
autocompletion is enabled again, the request is received and the
autocomplete dropdown is shown with the old suggestions. Strange, but
possible nevertheless ;-)
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Clicking on the confirm button now adds a share, but only if there is
just a single exact match. If there are no exact matches or there is
more than one exact match no share is added, and the autocomplete
dropdown is shown again with all the suggestions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"_getSuggestions" returned all the suggestions from the server, which
are composed by exact matches and partial matches. Now the exact matches
are also returned on their own parameter. This will be used by the
button to confirm a share.
Note that until now the order of the suggestions was "exact users,
partial users, exact groups, partial groups, exact..."; this commit also
changes that order to become "exact users, exact groups, exact...,
partial users, partial groups, partial...". This is not a problem, as
the suggestions were used in the autocomplete dropdown, and this new
order is arguably better than the old one, as all exact matches appear
now at the beginning.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Calviño Sánchez
Morris Jobke
John Molakvoæ (skjnldsv)
Julius Härtl
Claas Augner
Claas Augner
Daniel Peukert
Roeland Jago Douma
Moritz Beck
Christoph Wurst
Joas Schilling
Arthur Schiwon
Timo Förster
Michael Weimann
Joas Schilling
Roeland Jago Douma
Cthulhux
Bjoern Schiessle
Maxence Lange