Details
-
Improvement
-
Resolution: Unresolved
-
Low
-
None
-
None
-
None
-
None
Description
Added business value
Low. It's only about how MultiField nodes look in JCR view - whether they are named consistently. Does not affect functionality.
Current situation
Once MGNLUI-6190 / MGNLUI-6253 is integrated, we'll allow resolving multi-field nodes that do not follow the naming convention strictly. However, such nodes retain their inconsistent names.
E.g.
multi:
0:
field: 0_value
00:
field: 00_value
multi:
field: someText_value
multi1:
field: someText1_value
something1:
field: someText1_value
someText1_de:
field: someText1_de_value
would, after resaving, turn into
multi:
0:
field: 0_value
1:
field: 00_value
multi2:
field: someText_value
multi3:
field: someText1_value
something4:
field: someText1_value
someText1_de: #stays ignored b/c of locale suffix that will cause the node not to be resolved
field: someText1_de_value
So the prefixes stay empty or whatever they were before, and the numbers get updated.
The implementation reuses whatever prefix it finds via regex when handling a node. This means inconsistent prefixes stay inconsistent.
Desired situation
- Either we will rename the node after resolving right away since we detect its name is bad (this would be a change outside of OrderHandler, and not sure if it's possible)
- or the order handler will have to know the MultiField's name so it can stop guessing the prefix and replace whatever is there.
Or we won't care about it. It's only a question of looks in the JCR browser.
Checklists
Acceptance criteria
Attachments
Issue Links
- split from
-
MGNLUI-6253 Allow MultiFields using jcrChildNodeProviders to read children regardless of their names (followup to 6190)
-
- Closed
-