[MGNLUI-4264] Switchable Field default selection doesn't work Created: 15/Mar/17  Updated: 04/Aug/17  Resolved: 03/Aug/17

Status: Closed
Project: Magnolia UI
Component/s: forms
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Mariusz Chruscielewski Assignee: Federico Grilli
Resolution: Not an issue Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File contedit-50.png    
Issue Links:
Relates
relates to MGNLUI-4205 Setting "selected" is true in Select ... Closed
documentation
to be documented by DOCU-1095 Explain the behaviour of defaultValue... Closed
relation
is related to MGNLUI-4184 SelectField: field property 'selected... Closed
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: Content Editor fine-tuning
Sprint: Basel 107
Story Points: 5

 Description   

Hi, we are using Switchable Field Definition in new article editor app. In other (standard) app we can set one option to be selected by default (selected: true), this feature doesn't work in outlineFields.


Edit by assignee:
As mentioned by mgeljic in the comment section of this ticket, this is the expected behavior for an existing item. To recap

  • article definition adds or changes a SwitchableField with an option selected
    • existing article: no selection is applied
    • new article: selection is applied as you can see here


 Comments   
Comment by Philip Mundt [ 24/Jul/17 ]

When adding a simple info.magnolia.ui.form.field.definition.SwitchableFieldDefinition to the outline, default selection doesn't work.

Sample snippet:

test:
  class: info.magnolia.ui.form.field.definition.SwitchableFieldDefinition
  transformerClass: info.magnolia.ui.form.field.transformer.composite.DelegatingCompositeFieldTransformer
  options:
    - name: field1
      value: field1
    - name: field2
      value: field2
      selected: true
  fields:
    - name: field1
      class: info.magnolia.ui.form.field.definition.TextFieldDefinition
    - name: field2
      class: info.magnolia.ui.form.field.definition.TextFieldDefinition
Comment by Federico Grilli [ 31/Jul/17 ]

Hello mchruscielewski,

I can't reproduce the issue with the given configuration on upcoming content editor 1.0.6-SNAPSHOT, neither on Magnolia 5.5.6-SNAPSHOT, nor on 5.6-SNAPSHOT.
I placed the config given above by Philip in stories.yaml (config only slightly different with some labels and placeholders to make the UI more readable). Here it is

test:
  class: info.magnolia.ui.form.field.definition.SwitchableFieldDefinition
  transformerClass: info.magnolia.ui.form.field.transformer.composite.DelegatingCompositeFieldTransformer
  label: contedit-50 test
  options:
    - name: field1
      value: field1
    - name: field2
      value: field2
      selected: true
  fields:
    - name: field1
      label: field one
      class: info.magnolia.ui.form.field.definition.TextFieldDefinition
      placeholder: Add text one ...
    - name: field2
      label: field two
      class: info.magnolia.ui.form.field.definition.TextFieldDefinition
      placeholder: Add text two ...

And here is the visual result

EDIT:
Also saving the field seems to be working fine. Maybe I missed something in the configuration or the issue has been solved implicitly by something else which landed in UI 5.5.6+ and/or CONTEDIT 1.0.6.
Tried on 1.0.5 and got the same result. However, I could reproduce the issue in case of an existing article/story. In that case, adding the configuration actually did not work (no selection), whereas it works fine in case of a new article/story. I'll try to figure out what is going on there.

Comment by Mikaël Geljić [ 03/Aug/17 ]

Hi there,

Default values are only applied when the item is new.

What would happen if we applied default values for existing items?
Authors could open the dialog, see the default value, and decide to simply close/cancel the dialog—without realizing that value is not saved.

Do you observe this behavior when creating new articles?

It does not matter if the dialog definition changed.
Generally, when modifying dialog definitions, it might be a good idea to combine that with a new delta task, in the version handler; or at least with a groovy script (where then you can apply a default value to pre-existing content).

Hope this helps,

Comment by Federico Grilli [ 03/Aug/17 ]

mgeljic Thanks for clarifying this. I'll close the ticket as not an issue then and verify that documentation mentions this behaviour.

Generated at Mon Feb 12 09:14:58 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.