cq-msm-lockable for properties in subnodes not working

[Reini-]

Hi,

to show the "break inheritance" icon in page properties dialog you have to add the cq-msm-lockable property in the subnode granite:data.

Example:

<myCheckbox
	jcr:primaryType="nt:unstructured"
	sling:resourceType="granite/ui/components/coral/foundation/form/checkbox"
	cq:showOnCreate="{Boolean}true"
	text="myCheckbox"
	name="./myProp"
	value="{Boolean}true"
	uncheckedValue="{Boolean}false"
	renderReadOnly="{Boolean}true">
	<granite:data
		jcr:primaryType="nt:unstructured"
		cq-msm-lockable="./myProp" />
</myCheckbox>

But this only works for "flat" properties (like myProp in previsous example). If I add properties including nodes (e.g. subnode/myProp) then the break inheritance icon is shown, but when you break the inheritance, change the value in the livecopy and start a rollout again then the changed value gets overwritten although the dialog shows that the inheritance is broken.

Example:

<myCheckbox
	jcr:primaryType="nt:unstructured"
	sling:resourceType="granite/ui/components/coral/foundation/form/checkbox"
	cq:showOnCreate="{Boolean}true"
	text="myCheckbox"
	name="./subnode/myProp"
	value="{Boolean}true"
	uncheckedValue="{Boolean}false"
	renderReadOnly="{Boolean}true">
	<granite:data
		jcr:primaryType="nt:unstructured"
		cq-msm-lockable="./subnode/myProp" />
</myCheckbox>

As written above, with this code the icon is visible, you can break the inheritance but the value will be overwritten on every rollout.

Has somebody an idea how to solve this issue?

regards

Reini

[Vijayalakshmi_S · Accepted solution]

Hi @Reini-,

This is a known behavior. It is documented in below link

https://experienceleague.adobe.com/docs/experience-manager-65/developing/extending-aem/extending-msm...

Alternative fix/workaround for this is available in below blog post 

• https://www.bounteous.com/insights/2017/02/20/hotfix-aem-msm-inheritance-breaking/

If the content volume is minimal, you can consider changing the property name. In which case, approach would be

1. Back up old content -> Prepare migration script for already authored content to get updated to new property path(should be a copy action rather than move to support old path till we update the property name. Later when things are fine, you can purge old property path) -> then change the property name (Should be fine for future content as well as for already authored pages)

If it is huge and can't risk about existing content, consider the above workaround from the blog post. 

Note : Either ways, content backup is super important for scenarios like this in each environment.