Upgrading to 2022.2.1

Release

https://drive.google.com/file/d/1dt0RIuKXZ7GfSCJPwstqbF9zAZOwAZp2/view?usp=sharing

Structure changes

massimportitem

Those changes were delivered in the 2022.2 default NAR file and should only be applied with portal 2022.2.1

massimportitem

  • phavg: removed tag asset/hashimageaverage

  • phdiff:

    • removed tag asset/hashimagedifference

    • added tag rest_api_mass_import_field

  • status: added tag rest_api_mass_import_agg

Portal configuration for upload

Starting from 2022.2.1, changes applied to job items in portal mass indexation screens can be fine tuned to prevent monitoring for fields changes. The aim of such change is to smoothen user experience by preventing the progress bar (also known as snack bar) to show at every field change. Portal doesn’t need to monitor the change of items when such change does not require facets changes.

To benefit from this feature, you must update your configuration in $.damImport and $.damBulkedit In both entries, add a new key: faceFields. Associated value is an array containing the names of fields that should force portal to monitor changes from.

When such entry is defined

  • Changes to fields not contained in the array will not be monitored by portal, and no progress bar is shown

  • Changes to fields contained in the array will lock the form until changes are applied server side, and faces are computed.

WXM_RESTAPI configuration for upload

The configuration needed to accommodate the changes made to improve portal mass upload performance was delivered as the default configuration in the 2022.2 release. So there is nothing special to do. It is fully compatible with an older version of the portal, so there is normally nothing special to do to get an older version of the portal working. The detail of the configuration is explained here (See properties tagged 2022.1.0,as delivered in this release, but not activated, by default).

In this release, the validation is no longer done directly by the portal but by the server at its request, asynchronously. This does not allow the portal to delete jobs on demand (they may still be in the process of validation). As a consequence, we deactivate the job instead of deleting it. And it is a purge task that takes care of deleting the deactivated jobs, but also jobs and items that are unusable (orphaned items or jobs, empty jobs, etc). The configuration of this purge is detailed here.

Â