We cache the values we set in the setUserValue function.
However since the values are strings in the database we check if a value
is equal with string comparison
Now if the function was called with a $value of int or float. It would
be stored in the DB (and thus converted to string) and in the cache (not
converted thus as int/float).
Now if another call comes in that sets it to the same value (I'm looking
at you LDAP!). The check would fail since we would be comparing
int/float to string which fails by definition.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
There were two routes apps/files/ajax/download.php but apparently also
apps/files/download.php I could not find any use of it.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
When a share is shared with a circle the "share_with" field returned by
the API endpoint was always set to the name of the circle. However, the
name is not enough to identify a circle. The Circles app now provides
the ID of the circle in the "shared with" field of a Share, so this
commit modifies the API endpoint to set the "share_with" field to the ID
of the circle when provided by the Circles app.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
