Added additional capability in the provisioning API to signal whether
the federation scope values can be used.
This is based on whether the lookup server upload is enabled or not.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Include version number in capability
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Co-authored-by: Joas Schilling <213943+nickvergessen@users.noreply.github.com>
The fields for phone number, address, website and twitter are now
editable regardless whether federated sharing and the lookup server
are enabled or not.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Use new scope values in settings page.
Adjust all consumers to use the new constants.
Map old scope values to new ones in account property getter.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Now not all fields have the "v2-private" option in place.
Fix dropdown issue when a scope was stored that is not listed after
disabling the lookup server.
Whenever the lookup server upload is disabled, the scope menu is now
displayed where it makes sense to allow switching between the two private
scopes.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Added new v2-private account manager scope that restricts the scope
further by excluding public link access.
Avatars with v2-private account scope are now showing the guest avatar
instead of the real avatar.
Signed-off-by: Vincent Petry <vincent@nextcloud.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>
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>
- 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>
Nick Sweeting
Vincent Petry
Nextcloud bot
Roeland Jago Douma
Christian Weiske
John Molakvoæ
Valdnet
Morris Jobke
Robin Appelman
Joas Schilling
Sascha Wiswedel
Daniel Calviño Sánchez
Arthur Schiwon
John Molakvoæ (skjnldsv)