[MGNLCDEP-89] Dependencies from multi-valued properties cannot be resolved Created: 12/Apr/16  Updated: 19/Aug/20  Resolved: 03/Aug/20

Status: Closed
Project: Content Dependencies
Component/s: None
Affects Version/s: 1.6.1, 1.9
Fix Version/s: 1.9.3, 2.0.2

Type: Bug Priority: Neutral
Reporter: Philip Mundt Assignee: Antonín Juran
Resolution: Fixed Votes: 3
Labels: maintenance
Remaining Estimate: 0d
Time Spent: 2.25d
Original Estimate: Not Specified

Issue Links:
Relates
causality
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Epic Link: Support
Sprint: Maintenance 17, Maintenance 18, Maintenance 19
Story Points: 5

 Description   

If a configured reference property is mulit-valued (such as for example with the carousel of the travel-demo) the references cannot be resolved.



 Comments   
Comment by Sven Bach [ 23/Jul/18 ]

In the method info.magnolia.module.dependencies.impl.DefaultDependencies#getReferencesFromProperties(javax.jcr.Node, java.lang.String, java.util.List<java.lang.String>) on line 170:

 

169 try { 
170     dataString = data.getString(); 
171     List<String> ids = parseIds(dataString, workspaceToSearchIn);

 

The "getString();" method leads to an error.

property "foo" is a multi-valued property, so it's values can only be retrieved as an array

So i think there must be a check of the Property type and then overload the info.magnolia.module.dependencies.impl.DefaultDependencies#parseIds method.

protected List<String> parseIds(String[] dataStrings, String workspace) {
    

Or something else

Comment by Jonathan Ayala [ 24/Jul/18 ]

Find another use case to reproduce it here

Comment by Richard Unger [ 12/Dec/18 ]

We're affected by this in production. I will open a support ticket.

Comment by Richard Gange [ 12/Dec/18 ]

To me the challenge with this is all the different configurations (i.e. nestings, composites, ect.). Not to mention the transformers. I'm not convinced that changing a line or two of code is going to do it. There are a lot of cases to consider.

Comment by Richard Unger [ 12/Dec/18 ]

Well, I don't think that applies in this case, rgange The transformers are used to transform the dialog fields into the JCR structure, but the dependencies module operates on the JCR structure directly, not the dialogs. So the transformers don't matter, the nestings, composite, etc.. don't matter.

It all boils down to how the data is stored in a single JCR property, either multiple or not.

Admittedly there used to be a transformer that transforms to JSON within a string property, but I think this would be handled by the current RegEx based approach used for the RichText fields.

So I don't think complex dialogs are a hindrance when solving this issue. It's really only about multiple valued vs. single valued JCR properties.

Comment by Richard Gange [ 12/Dec/18 ]

The transformers are used to transform the dialog fields into the JCR structure, but the dependencies module operates on the JCR structure directly, not the dialogs. So the transformers don't matter, the nestings, composite, etc.. don't matter.

Yes, this is clear. But it's how you configure the dialog which ultimately determines how the data is stored. There is a relationship there. The transformers arrange the data differently.

Comment by Richard Unger [ 12/Dec/18 ]

Yes, this is clear. But it's how you configure the dialog which ultimately determines how the data is stored. There is a relationship there. The transformers arrange the data differently.

Agreed. But this relationship has no bearing on solving this bug, that's what I'm saying. If checked dependencies were configured on the dialog level, that would be very different. But since the dependencies module directly takes jcr properties as its input, it simply does not matter how complicated a dialog led to the property existing in JCR.

Generated at Mon Feb 12 00:12:26 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.