Resolving automatic asset publication in 2024.1, 2024.2 and 2024.3

Owned by Guillaume LEPICARD
Aug 08, 2024
50 min read

Context

Since 2024.1, a bug is causing an automatic workflow action on all created assets. With the default Starter-Kit configuration, this action publishes all assets after their creation. Depending on your project configuration, this bug can lead to unexpected behaviours, such as:

This bug was sneaky because it was often not visible right after the creation of the asset, but ± 15 minutes after creating the asset (which explains without excusing) why we missed this bug.

This page aims to help you

  • Understand different use cases the product team is managing within the configuration

  • Fix PACKAGED_DAM_Utils dam_denormalization_config parameter

  • Adapt the default product behaviours to your specific project / customer requirements

Reminder - native use cases

An asset is created from the Back Office

When asset creation is performed through the Back Office (whether by creating directly an instance of a dam collection, or by using the Back Office import feature), from a product perspective, the asset should be created in the draft status, and should remain in this status until a user changes its status (using the workflow tab available in dataview screen or using the bulk changes feature available from the datalist screen)

This manual action ensures that only authorised users with licensed accounts can publish assets.

An asset is created from Front Office’s “Upload v1” screens

When an asset is created from the Upload v1 feature (/dam-import Front Office URL), the product team assumes that clicking the Validate button means that the asset has been fully indexed by the user and that the indexing stage is completed. Therefore, there is no need for the user to manually mark the indexation state as completed (you can think at the asset within dam-import as being the equivalent of the draft status in Back Office)

image-20240808-194640.png

2 cases can occur :

  1. The user is allowed to publish assets (paid seat). In that case, it is assumed that as the user is clicking the Validate button, the asset should be created and published. This default behaviour is strongly recommended to avoid the user moving from the Front Office to the Back Office to complete the publication of the asset

  2. The user is not allowed to publish assets (free seat). In that case, it is assumed that as the user is clicking the Validate button, he has completed his job, and wants to submit it so that a granted user (paid seat) will publish the asset.

An asset is created from Front Office “Workspaces” feature

When an asset is created from the Workspaces feature (/spaces Front Office URL), the product team assumes that the asset has been fully approved (users have the opportunity to ask approval to different users and to collect their feedback). Therefore, only paid users are allowed to click the Publish button. Additionally, as the approval process has been ran with the workspace, the asset can be published directly.

 

image-20240808-200412.png

How it works

The PACKAGED_DAM_Utils plugin is responsible for applying the appropriate workflow on the asset upon its creation.

In order to define whether the asset should be

  1. Kept in its default status (Back Office use case)

  2. Submitted for approval or Published (Upload v1 use case)

  3. Published (Workspaces use case)

the plugin has to discover the source of the asset and take the appropriate workflow action.

Within the plugin configuration, you can see in asyncTransformers section rules equivalent to this one:

{ "objectSelector": "#damobject", "preventGuard": { "classAlias": "negate", "input": { "preset": "isSpaceAsset" } }, "workflowTrigger": [ "publish" ] },

This instructs PACKAGED_DAM_Utils to trigger the workflow action publish on objects having the damobject configuration tag if the isSpaceAsset preset returns true (beware that we we want to prevent this action if the asset is not coming from a workspace, reason why we make use of the negate transformer)

What went wrong?

The problem was coming from the way the plugin detected a creation from a Workspace. Here is the former (buggy) definition of the isSpaceAsset preset

{ "key": "isSpaceAsset", "classAlias": "lowerThan", "init": 1, "input": { "classAlias": "countCommon", "init": [ null ], "input": { "classAlias": "propertyAsObject", "init": "spaces" } } }

There are 2 issues with this definition:

  • The preset was relying on the spaces field (cmlr → collaborativespace) to define whether the asset originated from a workspace. It was assuming that if the asset had none null value, it would mean that the asset was indeed coming from a workspace is wrong as if the asset is not coming from a workspace, it will not have null in spaces field. null is never stored on a child multi.

  • Eventhough, relying on the spaces field was a terrible idea as this information persists, meaning that in case of a “workcopy”, the field spaces would have been kept untouched, leading to the publication of the workcopy immediately after its creation.

How to fix

Fix definition of isSpaceAsset preset

Replace the definition of the isSpaceAsset preset with this one:

{ "key": "isSpaceAsset", "classAlias": "greaterThan", "init": 0, "input": { "classAlias": "countCommon", "init": [ "space" ], "input": { "classAlias": "propertyAsObject", "init": "tmpsource" } } }

Instead of relying on the spaces field, we now use tmpsource field, checking if its value is “space”

Differentiating assets coming from Upload v1 and Workspaces

The following asyncTransformers must be added BEFORE massimport workflow trigger:

This will make sure the tmpsource field of a massimportitem will be correctly set to either “space” or “massimport” depending of the creation context of the item.

Fully fixed default configuration (with comments)

Find below the full default configuration (as of 2024.4.0) with explanations. Note that you cannot copy paste this directly as comments are not supported in JSON

Further reading

Metadata and AI extraction with DAM_Utils