* implement supplier templating to allow addressbooks and contacts to
come from various sources ("suppliers", thus) as opposed to solely
from JMAP
* add creating, deleting, updating, getting changes
* add some search filter parameters, currently incomplete
* 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
* 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
* 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
* 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
https://github.com/opencloud-eu/opencloud/pull/2880
* add environment variables to point to the certificates
* update services/groupware/DEVELOPERS.md with up-to-date instructions,
using Stalwart 0.16
* 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
* 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)
* remove the following methods on the jmap.QueryCommand interface, as
they ended up not being needed:
- GetPosition()
- GetAnchor()
- GetAnchorOffset()
- GetLimit()
* 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
* in the JMAP API as well as in several places in the Groupware
framework, use a single jmap.Response[T] object to return the
payload, the language, the session state and the etag/state instead
of individual multi-valued return values
* the "position" attribute is always set to 0 when using an anchor for
pagination, but it does not accurately reflect the position and thus
we decided to remove the attribute from the resulting object for
clarity
* omit "canCalculateChanges" attribute when its value is "true", which
is going to be the case in 100% of calls against Stalwart
* JMAP query limit of 0 is synonymous with "no limit", but we actually
want to be able to perform queries without any results, for cases
where we only want to count the total number of objects, and also
because it makes more sense semantically
* introduce query parameter validation checks, in order to only allow
query parameters that are actually supported, which is going to be
useful during development of clients
* adds creating addressbooks, calendars, mailboxes
* adds deleting mailbox, event, identity
* adds modifying an email
* introduce template functions for the Groupware API in templates.go,
and use those in route function implementations whenever possible
* add capability checking for mail, quota, blobs
* adds Changes interface
* adds JmapResponse interface
