Groupware#1994
Conversation
pbleser-oc
added
Status:Needs-Review
Type:Organizational
Type:Maintenance
| curl -ks -D- -X POST \ | ||
| "https://keycloak.opencloud.test/realms/openCloud/protocol/openid-connect/token" \ | ||
| -d username=alan -d password=demo -d grant_type=password \ | ||
| -d client_id=groupware -d scope=openid |
There was a problem hiding this comment.
when working from top to bottom this fails. using a client_id=web works ... so I need to add a client id for the goupware somewhere ...
There was a problem hiding this comment.
I did add a JSON file devtools/deployments/opencloud_full/config/keycloak/clients/groupware.json, expecting it to be automatically picked up, but that might require re-creating the Keycloak container... ?
In any case, that was a beginner's mistake, there is really no reason to have a distinct client ID for the groupware, as the Web UI is going to use web instead.
Removed that config file and updated the documentation accordingly to use web instead, in cfbbe02
| to which one should receive the following response: | ||
|
|
||
| ```java | ||
| A OK [CAPABILITY IMAP4rev2 ...] Authentication successful |
There was a problem hiding this comment.
hm, I need to dig into:
stalwart-1 | 2025-12-10T16:07:05Z TRACE Raw IMAP input received (imap.raw-input) listenerId = "imaptls", localPort = 993, remoteIp = 172.39.0.1, remotePort = 45034, size = 19, contents = "A LOGIN alan demo\r\n"
stalwart-1 | 2025-12-10T16:07:05Z ERROR LDAP error (store.ldap-error) listenerId = "imaptls", localPort = 993, remoteIp = 172.39.0.1, remotePort = 45034, reason = "I/O error: Connection refused (os error 111)", causedBy = "crates/directory/src/core/dispatch.rs:25", id = "A"
| @@ -0,0 +1,49 @@ | |||
| package jmap | |||
There was a problem hiding this comment.
I think we should drop the jmap_ prefix from all files in this package
| AUTH_BASIC_LDAP_BIND_PASSWORD: "admin" | ||
| USERS_LDAP_BIND_PASSWORD: "admin" | ||
| GROUPS_LDAP_BIND_PASSWORD: "admin" | ||
| IDM_LDAPS_ADDR: 0.0.0.0:9235 |
There was a problem hiding this comment.
I configured everything on .compose.test to prevent collisions with my .opencloud.test deployment. The stalwart URL then needs to be set for the groupware:
| IDM_LDAPS_ADDR: 0.0.0.0:9235 | |
| IDM_LDAPS_ADDR: 0.0.0.0:9235 | |
| GROUPWARE_JMAP_BASE_URL: https://${STALWART_DOMAIN:-stalwart.opencloud.test} |
There was a problem hiding this comment.
oh and we need to set FRONTEND_GROUPWARE_ENABLED: "true" and enable the mail app in the web config when stalwart is enabled ... but that connot be configured with a simple env var ... 😞 we need to replace the config file then ...
There was a problem hiding this comment.
Ok, I still don't have a menu entry for mail in the web UI even though the config.json contains the mail app. I assume that is a problem with my setup/config. in any case, I can see the mail UI when navigation to {$OC_URL}/mail manually. \o/
I did run into some minor issues when following the docs. If you could address them (and enlighten me on how to get menu to show the groupware apps) I'm happy to merge this. I mostly want others to be able follow the DEVELOPMENT.md and have a working setup. Kudos for that, btw.
The groupware service itself follows our ... boilerplate ... service code ... and implements the JMAP handling. I assume that will have to evolve, but we can merge it and iterate.
Tip
the web repo has a compose file with all the apps enabled. That gave me the final hint to get the menu entries
pbleser-oc
force-pushed
the
groupware
branch
from
a9ef8f3 to
3d8cad1
Compare
pbleser-oc
force-pushed
the
groupware
branch
2 times, most recently
from
284aa10 to
0fce463
Compare
pbleser-oc
force-pushed
the
groupware
branch
2 times, most recently
from
fed43d7 to
aaa0140
Compare
pbleser-oc
force-pushed
the
groupware
branch
from
aaa0140 to
4909efd
Compare
pbleser-oc
force-pushed
the
groupware
branch
2 times, most recently
from
c415019 to
31458e3
Compare
pbleser-oc
force-pushed
the
groupware
branch
2 times, most recently
from
18d4522 to
911f8ad
Compare
…suppliers * refactor APIs in JMAP and Groupware in order to implement pagination across multiple accountIds and multiple suppliers (currently implemented using a mock supplier for contacts) * requires go 1.26 due to use of self-reflecting generics type constraints * still missing: query criteria and sorting parameters * still missing: multi-accountId support for emails * errors are now all just 'error' in the APIs, instead of the specialized implementations, and are interpreted dynamically where necessary in order to transform them into HTTP responses * remove position, anchor, anchorOffset as individual query parameters as we now only support a 'next=...' token for subsequent pages (except in emails for now), and use jmap.QueryParams instead; those tokens have a header character for the format, followed by a JSON encoded QueryParams map, all wrapped into base62 to make it clearer that it is meant to be an opaque token, and not a parameter clients should tinker with or construct themselves * introduce QueryParamsSupplier as an interface to provide QueryParams for various scenarios (single supplier, multiple supplier, ...) per accountId * implement multi-supplier template methods slist and squery
* remove the following methods on the jmap.QueryCommand interface, as they ended up not being needed: - GetPosition() - GetAnchor() - GetAnchorOffset() - GetLimit()
…SupplierId Purpose is to make APIs and parameters easier to understand, since plain strings are used all over the place for all sorts of identifiers.
* add new configuration setting GROUPWARE_SEND_DURATIONS_RESPONSE (defaults to false) * keep track of lists of durations of backend calls * when enabled, report them as response headers Durations (human readable) and Durations-Nanos (as raw nanosecond values for machine consumption)
* don't run the Stalwart container in recovery mode first, just run it in "proper" mode, import the configuration and use it like that, which only requires skipping the "destroy" steps * add code documentation and logging * replace the text templating of the Stalwart snapshot by doing the same as the formatting script was doing, but directly in Go, removing an additional step to perform when modifying a Stalwart configuration to use in the integration tests
…M LDAP option for now)
…ation by adding default roles as well as adding the 'impersonate' permission on the admin@example.org user
…rade integration tests to Stalwart 0.16.8 + update Stalwart configuration to include necessary default roles
…m 'master' to 'admin@example.org' to make it work with Stalwart >= 0.16
* add instructions and container to create a key and certificate pair for the built-in IDM LDAP as we need it to listen on LDAPS for Stalwart, which has been disabled by default with #2880 * add environment variables to point to the certificates * update services/groupware/DEVELOPERS.md with up-to-date instructions, using Stalwart 0.16
…ssions on the files or the opencloud container can't access them
* fix the inline dockerfile for building the stalwart:cli container, cannot be based on scratch since we need a shell and wget, and it should thus retain the alpine container as its base * remove stdin_open and tty from the container attributes, not needed
…ements for using the primary email instead of the username
…to the docker compose project
…ailable for 1.25 at the moment * retrofit from using self-referencing generics parameters that were introduced with Go 1.26, will re-enable when we upgrade to 1.26 * re-introduce a 'ptr' func since we don't have the new 'new' func yet that comes with 1.26
… currently do not have a use for it
…E_MOCK_DATA that controls whether the mock addressbook and mock contacts should be injected or not; default is false/disabled since it is not fully functional yet
…cker compose pull' fail needlessly
* by adding a predicate that can analyze a filter and inform the template methods whether the filter is applicable for that supplier or not * this fixed /groupware/accounts/.../addressbooks/.../contacts
3 participants
Description
Ongoing implementation of the Groupware backend service, which initially happened on its own branch but should now occur on the
mainbranch.Changes are almost exclusively on packages that are distinct to the Groupware backend, namely
pkg/jmap,pkg/jscalendarandpkg/jscontact: contain the implementation of the JMAP protocol and data models for Core, Mail, Contacts, Calendars, Blobs, ...services/groupware: contains the Groupware backend service which is currently configured to not be started by default, and must be explicitly included in theSTART_ADDITIONAL_SERVICESpropertyChanges to common areas include:
devtools/deployments/opencloud_full: addition of a container of the Stalwart mail server which is used for Groupware functionalitypkg/structs: add more helper functions that are then used inpkg/jmapandservices/groupwareNote that it is not fully functional yet and is going to be under continued and ongoing development along with its UI counterparts.
Specifically, the following aspects are lacking and only implemented in a skeletal way as a proof of concept:
The Groupware backend is not meant to be used productively yet.