Until now the password to be sent by mail was set by enabling a checkbox
in the share menu and then entering the password in an input field shown
below. Now, when Talk is enabled, another item is added to the share
menu to do the same for a password to be sent by Talk.
Sending the password by mail and sending it by Talk are mutually
exclusive actions, so when one of the checkboxes is enabled the other
one is automatically disabled.
Note that the icon set for the field, "icon-passwordtalk", does not
currently exist; it simply mimics the "icon-passwordmail" (which does
not exist either) used for the field of the password protect by mail to
get the right padding in the menu.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The escaping of special characters was needed when the ids of the
permission checkboxes for shares were based on the "shareWith" field.
Since they are based on the "shareId" field the escaping is no longer
needed, as the "sharedId" is expected to always contain compatible
characters.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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, the avatar for a circle share was generated using the
"share_with" field as the seed for "imageplaceholder". Due to this, when
the "share_with" field is set to the circle ID the character shown in
the avatar was just a random character instead of the first character of
the display name. Now the "share_with" is still used as the seed for the
colour, but the display name is used as the text of the avatar.
This adds support for "share_with" fields set to the circle ID while
being backwards compatible with "share_with" fields set to the circle
name.
Note that when "share_with" fields is set to the circle name the colour
of the avatar is different in the list of suggested sharees and in the
list of current sharees, but that also happened before these changes
(due to a different seed being used in each place).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Also, the checkbox is updated to the correct state while a
permission change is in progress.
should fix issue #8371
Signed-off-by: Maximilian Wende <dasisdormax@secure.mailbox.org>
the contacts popovermenu is also present and is being replaces, ending
up in two permission popupmenus with checkboxes duplicating the id,
breaking further permission changes.
plus, fixing a selector
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Fixes#1330
userA shares a file to userB
userB shares that file to userC
userA can see both userB and userC.
Now they can also see that userB shared it to user C
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>