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.
Â