[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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:
I see three possible interpretations for it could mean to mark a composite field as "required":
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:
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
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 |