Groupware capabilities

[kulmann]

Initial Checklist

• I understand this is a user story and questions should be posted in the Community Discussions
• I searched issues and couldn’t find anything (or linked relevant results below)

User Story

• As a web dev I want to know which groupware components are available so that I can develop a personalized UX.

User Value

Groupware app bootstrapping

Acceptance Criteria

• capabilities have a new property groupware which has content similar to:

"groupware": {
  "enabled": true
}

This capability needs to be added to reva and the enabled variable should be configurable via environment variable

• opencloud default: groupware.enabled = false
• web dev stack: groupware.enabled = true
• if groupware is enabled, fetch the groupware meta endpoint <serverUrl>/groupware as part of the web bootstrap (similar to how we load all project spaces initially)
• meta endpoint gives information like e.g. the list of accounts and which one the default mail account is or the endpoint for the unified inbox (needed for Mail listing #1244 )
• persist in a pinia store and build a zod schema

[kulmann]

@pbleser-oc could you add details about the /groupware endpoint? Just pasting an example response in the current shape as comment to this issue would be sufficient for me. Is it ok to call it metaUrl in the context of OpenCloud capabilities, or do you have a better name?

[pbleser-oc]

Current state of the GET /groupware endpoint:

{
    "version": "0.0.1",
    "capabilities": [
        "mail:1"
    ],
    "limits": {
        "maxSizeUpload": 50000000,
        "maxConcurrentUpload": 4,
        "maxSizeRequest": 10000000,
        "maxConcurrentRequests": 4
    },
    "accounts": {
        "b": {
            "name": "Alan Turing",
            "isPersonal": true,
            "isReadOnly": false,
            "capabilities": {
                "mail": {
                    "maxMailboxDepth": 10,
                    "maxSizeMailboxName": 255,
                    "maxMailboxesPerEmail": 0,
                    "maxSizeAttachmentsPerEmail": 50000000,
                    "mayCreateTopLevelMailbox": true,
                    "maxDelayedSend": 2592000
                },
                "sieve": {
                    "maxSizeScriptName": 1048576,
                    "maxSizeScript": 1048576,
                    "maxNumberScripts": 256,
                    "maxNumberRedirects": 1
                }
            },
            "identities": [
                {
                    "id": "b",
                    "name": "Alan Turing",
                    "email": "alan@example.org",
                    "mayDelete": true
                }
            ]
        }
    },
    "primaryAccounts": {
        "mail": "b",
        "submission": "b",
        "blob": "b",
        "vacationResponse": "b",
        "sieve": "b"
    }
}

As for every other /groupware/* request, it is required to be authenticated, via OIDC (Bearer with a JWT), same as for all the other services.

I currently didn't add any information about additional endpoints as I am assuming that the API is well-known to the client.

There are pros and cons to doing so, in my opinion, the only real benefit being that the backend (or a middleware or ingress in-between) can tell the UI which backend URI to use in a sharded cluster (e.g. GET https://groupware.opencloud.eu/ -> {"next": "https://groupware03.opencloud.eu"}, but that also makes up for a little more complexity on the backend, since it needs to know its hostname in the URL.

The endpoint to retrieve the "latest X emails from all accounts" is currently

GET /groupware/accounts/all/emails/latest/summary?limit=10

But if you prefer refs to endpoints in the initial bootstrap/meta response (to GET /groupware), we can flesh that out.