- 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>
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>
When an contact is moved to another address book, the contact is copied to
the second address book.
During copying, the birthday event is created - but it gets the same UID
as the contact's birthday event in the first address book.
To prevent the "Calendar object with uid already exists" error that followed,
we need to delete the old entry before the new one is created.
Resolves: https://github.com/nextcloud/server/issues/20492
Signed-off-by: Christian Weiske <cweiske@cweiske.de>
- allows to delete data of existing LDAP users, which otherwise is safe
guarded
- ensures that the user is not being deleted on LDAP through a plugin
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
some smb servers are very insistent in reporting that the root of the share is readonly, even if it isn't.
This works around the problem by adding a hidden option to overwrite the permissions of the root of the share.
This can be enabled using
```bash
occ files_external:config <mount id> root_force_writable true
```
where you can find your mount id using
```bash
occ files_external:list
```
Signed-off-by: Robin Appelman <robin@icewind.nl>
The remote URL of a share is always stored in the database with a
trailing slash. However, when a cloud ID is generated trailing slashes
are removed.
The ID of a remote storage is generated from the cloud ID, but the
"cleanup-remote-storage" command directly used the remote URL stored in
the database. Due to this, even if the remote storage was valid, its ID
did not match the ID of the remote share generated by the command and
ended being removed.
Now the command generates the ID of remote shares using the cloud ID
instead, just like done by the remote storage, so there is no longer a
mismatch.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
even thought we currently have no proper way of limiting the search itself, we can at least limit the construction of the result objects.
this saves about 40% of the time spend in the search request in my local testing
Signed-off-by: Robin Appelman <robin@icewind.nl>
Because the exceptions don't always contain a useful message for the UI,
but also because in some cases we need to find out what went wrong.
In some setups, a ShareNotFoundException might happen during creation
when we try to re-read the just written share. Usually related to Galera
Cluster where node syncing wait is not enabled.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Nextcloud bot
Arthur Schiwon
Morris Jobke
Julius Härtl
Roeland Jago Douma
Daniel Calviño Sánchez
Robin Appelman
Claas Augner
Vincent Petry
Valdnet
Roeland Jago Douma
Nick Sweeting
John Molakvoæ
Christian Weiske
Christoph Wurst