[MGNLUI-3313] Improve validation capabilities of the multi fields Created: 08/Jan/15  Updated: 27/Jun/16  Resolved: 17/Nov/15

Status: Closed
Project: Magnolia UI
Component/s: forms
Affects Version/s: 5.3.6
Fix Version/s: 5.3.12, 5.4.4

Type: Improvement Priority: Major
Reporter: Mikaël Geljić Assignee: Federico Grilli
Resolution: Fixed Votes: 4
Labels: support, ux, validation
Remaining Estimate: 0d
Time Spent: 1.25d
Original Estimate: Not Specified

Attachments: JPEG File CompositeField-Required.jpg     PNG File Design - Field with error.png     PNG File composite-error.png     PNG File no-validation-indicator-on-required-composite-field.png     PNG File switchable-validation-error.png    
Issue Links:
Cloners
clones MGNLUI-3227 Improve validation capabilities of th... Closed
Relates
relates to MGNLUI-3871 Missing red line in multi-value field... Closed
causality
dependency
is depended upon by MGNLUI-3625 SwitchableField should only validate ... Closed
is depended upon by MGNLUI-3527 Item count validation for multi field Closed
duplicate
is duplicated by MGNLUI-3090 Multivalue Field cannot be set as req... Closed
relation
is related to MGNLUI-3664 Display multiple error messages as st... Closed
supersession
supersedes MGNLUI-3312 SwitchableField doesn't work correctl... 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)
Date of First Response:
Sprint: Basel 20
Story Points: 8

 Description   

Quoting awedermp on cloned ticket:

I see some need to make it easier to make all fields of a composite field required, though I'm not sure this goes in the right direction.

Below I'm looking at these questions:

  • What does it mean, if we mark a composite field as required?
  • How do we indicate, if validation fails of at least one of its fields?
  • How do we visually mark a composite field as "required"?

I see three possible interpretations for it could mean to mark a composite field as "required":

  1. if a composite field is marked as "required", all its fields must have a value
  2. if a composite field is marked as "required", at least one of its fields requires a value
  3. if a composite field is marked as "required", at exactly one of its fields requires a value

We don't have to necessarily build all these cases, but we should make sure they remain possible, if we implement a shortcut.

As for showing a message on validation failure, I agree with @Topher: yes, we absolutely need that. In all cases, we should be fine by showing an error message on composite field level. I'd prefer if we could also show a message on the field level, if I have to indicate that one or several fields are missing. However, I would expect such a solution to become rather complex, as the good placement of this largely on form layout and field types.

Visually, we don't have a design for that, but I'd show such a messages on composite field level the same way as we currently do it for any other field. Just show it below the composite field with an arrow pointing towards it, but make sure we can show multiple lines:

   First name is required. 
   Last name is required.

As for how we should indicate if all fields of a composite fields are required, we could set the mark on either the composite field itself or on all its fields. We should be fine for both cases mentioned above if we just mark the composite field as "required", though. Again - and strictly speaking -, this actually depends a lot on the form layout and the complexity of the composite field. If a composite field spreads its field across multiple lines, it would be clearer to mark each individual field as "required". But I think we'll be fine if we just mark the composite as "required".



 Comments   
Comment by Mikaël Geljić [ 17/Feb/15 ]

Raising priority as this was reverted once already.

I do see the three potential interpretations of the required property for multi-fields in general (i.e. multivalue, composite and switchable fields).

But I also think we may come up with a sensible interpretation for each of them, individually:

  • MultiField would require at least one entry.
  • SwitchableField would require exactly its switch property to be set, i.e. the radio was explicitly selected. Whether subfield should have a value depends upon its respective required property.
  • CompositeField is more arguable.
    • It's already possible to mark individual sub-fields as required, on their respective definition.
    • A. Either it means all fields are required
    • B. Either at least one subfield is required
      • the "all" option remains possible by marking all subfield definitions as required (parent probably missing the asterisk then).
      • is more consistent with other multi-fields.
    • C. I would dismiss the "exactly one field" proposal — use a switchable field instead.
    • D. Fourth option: simply ignore the required property explicitly for composite fields.
      • Log a warning from the CompositeFieldFactory if one is configured as required
      • Consequently make sure we never show the asterisk on the composite field itself.

In any case, if the required property doesn't solve issues, we should make sure it is possible to set custom FieldValidators to implement these behaviors, and maybe provide some of them.

Comment by Mikaël Geljić [ 19/Feb/15 ]

We came up with specification above (see green marks); this may now be re-scheduled for maintenance.

Comment by Casper Biever [ 25/Mar/15 ]

Please make sure that invisible required fields aren't validated. Otherwise it might happen that a dialog cannot be saved due to validation errors on elements that cannot be edited because they are hidden (like we experienced with Switchable in 5.3.7).

Comment by Joerg von Frantzius [ 09/Nov/15 ]

Hi,

when a CompositeField recursively contains some required field, no matter whether the CompositeField is itself required, then intuitively I'd expect not to be able to save the dialog until that contained required field is filled. Do you per chance know whether that will be the case?

Comment by Mikaël Geljić [ 10/Nov/15 ]

Hi Joerg, as far as I know, this already works. Or did you face any particular issue with composite fields?

Comment by Federico Grilli [ 19/Nov/15 ]

weder FYI this is how it looks now a composite field error. The picture displays a component made up by two fields

  • text field
    • required
    • with an email validator attached
  • date field
    • required

As you can see the required sign shows up for the single fields and not at composite component level. Also the error indicator might be confusing in cases such as the one illustrated here, as the email error message obviously refers to the left text field but the arrow points to the date field instead. I know that is because the position of that arrow is fixed but I guess we could improve that in the future. Also I'm a bit annoyed by the top message and the "1 errors" and the "Jump to next error" link which here is pretty useless (and iirc the text is even hardcoded).

Comment by Andreas Weder [ 19/Nov/15 ]

Ok, thanks. The "required" marks here look good to me, given that each field of the composite field is actually required.

The top message is also ok. It mainly exists to mark the entire form as having a problem. That's especially important for those cases, where the actual error isn't visible, but below the fold or in another tab. It also means that there's a consistent location where validation errors are shown. Both are important points from the usability perspective. But I agree, in this case, the entire arrangement is a bit too much. There's actually an issue asking for more subtle error messages as they were originally designed, which will dissolve part of the "boom" this creates here.

As for the arrow... ok, that's a bit tricky. The arrow's supposed to be pointing towards the field that has the problem. That also works well for composite fields iff the field is highlighted using a red border. Then, it's basically irrelevant to which part of the composite field the arrow points to. I've attached you a design example that shows this.

Is this something you can still add?

Comment by Federico Grilli [ 19/Nov/15 ]

Thanks for the exhaustive response. The field actually already gets the validation-highlight css class applied but for some reason it's not displayed. I'll try to look into that.

Comment by Christian Menzel [ 23/Dec/15 ]

Hi Frederico, have you opened another ticket for the CSS issue? This problem also applies to switchable fields.

Comment by Federico Grilli [ 23/Dec/15 ]

Hi Christian, that was addressed by MGNLUI-3664 which was released with 5.3.12 and is going to land in 5.4.4. This is how e.g. a switchable field (but applies to any multi field) validation error looks like

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