When the user is created, the provisioning api
was not adding the email address of the user
when provided if the `send email to new user`
is not set.
Signed-off-by: Sujith Haridasan <sujith.h@gmail.com>
because moving to trash can take a long time, keeping a transaction active for the duration can lead to issues
Signed-off-by: Robin Appelman <robin@icewind.nl>
When asking for sharees we compare not only UID and displayname but also
the email address. And if that matches we return the sharee as an exact
match. This logic had a flaw as in that it also matched the empty string
to users with no email address.
This is most noticeable when you disable sharee enumeration and open the
ownership transfer dialog. It suggested other users of the instance
before. This has stopped now.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Before when you have a user "smith" and a federated user "smith@example.com"
you could see the federation result with "smit" but not with "smith" anymore.
With most LDAP configurations and local backend setups this is disturbing and
causes issues.
The idea of not showing the email and federation on a matching user was with:
Local user registered with "smith@example.com" user id and having that same
email / cloud id in your contacts addressbook. So we now only hide those
"side results" when the search does contain an @
Signed-off-by: Joas Schilling <coding@schilljs.com>
TypeError: strpos() expects parameter 1 to be string, int given
The problem is that in cacheNode() we strip of any slashes, so
a folder "0/" will be trimmed to "0" and be used as an array key.
Since PHP automatically casts numeric array keys to integers,
you afterwards get $nodePath as int(0). Since it's now a number,
the strpos() function does not accept it anymore. Simply casting
$nodePath to a string again in the foreach solves the issue
Signed-off-by: Joas Schilling <coding@schilljs.com>
- they show up previously with / typed – end user needs to know about it
- inconsistent with some other fields, that show it directly
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Until recently (it was fixed in ac2999a26a) when a path was transferred
other shares with the target user were removed, so a test was added to
ensure that it does not happen again.
Besides that a test to ensure that other files with the target user are
not transferred was added too (it did not fail before, but seemed
convenient to have that covered too :-) ).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The files:transfer-ownership performs a sanitization of users with
"risky" display names (including characters like "\" or "/").
In order to allow (escaped) double quotes in the display name the
regular expression used in the "user XXX with displayname YYY exists"
step had to be adjusted.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently only transferring ownership of a reshare with a group to a
user in the group is possible.
When transferring ownership of a reshare with another user or with a
group to a user not in the group restoring the share fails (but the
command succeeds, it only fails for the specific files that are
reshares).
When transferring ownership of a path that is a reshare the command
fails (as when a specific path is provided the path tries to move the
file, it does not take into account reshares).
The added integration tests reflect the above behaviours.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The integration tests did not verify that the shares were actually
transferred between the users (or that they were removed due to being
transferred to the sharee).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Sujith Haridasan
mrtnmtth
Robin Appelman
Nextcloud bot
Roeland Jago Douma
Roeland Jago Douma
Joas Schilling
Julius Härtl
Christoph Wurst
Joas Schilling
Arthur Schiwon
Daniel Calviño Sánchez
John Molakvoæ (skjnldsv)