Add icon hints to share role descriptions

[felix-schwarz]

Is your feature request related to a problem? Please describe.

Clients that want to display an icon to visualize a share role currently have to hardcode a table that maps role UUIDs to icon names locally, as can be seen here:

• https://github.com/owncloud/web/blob/b7fc548b3c6126c6e31076b9a087dd58cd3d7ee3/packages/web-runtime/themes/owncloud/theme.json#L11 (web)
• https://github.com/owncloud/ios-sdk/blob/ad69656aa163e5b65fb096adde6b67aff3eb616b/ownCloudSDK/Share/Roles/OCShareRole.m#L51 (iOS SDK)

IMO it counters the idea of having share roles returned by the server if clients still have to maintain and ship a list of role UUIDs to be able to "recognize" them and to present them in a visually appealing manner.

Describe the solution you'd like

The UnifiedRoleDefinitions returned by the permissions endpoint should add an extra property that provides hints as to which icon the client should use, like f.ex. eye, pencil, upload, shield.

A standard set of these icon names should be defined, so that clients can map them to local assets.

In order to allow new icons to be added over time, the icon hints should be provided as an array, with clients picking the first icon they know.

Put together, this could look like this:

{
  "@libre.graph.permissions.roles.allowedValues": [
    {
      "@libre.graph.weight": 1,
      "description": "Ansehen und herunterladen.",
      "displayName": "Kann anzeigen",
      "iconHints": [ "eye" ],
      "id": "b1e2218d-eef8-4d4c-b82d-0f1a1b48f3b5"
    },
    {
      "@libre.graph.weight": 2,
      "description": "Ansehen, herunterladen und hochladen.",
      "displayName": "Kann hochladen",
      "iconHints": [ "upload-folder", "upload" ],
      "id": "1c996275-f1c9-4e71-abdf-a42f6495e960"
    },
    {
      "@libre.graph.weight": 3,
      "description": "Ansehen, herunterladen, hochladen, editieren, hinzufügen, löschen.",
      "displayName": "Kann bearbeiten",
      "iconHints": [ "pencil" ]
      "id": "fb6c3e19-e378-47e5-b277-9732f9de6e21"
    }
  ],
...

In this example the role with ID 1c996275-f1c9-4e71-abdf-a42f6495e960 introduces a new icon, upload-folder that older clients may not yet know. These clients can then fall back to the icon they have stored for upload.

Likewise, the server can introduce new roles and use the existing pool of icon hints - and clients will be able to show an icon for them without the need for source modification or a new release.

[2403905]

We could do it, but we should update the UnifiedRoleDefinition definition in a libre-graph https://github.com/owncloud/libre-graph-api-go/blob/fa3804be6c27a2862812ffd75c9e01a395f8d335/model_unified_role_definition.go#L21 Let's wait for @kobergj, and I'll discuss it with them.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[kobergj]

@felix-schwarz currently the icons are configured in the /themes/owncloud/theme.json. The icon is not really an object of the graph API, it fits better to the themes. Can you take the info from there?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[felix-schwarz]

@kobergj I see your point and while it's a possibility to pull it from theme.json, that would

• require the client to piece this together, introducing additional complexity (an additional HTTP request + parsing / mapping icon names)
• introduce a dependency on an implementation detail of the web client that could be subject to change :-/ (including, possibly, the path/location of the web client?)

In https://github.com/owncloud/enterprise/issues/7320 a customer uses their own share roles with new UUIDs that the iOS client hasn't built in - and now complains about the lack of icons. I was able to extract the UUIDs for the two new roles from HTTP responses, but since/while I'm touching this code again, it would be great to have a stable/future-proof solution for this problem.