Move this to the private implementation in OC, so that using IRootFolder
in apps doesn't require dummy stubs.
This will create a new psalm warnings for users of this method but
considering that this is deprecated for a long time and that it still
works at runtime, this shouldn't cause any issue.
Signed-off-by: Carl Schwan <carlschwan@kde.org>
When implementing this for user_saml, I noticed that we do need to make
the return value nullable as otherwise there are no way for this feature
to be optional for the admin.
Signed-off-by: Carl Schwan <carlschwan@kde.org>
Use the class/interface name instead to avoid logging.
This was breaking in some cases as logging would trigger a deprecation
warning, resulting in an infinite loop.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
Shares using the OCM multi-protocol envelope (name multi, with the secret carried in a sibling protocol entry such as webdav) were rejected with Missing sharedSecret in protocol. Scan every protocol entry for the shared secret during validation, resolve the secret from the matching entry, and let the files provider serve the webdav entry of a multi envelope. Covers the file and folder resource types.
Signed-off-by: Micke Nordin <kano@sunet.se>
The new public IManager::claimNextScheduledTask lands in master (35.0.0),
not 34.0.0. Addresses review feedback.
Signed-off-by: Yoan Bozhilov <bygadd@gmail.com>
Assisted-by: Claude Code:claude-opus-4-8
- `$child` was used as an array key earlier. If they are numeric, they
are automatically converted to ints, leading to type issues later.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Current code blindy adds any resources to the ocm disocvery, this makes
it so that different cloud federation providers can not add different
protocols for the same resourceType without the resourceType being
duplicated, something that OCM does not allow:
```
REQUIRED: resourceTypes (array) - A list of all resource types this
server supports in both the Sending Server role and the Receiving
Server role, with their access protocols. Each item in this list MUST
itself be an object containing the following fields:
name (string) - A supported resource type (file, calendar, contact, ...).
Implementations MUST offer support for at least one resource type, where
file is the commonly supported one. Each resource type is identified by
its name: the list MUST NOT contain more than one resource type object
per given name.
...
```
https://datatracker.ietf.org/doc/html/draft-ietf-ocm-open-cloud-mesh-04#name-fields
This patch changes this behaviour from this example result:
```
{
"name": "folder",
"shareTypes": [
"user"
],
"protocols": {
"webapp": {}
}
},
{
"name": "folder",
"shareTypes": [
"user"
],
"protocols": {
"webapp-receive": {
"targets": [
"blank",
"iframe"
]
}
}
```
to:
```
{
"name": "folder",
"shareTypes": [
"user"
],
"protocols": {
"webapp": {},
"webapp-receive": {
"targets": [
"blank",
"iframe"
]
}
}
```
which is the correct behaviour according to OCM.
Signed-off-by: Micke Nordin <kano@sunet.se>