App Suite Middleware

API - HTTP-API

SCR-1573

Summary: New option 'identifiers' for 'folders?action=notify'

In order to support arbitrary permissions beyond context-internal entities, the notify action in module folders is extended by the possibility to reference the targeted recipients also by their identifier, as used in the corresponding permissions.

Therefore, the request body accepts an additional string array named identifiers, where the identifiers of the users or groups that shall be notified can be specified.

See the HTTP API documentation for further details.

SCR-1571

Summary: Exposed parameter 'trackAttendeeUsage' for 'chronos?action=new' and 'chronos?action=update'

The new and update actions in module chronos will now evaluate the optional parameter trackAttendeeUsage.

It can be used to configure whether newly added attendees from creations and updates should be tracked automatically, which includes adding new entries in the collected contacts folder for new external calendar users (utilizing the contact collector service), as well as incrementing the use counts for already known internal and external entities (using the object use count service). Defaults to true, hence needs to be disabled explicitly.

See the HTTP API documentation for further details.

Configuration

SCR-1574

Summary: New property 'com.openexchange.mail.crossContextPermissions'

In order to enable cross-context folder permissions / mailbox ACLs, the new lean configuration property com.openexchange.mail.crossContextPermissions is introduced, defaulting to false. It can be defined through the config-cascade and is reloadable. It should only be enabled if all contexts of the deployment access the same mail server, and requires further preconditions like a configured mail login resolver service.

Clients are able to discover the actual value via JSlob path io.ox/mail//crossContextPermissions.

See the property documentation, as well as the feature documentation for further details.

SCR-1572

Summary: New parameter 'com.openexchange.calendar.storage.separateTransactionForSequenceIds'

In order to control whether a separate database transaction should be used for generating sequential identifiers, or if id generation should be performed within the surrounding transaction of the calendar storage operation, the new lean configuration property com.openexchange.calendar.storage.separateTransactionForSequenceIds is introduced.

Using a separate transaction can help to minimize the duration of the row lock in the sequence table, especially when many conflicting accesses for a single context are to be expeceted, e.g. during mass imports of calendar data. However, an additional database connection is used, and any already incremented counters won't be part of a potential rollback, then.

The property defaults to false, is reloadable, but not config-cascade aware.

See the property documentation for further details.