Fixes#9279
If a pure numerical user is in the DB the value might be casted to a int
when returned. Cast it all to a string so we don't break the strict
typing.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Due to a misplaced closing parenthesis the condition of the left join
clause was just "userid = uid"; the other conditions were passed as
additional parameters to "leftJoin", and thus they were ignored.
Therefore, the result set contained every preference of each user
instead of only the email, so the "WHERE configvalue LIKE XXX" matched
any configuration value of the user.
Besides the closing parenthesis this commit also fixes the literal
values. Although "Literal" objects represent literal values they must be
created through "IExpressionBuilder::literal()" to be properly quoted;
otherwise it is just a plain string, which is treated as a column name.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixes#7175.
- Updated the query to fetch the users in users > everyone tab.
- Updated the query to fetch the users in users > admin tab.
- Tested to ensure that the disabled users are also being fetched.
- Added test cases.
Signed-off-by: Abijeet <abijeetpatro@gmail.com>
`\OC\User\Database::createUser` can throw a PHP exception in case the UID is longer than
permitted in the database. This is against it's PHPDocs and we should cast this to `false`,
so that the regular error handling triggers in.
The easiest way to reproduce is on MySQL:
1. Create user `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` in admin panel
2. Create user `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` in admin panel again
3. See SQL exception as error message
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
The constructor is iniitiated already very early in base.php, thus requiring this here will break the setup and some more. For now we probably have to live with a static function call here thus.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
For guest users on every request executes query:
SELECT `uid`, `displayname` FROM `users` WHERE LOWER(`uid`) = LOWER(null)
as I see, uid can't be equal to null by design.
We always query the database backend. Even if we use a different one
(ldap for example). Now we do this everytime we try to get a user object
so caching that a user is not in the DB safes some queries on each
request then (at least 2 what I found).
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Robin Appelman
Arthur Schiwon
Roeland Jago Douma
Daniel Calviño Sánchez
Abijeet
Morris Jobke
Lukas Reschke
Vincent Petry
Jörn Friedrich Dreyer
Loki3000
michag86
Joas Schilling
Bjoern Schiessle
Lukas Reschke
Roeland Jago Douma