Why censhare chooses wrong 'Asset type metadata dialog' template?

1. What means "Asset type metadata dialog" template?

"Asset type metadata dialog" templates are resource assets of type module.dialog. and with resource usage "Asset type metadata dialog definition". The resource keys of the default once are having the following pattern:

With these templates is managed/configured e.g. the content of the “Create new asset dialog” or "Edit properties dialog":

Create new asset dialog

Edit properties dialog

2. What is this article about?

A source asset filter, which is defined in the template, determines for which asset type should be applied the template:

This template should be applied for assets of type module.oc.sharelink.

This article explains how censhare evaluates the source asset filter in order to choose which template to be applied for a certain asset type and why sometimes a wrong template is applied.

3. Actual censhare behaviour (currently in version 2020.1 and lower).

Example: currently, assets of type module.oc.sharelink. are accepted by two different dialog templates present in the required module assets folder:

1. "Share Link Asset Metadata Dialog", which matches assets of type module.oc.sharelink. and should be the one used in this case as it’s the dialog with an input field for the share link ID, and

2. "Module Asset Metadata Dialog", which has filter :starts-with(asset/@type, 'module.') (without *), but although matches assets of type module.* and should not be used in this case as it doesn’t include the share link ID.

Because of this overlapping, the correct dialog will be used only if the ID of its resource asset is greater than the other one’s, which is something that can not be guaranteed in the censhare versions mentioned above.

Consequence: In this example, this has the side effect of an user not being able to create a share link, as its ID is a required field and the wizard cannot proceed when it is missing.

Workaround 1: When you have overlapping dialog templates and your system is choosing the wrong one, deleting the asset for the correct one and running the Synchronize module assets server action on the folder that contains it. This will force the asset to be recreated with a higher ID than any of the other options.

Workaround 2:  Another alternative, more suitable for assets where there are changes not coming from the module assets folder which a user might want to keep, is to duplicate the asset, remove the resource key from the old one, add that same resource key to the duplicate and only then deleting the old one.