* ensure that all the jmap responses contain the SessionState
* implement missing errors that were marked as TODO
* moved common functions from pkg/jmap and pkg/services/groupware to
pkg/log and pkg/structs to commonalize them across both source trees
* implement error handling for SetError occurences
* Email: replace anonymous map[string]bool for mailbox rights with a
MailboxRights struct, as the keys are well-defined, which allows for
properly documenting them
* introduce ObjectType as an "enum"
* fix JSON marshalling and unmarshalling of EmailBodyStructure
* move the swagger documentation structs from groupware_api.go to
groupware_docs.go
* fix: change verb for /groupware/accounts/*/vacation from POST to PUT
* refactor the jmap package to split it into several files as the
jmap.api.go file was becoming too unwieldy
* refactor the Groupware handler function response to be a Response
object, to be more future-proof and avoid adding more and more
return parameters while handling "no content" response as well
* more godoc for the JMAP model
* add Email creation, updating, deleting (Email/set,
EmailSubmission/set)
* add endpoints
- POST /accounts/{accountid}/messages
- PATCH|PUT /accounts/{accountid}/messages/{messageid}
- DELETE /accounts/{accountid}/messages/{messageid}
* after having decided that the Groupware API should be a standalone
independent custom REST API that is using JMAP data models as much as
possible,
* removed Groupware APIs from the Graph service
* moved Groupware implementation to the Groupware service, and
refactored a few things accordingly
* refactored the models to be strongly typed with structs and mapstruct
to decompose the dynamic parts of the JMAP payloads
* externalized large JSON strings for tests into .json files under
testdata/
* added a couple of fantasy Graph groupware APIs to explore further
options
* added k6 scripts to test those graph/me/messages APIs, with a setup
program to set up users in LDAP, fill their IMAP inbox, activate them
in Stalwart, cleaning things up, etc...
Four cases covering the distinct grammar paths touched by the
new Key rule: dotted key in a TextPropertyRestrictionNode,
multi-level key (stressing the Kleene part), dotted key in a
GroupNode (the k:Key? branch), and a dot on the value side
that must stay a literal character.
Introduce a dedicated Key rule (Char+ ("." Char+)*) so property
restriction keys can contain dots. Queries like
audio.artist:Motörhead or photo.cameraMake:Apple now parse.
Goal: keep the data structure aligned with the query namespace.
A driveItem exposes nested fields as dotted paths in its API
response (photo.cameraMake, location.latitude); users should be
able to query with the same path, without admin-configured slot
mappings or alias tables like Microsoft requires.
Both bleve and OpenSearch already treat dots as the nesting
separator for field paths and pass unknown keys through
unchanged — only the KQL grammar blocked dotted keys via
Char <- [A-Za-z]. The new Key rule lifts that restriction; no
compiler changes or field-alias maintenance is needed.
Values are unaffected — dots in values still parse as literal
characters.
be careful, the env:OC_EDITION, env:FRONTEND_EDITION, and conf:edition got removed as part of this commit, no deprecation because the flag is build time only!
