App Suite Middleware

General

SCR-1613

Summary: Added new property specifying that server-associated capabilities should be cached on a per user basis

Added new lean property com.openexchange.imap.cache.serverCapabilitiesPerUser specifying that server-associated capabilities should be cached on a per user basis. This is useful for setups with some sort of IMAP proxy in front forwarding to heterogeneous IMAP back-ends. Default is false. It is reloadable as well as config-cascade aware.

API - SOAP

SCR-1619

Summary: New Element 'primaryAddress' in 'accountDataUpdate' for 'OXSecondaryAccountService'

In order to set a new primary email address for a secondary account, the accountDataUpdate element within the update SOAP body of OXSecondaryAccountService service port is extended with a new optional element primaryAddress.

While changing the address, the targeted account still needs to be supplied via parent element primaryAddress, afterwards, the secondary mail account is acceesible using the new primary address.

Example:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://soap.admin.openexchange.com" xmlns:xsd="http://dataobjects.soap.admin.openexchange.com/xsd" xmlns:xsd1="http://dataobjects.rmi.admin.openexchange.com/xsd">
   <soapenv:Header/>
   <soapenv:Body>
      <soap:update>
         <soap:primaryAddress>service@context1.ox.test</soap:primaryAddress>
         <soap:accountDataUpdate>
            <xsd:primaryAddress>service2@context1.ox.test</xsd:primaryAddress>
            <xsd:name>service2@context1.ox.test</xsd:name>
            <xsd:personal>Service 2 &lt;service2@context1.ox.test</xsd:personal>
            <xsd:login>service2@context1.ox.test</xsd:login>
         </soap:accountDataUpdate>
         [...]
      </soap:update>
   </soapenv:Body>
</soapenv:Envelope>

CLT

SCR-1620

Summary: New Option '--new-primary-address' for 'updatesecondaryaccount'

In order to set a new primary email address for a secondary account, the commandline utility updatesecondaryaccount is extended with a new optional argument --new-primary-address.

While changing the address, the targeted account still needs to be supplied via mandatory parameter primary-address, afterwards, the secondary mail account is accessible using the new primary address.

See the documentation for further details.

Configuration

SCR-1623

Summary: Added new property to specify preferred snippet service to use

Added new lean property "com.openexchange.snippet.preferredSnippetService" to specify preferred snippet service to use. Default value is empty (no preferred snippet service). It is reloadable and config-cascade aware.

Accepted values are:

  • "database" for database-backed snippet service
  • "filestore" for filestore-backed snippet service

SCR-1622

Summary: Added new property for read duration threshold

Added new lean property com.openexchange.mail.bodyPartReadThresholdMillis that specifies the threshold in milliseconds for the read duration of body parts from mail storage. If that threshold is exceeded a warn log message is generated. Default value is 3000 (3 seconds). It is reloadable, but not config-cascade aware. A value of less than/equal to 0 (zero) disables this threshold.

SCR-1621

Summary: New Property 'com.openexchange.calendar.allowChangeOfOrganizerWithExternals'

Changing the organizer in group-scheduled events is an out-of-band process that might not be compatible with iTIP clients. In order to allow changing the organizer for mettings with only context-internal participants, there's property com.openexchange.calendar.allowChangeOfOrganizer already available, which enables clients changing the organizer via HTTP API - however this only works if the new organizer and all attendees of the event are context-internal users.

Now to also allow this for events with external attendees, the new lean configuration property {}com.openexchange.calendar.allowChangeOfOrganizerWithExternals. It is reloadable and can be defined through the config-cascade. See the property documentation for further details.

SCR-1618

Summary: New Properties to Enable Custom Login Source for Drive Client Onboarding

In order to enable usage of a registered custom login source when preparing details for the driveappmanual and drivewindowsclientmanual onboarding scenarios, the following new lean configuration properties are introduced:

  • com.openexchange.client.onboarding.drivewindowsclient.login.customsource
  • com.openexchange.client.onboarding.driveapp.login.customsource

Both default to false, are reloadable and can be defined through the config cascade.

SCR-1617

Summary: New Scenarios for Manual Drive Client Onboarding Configuration

The available onboarding scenarios are extended with two new "manual" configuration options for the Drive App, with the following identifiers:

  • driveappmanual
  • drivewindowsclientmanual

Accompanying the corresponding link / installer scenarios, these new options can be enabled and configured within the scenario configuration file {}client-onboarding-scenarios.yml, and added to the respective enabled scenarios per platform in configuration file {}client-onboarding.properties.

See template file client-onboarding-scnearios-template.yml for further details.