[PAGES-40] Default values do not work when editing optional areas Created: 14/Nov/13 Updated: 15/Apr/16 Resolved: 13/Oct/15 |
|
| Status: | Closed |
| Project: | Magnolia pages module |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.4.2 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Tom Wespi | Assignee: | Espen Jervidalo |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | backlog, support, ux | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| 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: | |||||||||||||||||||||||||
| Sprint: | Basel 17 | ||||||||||||||||||||||||
| Story Points: | 13 | ||||||||||||||||||||||||
| Description |
|
UPDATE: The scope of this ticket was reduced to optional areas only. Please see the comment for the reason why and a work-around. Unlike components, page and area nodes are created and edited in two distinct steps, so at the moment we don't know when they are actually new, and thus don't apply default values (regardless of field-type). This may be a custom behavior to implement specifically in the pages app. e.g. using an OptionGroupFieldDefinition and setting default option with the "selected" property: If dialog is called from component, it is working. To reproduce: Copy a OptionGroup e.g. from Form Module to a Area Dialog. No Value is selected. |
| Comments |
| Comment by Markus Koller [ 13/May/14 ] |
|
Still affected version: 5.2.4 |
| Comment by Adrian Andermatt [ 27/Nov/14 ] |
|
hey guys thanks and regards, Adrian |
| Comment by Richard Gange [ 17/Dec/14 ] |
|
Hi Adrian- Hopefully this will be part of 5.3.7. It seems to be of very common interest. Hope this helps |
| Comment by Mikaël Geljić [ 20/Jan/15 ] |
|
Reopened: Current fix affects option-groups configured as multiselect (checkboxes). In particular, if someone unselects all options, next time dialog is opened default option is wrongly selected again. The underlying explanation for the behavior in this ticket is that you're never getting a "new node" with auto-created areas, so you never get default values. Another option could be to introduce a nullable property in the definition, and only then set default value for non-multiselect option-groups. |
| Comment by Evzen Fochr [ 21/Jan/15 ] |
|
Imo preselection works correctly. It should work only for newly created Areas/Components. If OptionGroup is added to a dialog and dialog iss opened on already created Area/Component, it correctly shows that nothing was yet selected. |
| Comment by Mikaël Geljić [ 22/Jan/15 ] |
|
Reopening and rephrasing this issue. Unlike components, page and area nodes are created and edited in two distinct steps, so at the moment we don't know when they are actually new, and thus don't apply default values (regardless of field-type). We have to think about what options we have there. So chances are that we postpone it once again. Cheers, |
| Comment by Espen Jervidalo [ 13/Oct/15 ] |
|
This ticket has been partly resolved by opening the configured area dialog directly when creating optional areas, instead of creating the area and re-render the page. For auto-generated areas we already have a mechanism in place, which takes care of creating default-content for an area.
Details can be found in: info.magnolia.templating.elements.AreaElement#tryToCreateAreaNode info.magnolia.rendering.generator.CopyGenerator#generate I can imagine that this is a bit cumbersome compared to defining them directly in the dialog definition and we tried to find an acceptable solution for auto-generated areas as well. One solution we have implemented is to trick the form framework to treat auto-generated areas as if it was a ‘new’ node and hence setting the default properties. One other approach we considered was to replace to CopyGenerator by a much more sophisticated one and let it lend concepts from our form framework and read out the dialog-definition and the configured defaultValues. But in the end, we would have to take Transformers and Converters into account. And for this the framework really wasn’t designed in the first place. Forms, Transformers and Converters are built around Vaadin’s Item and must be kept away from the rendering. |
| Comment by Aleksandr Pchelintcev [ 15/Oct/15 ] |
|