The comparisson of NULL is a bit special.
So we need to handle this a tad beter else it might not replace NULL
values. or allow you to set NULL values on updates.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This is within the failed lock acquiring branch. So the lock is free by another process and should not be removed because the cached file (that was created by the process having the lock) appeared on the filesystem.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
The QBMapper is kind of a generic type, though this concept does not
exist in php. Hence you have a lot of type coercion in subtypes (mappers
in the individual apps) because you suddenly don't expect an Entity[]
but your specific type.
Luckily Psalm lets us type those. Then in the subclass you can
psalm-implement the mapper with a concrete type and psalm will do all
the magic to ensure types are used correctly.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
On some systems with a lot of users this creates a lot of extra DB
writes.
Being able to increase this interval helps there.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.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>
Since we try to do range requests this will fail hard.
However since empty files are not that interesting to read anyways we
just read from an emptry memory stream.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Julius Härtl
Morris Jobke
Nextcloud bot
Arthur Schiwon
Roeland Jago Douma
Christoph Wurst
Roeland Jago Douma
Joas Schilling
korelstar