Upcoming
release-2023-05
May 2023 Release
https://github.com/livingdocsIO/livingdocs-editor/tree/release-2023-05

Caveat 🔥

These are the release notes of the upcoming release (pull requests merged to master).

  • ℹ️ this document is updated automatically by a bot (pr’s to categorize section)
  • ℹ️ this document will be roughly updated manually once a week (put PRs + description to the right section)
  • 🔥 We don’t guarantee stable APIs. They can still change until the official release
  • 🔥 Integration against the upcoming release (currently master branch) is at your own risk

PRs to Categorize

Attention: If you skipped one or more releases, please also check the release-notes of the skipped ones.

Webinar

System Requirements

Suggested

TODO

Minimal

TODO

Highlights

Document Access Control

TODO: Description

Synced Table Dashboards

TODO: Description

Planning System (Bundles)

TODO: Description

Working Title

TODO: Description

Publication/Draft Index

TODO: Description

Advanced Search Filters Foundation

TODO: Description

Home Screen - Part 2

TODO: Description

Display Filters ListV2 with OR combination

TODO: Description

Issue Management - Navigation

TODO: Description

Metadata Preview

TODO: Description

Concurrent License Model: Billing Report

TODO: Description

i18n - Editor available in German

TODO: Description

Microsoft Teams Integration

TODO: Description

Breaking Changes 🔥

Migrate the Postgres Database 🔥

It’s a simple/fast migration with no expected data losses.

# run `livingdocs-server migrate up` to update to the newest database scheme
# migration 184-increase-webhook-handle-length.js
#   limit webhook handle to 50 characters
# migration 185-li-get-leaf-of-revision-history.js
#   add psql function li_get_leaf_of_revision_history
livingdocs-server migrate up

Drop support for node v14

🔥 Drop support for node 14, use node v18 instead.

Drop support for Redis < v6.2

🔥 The minimal required Redis version is v6.2.

Upgrade to elasticsearch client v8

🔥 The response structure changed in the new client. If you have custom code that accesses elasticsearch, you’ll need to update it accordingly:

- const {body} = await elasticsearchClient.search({
+ const body = await elasticsearchClient.search({
    index: 'li-documents',
    q: `document.id:${this.doc.id}`
  })

Please see the examples of elasticsearch how to use it: https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/get_examples.html

🔥 The elasticsearch client configuration changed slightly. Please consult the elasticsearch client configuration documentation: https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/basic-config.html

  search: {
    elasticsearchClient: {
      node: 'https://127.0.0.1:9200/',
      auth: {username: 'admin', password: 'admin'},
-     ssl: {rejectUnauthorized: false}
+     tls: {rejectUnauthorized: false}
    }
  },

Stricter search queries

  • 🔥 Filters on unavailable properties throw an error.

  • 🔥 Elasticsearch exists queries on objects not supported anymore. Please use a specific sub-property instead.

    e.g. To filter for documents that have no category assigned, you need to use category.reference.id instead of category in the editor search filter:

    {
  id: 'without-category',
  label: 'Without category',
  type: 'metadata',
-  key: 'category',
+  key: 'category.reference.id',
  value: {exists: false}
}

References: Server PR

Don’t expose error_details in 5xx response

🔥 5XX responses will no longer contain body.error_details object, still the whole error response will be logged.

References: Server PR

Remove metadata plugin li-media-language

🔥 Remove metadata plugin li-media-language, use li-metadata-translations instead.

References: Server PR

Remove deprecated document.path

Since a long time we deprecated the DB property documents.path, because there is no real feature behind that property.

🔥 contentTypes[].editor.deliveryLinks do not support:path placeholder 🔥 editor model draft.path is not accessible anymore

References: Server PR

Support removal of metadata properties by assigning null

🔥 Before this change, assigning null values resulted in a metadata schema error. Now it’s accepted and it removes the metadata property. Therefore it’s not possible anymore to save the value null as metadata property value.

// before
metadata.myField = null // throws
// now
metadata.myField = null // delete metadata.myField

References: Server PR

Mandatory project_id in documentApi.find

🔥 Make project_id mandatory in documentApi.find

References: Server PR

Fix firstPublicationDate to documents table (Post Deployment) 🔥

This script was backported to release-2022-11, so it has been added again for release-2023-05 in case anyone missed it. If you already ran the script with the previous release upgrade you do not need to run it again.

If you have unpublished a document while running release-2022-07 or release-2022-09 then you may have inaccurate values for the document.systemdata.firstPublicationDate. Below is a comparison of the change in the four most recent versions:

First publish: release-2022-07 and release-2022-09: Set firstPublicationDate release-2022-05 and release-2022-11: Set firstPublicationDate

Republish while published: release-2022-07 and release-2022-09: Keep firstPublicationDate release-2022-05 and release-2022-11: Keep firstPublicationDate

Unpublish: release-2022-07 and release-2022-09: Remove firstPublicationDate release-2022-05 and release-2022-11: Keep firstPublicationDate

Republish after unpublish: release-2022-07 and release-2022-09: Set firstPublicationDate release-2022-05 and release-2022-11: Keep firstPublicationDate

Essentially the old behaviour and the new “fixed” behaviour is to set firstPublicationDate once and never modify it. This property will still exist even when the document is unpublished. For release-2022-07 and release-2022-09 the difference in behaviour was that the firstPublicationDate would be cleared on unpublish and set again at the next publish.

If you would like to correct the firstPublicationDate property for all of your articles you can run:

node ./node_modules/@livingdocs/server/db/manual-migrations/009-fix-first-publication-date.js

This script performs the following actions:

  1. Check that first_publication_id has been set (same as the script 007-populate-first-publication-data.js)
  2. Move firstPublicationDate from data to data.publishControl
  3. Remove data.firstPublicationDate
  4. If firstPublicationDate is not set then use the value from the first publication
  5. If firstPublicationDate is set then use the value from the first publication when the first publication is older

It is highly recommended that you run this script because it is performing a data migration as well as fixing the values.

References: Server PR

Deprecations

Deprecate Dashboard Display Filters

These Dashboard Display Filters get deprecated:

  • coreApi.searchFilters.register
  • coreApi.searchFilters.registerList
  • coreApi.searchFilters.registerAngularComponent

Update the deprecated filter to the supported Display Filters from the core.

  • Named Filters
  • Metadata Filters
  • ListV2 Filters

If you can’t handle your requirements with core filters it’s best to contact your Customer Solutions manager to get inputs for solutions (one option is to create your custom Vue component, but that should be prevented whenever possible)

Breaking Change: release-2023-03

References: Editor PR

Other Changes

Features

Improvements

Bugfixes

Patches

Here is a list of all patches after the release has been announced.

Livingdocs Server Patches

Livingdocs Editor Patches

Icon Legend

  • Breaking changes: 🔥
  • Feature: 🎁
  • Bugfix: 🪲
  • Chore: 🔧