Migration to 2.0

Collection Type definitions

EditableMetadata Removed

With DO 2.0, the deprecated collection type definition structure editableMetadata has been completely removed and replaced with the new metadata structure. This change provides more granular control over field visibility and permissions.

What Changed:

The old editableMetadata structure with separate create and edit sections is no longer supported:

Old approach (removed):

editableMetadata:
  create:
    - key: field1
      label: Field 1
  edit:
    - key: field2
      label: Field 2

New approach (required):

metadata:
  - key: field1
    label: Field 1
    visibility: CREATE
    permission: CREATE
  - key: field2
    label: Field 2
    visibility: EDIT
    permission: EDIT

Migration Steps:

1. Replace editableMetadata with metadata - Change the field name in your collection type definitions

2. Convert create fields - Fields from the create section should have:

   • visibility: CREATE - Only shown when creating new elements
   • permission: CREATE - Allows creating new fields

3. Convert edit fields - Fields from the edit section should have:

   • visibility: EDIT - Only shown when editing existing elements
   • permission: EDIT - Only allows modifying existing fields

New Properties Reference:

Property	Values	Description
visibility	CREATE, EDIT, ALL	When the field is displayed to the user
permission	READ, EDIT, CREATE	What operations are allowed on the field

Understanding visibility contexts:

• visibility: CREATE - Field is shown when creating a new document (e.g., by copying or moving pages into a new document)
• visibility: EDIT - Field is shown when editing the metadata of an existing element
• visibility: ALL - Field is shown in both creation and editing contexts

Understanding permission contexts:

• permission: READ - Field is displayed but cannot be modified
• permission: EDIT - Existing values can be modified, but new values cannot be created
• permission: CREATE - New values can be created even if the field doesn't exist initially

Helm Changes

Secret configuration moved

The secret configuration for various secrets related to the organizer has been moved from the global space to the organizer subpath.

secrets.db                 -> organizer.secrets.db
secrets.sba                -> organizer.secrets.sba
secrets.loader             -> organizer.secrets.loader
secrets.s3                 -> organizer.secrets.s3
secrets.webdav             -> organizer.secrets.webdav
secrets.saveNotification   -> organizer.secrets.saveNotification
secrets.exportNotification -> organizer.secrets.exportNotification

The object structure and field names of each secret remain unchanged.

DB secret changes

The database secret no longer supports the native MariaDB credential needed to set up a MariaDB container. The following fields where removed:

secrets.db.mariadb.password
secrets.db.mariadb.rootPassword
secrets.db.mariadb.replicationPassword

The remaining fields stay the same and only contain the information necessary to connect to an existing database:

secrets.db.username
secrets.db.password 

This change follows the removal of the MariaDB chart dependency. If you want to continue to use MariaDB you have to add the chart manually and configure the secrets according to your chart of choice.

MariaDB sub dependency removed

Due to changes in the distribution model of our MariaDB vendor, we are no longer allowed to include the MariaDB image directly in our Chart. In light of this, the MariaDB sub dependency was removed entirely. Now the MariaDB has to be set up and configured externally, as this was already the case for all other DB variants. All configuration below mariadb.* where removed and the db secret was changed as described above.

Export and Save Notification Token Configuration

With DO 2.0, notification credentials should no longer be stored as plain text in the organizer configuration. As they contain sensitive information they should be provided via the secrets section.

Old approach (deprecated):

organizer:
  exportNotification:
    auth:
      basicAuthenticated:
        enabled: true
        username: my-user
        password: my-password

New approach:

organizer:
  exportNotification:
    auth:
      basicAuthenticated:
        enabled: true

secrets:
  exportNotification:
    username: my-user
    password: my-password

Document source redirect

The default value for the organizer.loaders.localHostRedirect: true configuration has changed from false to true.

This is to prevent downloading local documents using the external Fusion host address. Any document source that points to the Fusion host itself will be redirected to localhost to improve performance.

Renamed Compact History Job Configuration Field

The field organizer.jobs.compactHistory.transactionBatchSize was renamed from batchSize to transactionBatchSize, to unify the naming convention with other job configurations.

This Field is used to configure the number of transactions included in a single database transaction when executing a compact history job.