I have a solution where a regionalized variation of a Content Fragment is intended to be used based on the resource path of the request. This allows us to seamlessly display region specific content from the matching variation without needing to manually select the variation from a component dialog and breaking the inheritance chain on our live copies. I've modified an existing solution that was already in place that simply created a
com.adobe.cq.dam.cfm.ContentFragmentException: Could not create modifiable property map. at com.adobe.cq.dam.cfm.impl.PropertyElement.getVarProperties(PropertyElement.java:130) [com.adobe.dam.cq-dam-cfm-impl:0.11.98] at com.adobe.cq.dam.cfm.impl.PropertyElement.getProperties(PropertyElement.java:137) [com.adobe.dam.cq-dam-cfm-impl:0.11.98] at com.adobe.cq.dam.cfm.impl.PropertyElement.setContent(PropertyElement.java:319) [com.adobe.dam.cq-dam-cfm-impl:0.11.98]
I suspect this could have something to do with our author instances using the admin userID and our publish instances using anonymous userID. If this is indeed the case, is there another way to use the contentVariationElement in place of the Master element without running into permissions issues?
After logging into my publish instance as admin, I can confirm it's a permissions issue. The jcr:write permissions are required to use ContentElement.setValue(FragmentData).
In it's old form, our helper function iterated through the ContentElements in the given ContentFragment and returned them in a map<String, ContentElement>. The limitation here is that only the master variation can be displayed as any variation content is stored in ContentVariation objects. Initially, in an effort to get around this without needing to refactor the other classes that use this helper class, I attempted to set the value of the content element with the FragmentData of the variation. This worked as expected on author but not on Publish, due to the permissions issue.
In the end, since we simply use the keys to display the content and since both ContentElements and ContentVariations share the same structure, I chose to change the Map signature to <String, Object> so the map could hold both objects and we could call the needed content using the keys as before. This solution did come with the caveat of having to refactor other classes and potentially needing to cast the Objects back to their original classes if the methods are ever needed in a future implementation. But this solution fixed the bug and fits our use case.
I would like to still leave this thread open to see if anyone else happens to see another solution that perhaps I have yet to consider.
Topics help categorize Community content and increase your ability to discover relevant content.
Sign in to like this content
You can confirm if it is a permission issue by login into your Publish instance (http://localhost:4503/login), if that's the root cause, can't you simply grant permission to the anonymous user?
Yep, I had the same thought shortly after my post to login as admin on the local publish instance. I can confirm that it was an issue with permissions. Anonymous doesn't have jcr:write privileges, which is required to use the method ContentElement.setValue(FragmentData). I was a bit confined in options here as this particular treatment of Content Fragments in our project was built long before me and is already heavily implicated in our project. Until now, Content Fragment variations were just not used by our authoring team so the potential permissions issue here was never considered.
We didn't want to give the anonymous user additional permissions for security reasons, since those permissions would be carried over all the way to our live server. We considered adding a ServiceUser that had the necessary permissions to run the function and then close the ResourceResolver after, but that seemed a bit heavy and unnecessary.
I updated the original post with the solution that I came up with. Thanks for reaching out!