In some cases (for example you never send data to the lookup server)
there is no need for this job to even try.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
- saves an LDAP requests in these cases
- prevents a Protocol Error logged on < 7.3 API (for backports)
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
It was disabled by default for ages. And often resulted in unwanted
behavior. If admins want trusted servers they just have to do it
manually.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Due to a bug (fixed some commits ago) in the UsersController of the
settings app the scope of the properties can be null (for example, if
lookup server upload was disabled and the user then changed the display
name in the profile information). In that case now the scope menu icon
shows an error to inform the user.
The scope value will not change when other properties are modified until
the user chooses an explicit value from the menu. Note that until a
scope is explicitly set the property will behave as if it is private.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When upload to the lookup server is disabled the scope menu was hidden
in the personal information settings. However, even if the lookup server
upload is disabled the personal information is still accesible from the
local server as well as trusted servers. Users should be able to still
set if their information is available to other users or if it is
private, so now the scope menu is always show (although the "Public"
option is hidden if the lookup server upload is disabled).
If the user set the information as public before the upload to the
lookup server was disabled the menu will also show the "Public" option
as active, although disabled. Setting the visibility to any of the other
options will hide the "Public" option from the menu (until the lookup
server upload is enabled again).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"sendingAToWithRequesttoken" needs to be used to test some non OCS
endpoints which require the request token to be sent in the request. Now
it is possible to specify the body (or, rather, additional contents
beside the cookies and the request token) for those requests, as it will
be needed for example to update the user profile.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The controller can receive an optional subset of the properties of the
user settings; values not given are set to "null" by default. However,
those null values overwrote the previously existing values, so in
practice any value not given was deleted from the user settings. Now
only non null values overwrite the previous values.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"AccountManager::updateUser()" wipes previous user data with whichever
user data is given (except for some adjustments, like resetting the
verified status when needed). As the controller overrode the properties
those properties would lose some of their attributes even if they are
not affected by the changes made by the controller. Now the controller
only modifies the attributes set ("value" and "scope") to prevent that.
Note that with this change the controller no longer removes the
"verified" status, but this is not a problem because, as mentioned,
"AccountManager::updateUser()" resets them when needed (for example,
when the value of the website property changes).
This change is a previous step to fix overwritting properties with null
values, and it will prevent the controller from making unexpected
changes if more attributes are added in the future.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Right now it makes no difference, but this should make future tests
clearer, specially in case of failure.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Roeland Jago Douma
Morris Jobke
Roeland Jago Douma
Joas Schilling
Nextcloud bot
Julius Härtl
Robin Appelman
Arthur Schiwon
Lukas Reschke
Daniel Calviño Sánchez