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>
Since all the compiled routes are based on the server webroot,
we have to use this, independent from which app this belongs to.
Signed-off-by: Joas Schilling <coding@schilljs.com>
When your password changes out of bounds your Nextcloud tokens will
become invalid. There is no real way around that. However we should make
sure that if you successfully log in again your passwords are all
updates
* Added event listener to the PostLoggedInEvent so that we can act on it
- Only if it is not a token login
* Make sure that we actually reset the invalid state when we update a
token. Else it keeps being marked invalid and thus not used.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Else we might run into the issue that for an external storage where the
size is not known yet we do not use zip64. Which then of course fails on
large zip files.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If the object store errors we should not always delete the filecache
entry. As this might lead to people losing access to their files.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Nextcloud bot
Christoph Wurst
Roeland Jago Douma
Joas Schilling
Roeland Jago Douma
Julius Härtl
korelstar
Arthur Schiwon
Morris Jobke
Robin Appelman