Skip to content

fix(ocm): merge resource types by name in discovery#61126

Open
mickenordin wants to merge 2 commits into
masterfrom
kano-fix-ocm-discovery
Open

fix(ocm): merge resource types by name in discovery#61126
mickenordin wants to merge 2 commits into
masterfrom
kano-fix-ocm-discovery

Conversation

@mickenordin

@mickenordin mickenordin commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

Summary

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.

Checklist

  • Sign-off message is added to all commits
  • Tests are included
  • Documentation has been updated or is not required

AI (if applicable)

  • The content of this PR was partly or fully generated using AI

@mickenordin mickenordin requested a review from a team as a code owner June 9, 2026 20:25
@mickenordin mickenordin requested review from ArtificialOwl, CarlSchwan, leftybournes and provokateurin and removed request for a team June 9, 2026 20:25
@mickenordin mickenordin force-pushed the kano-fix-ocm-discovery branch from 07a1c6b to c0461ed Compare June 9, 2026 20:40
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>
Assisted-by: ClaudeCode:claude-fable-5
Signed-off-by: Micke Nordin <kano@sunet.se>
@mickenordin mickenordin force-pushed the kano-fix-ocm-discovery branch from c0461ed to d5c56b8 Compare June 10, 2026 07:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants