[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: |
|
||||||||
| 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 ] |
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 ] |
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. |