Skip to main content

2020.1 to 2020.2

1. Indexsearch: Changes to Indexing and External Solr Usage​

What changed​

  • The index scheme has been updated, requiring a full rebuild of the index.
  • Embedded mode for the index is no longer supported; an external Solr server must be used.
  • Only one index group per entity is allowed; subgroups are now handled via a new feature using the system field #SUB_GROUP.

Why it matters​

  • The new index scheme improves subgroup handling but requires deleting existing index files and reindexing.
  • External Solr usage means the indexer runs separately from the application, improving scalability and maintainability.
  • Restricting to one index group per entity simplifies configuration and leverages the new subgroup feature.
  • Set up and configure an external Solr server prior to upgrading ADITO to version 2020.2.
  • Delete current index files before running a full indexer pass.
  • Update entity index configurations to use only one index recordcontainer per entity.
  • Map the #SUB_GROUP system field in index recordcontainers to implement subgroups.

Example usage​

  • Use the #SUB_GROUP field to assign string values representing subgroups. All datasets with the same string value will be grouped accordingly.

20202_IndexSubGroup
Figure: Example of index subgroup configuration

2. Appointment_entity: Updates to contentProcess and Grant Processes​

What changed​

  • The contentProcess of the entity’s recordcontainer now reads the owner (calendars.USER2) as a string instead of JSON.
  • The organizer field remains as JSON.
  • The grantDeleteProcess and grantUpdateProcess were updated to reflect this change.

Why it matters​

  • These changes affect how ownership and permissions are handled internally.
  • Integrations or customizations relying on the previous JSON format for the owner field may break or behave unexpectedly.
  • Review and adapt any custom code or integrations that interact with the contentProcess, grantDeleteProcess, or grantUpdateProcess of the Appointment_entity.
  • Ensure that the owner is treated as a string in all relevant contexts.

3. 360Degree_entity and Context_lib: Refactoring of Configuration for Context Data​

What changed​

  • The previous large configuration object in Context_lib for selecting 360° entity data was replaced by a function: ContextUtils.getContextDataViaReadEntity.
  • Configuration is now handled in the respective providers of 360Degree_entity via the objectType parameter.
  • The connection between objects is based on the contact ID of the related organization or person.

Why it matters​

  • This refactoring simplifies and modularizes the configuration process.
  • Customizations using the old configuration object must be updated to the new function-based approach.
  • Extending or customizing special cases may require adding new methods to Context_lib.
  • Migrate any existing custom configurations from the old object to use ContextUtils.getContextDataViaReadEntity.
  • Review the examples in the 360Degree_entity documentation for guidance.
  • Implement additional methods in Context_lib if your customization requires it.

4. Deprecated Property: Removal of isSaveAction from Actions​

What changed​

  • The isSaveAction property within actions has been deprecated and should no longer be used.

Why it matters​

  • Continued use of isSaveAction may lead to compatibility issues in future versions.
  • Removing deprecated properties ensures cleaner and more maintainable codebases.
  • Audit your projects to identify and remove all usages of the isSaveAction property.
  • Avoid using this property in any new developments.