* 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
* jmap: add UpdateContactCard and UpdateCalendarEvent funcs
* use JSON marshalling and unmarshalling into a map for toPatch()
implementations
* add updating ContactCards and CalendarEvents to tests
* add deleting ContactCards and CalendarEvents to tests
* make query response totals work when the value is 0
* tests: use CreateContactCard and CreateCalendarEvent funcs to create
objects in tests instead of using a different JMAP stack that works
with untyped maps
* make the JMAP internal API a bit more future-proof by passing
ObjectType objects instead of the JMAP namespaces
* remove the new attempt to contain operations even further using the
Factory objects
* move CalendarEvent operations to its own file, like everything else
* fix email tests
* ignore WS error when closing an already closed connection
* move ContactCard from jscontact to jmap, as it is actually a JMAP
specification item, but also was causing too many issues with
circular references from jscontact -> jmap
* introduce Foo, Idable, GetRequest, GetResponse, etc... types and
generics
* first attempt at a Foo factory type for Mailboxes, needs to be
expanded to further minimize repetition
* add more specialized template functions to avoid repetition
* introduce ChangesTemplate[T] for *Changes structs
* add Groupware APIs for creating and deleting addressbooks
* add Groupware APIs for creating and deleting calendars
* add JMAP APIs for creating and deleting addressbooks, calendars
* add JMAP APIs to retrieve Principals
* fix API tagging
* move addressbook JMAP APIs into its own file
* move addressbook Groupware APIs into its own file
* implement ContactCard retrieval endpoint for syncing
* re-implement that endpoint for Email too
* fix the Mailbox changes endpoint to actually return changes about
Mailboxes, and not about Emails
* when querying the diff of Mailboxes without any prior state, return
an error since the result is not what one would expect
* introduce the 'changes' API tag and group
* refactor the successful response functions to consistently return an
object type and object state whenever possible
* move the syncing endpoints under /accounts/*/changes/ for better
clarity, e.g. /changes/emails instead of /emails/mailbox/*/changes
