[MGNLUI-3491] Switching the language in a content app bypasses validation Created: 08/Jul/15  Updated: 24/Oct/18  Resolved: 30/Dec/16

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.3.9, 5.4, 5.5
Fix Version/s: 5.5.1

Type: Bug Priority: Neutral
Reporter: Fabian Schneider Assignee: Ngoc Nguyenthanh
Resolution: Fixed Votes: 0
Labels: estimate-with-uncertainty, forms, i18n, needs-concept, support, ux
Remaining Estimate: 0d
Time Spent: 2d 0.5h
Original Estimate: 3d

Attachments: PNG File blank-field.png     PNG File reopen.png     PNG File switched language.png    
Issue Links:
Relates
causality
is causing MGNLUI-4729 Revise the field validation when swit... Closed
dependency
relation
is related to MGNLUI-3490 Investigate the possibility to stream... 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: Form field attributes handling
Sprint: Saigon 75, Saigon 76 (xmas)
Story Points: 5

 Description   

Through switching the current language it is possible to save a content app form despite blank required fields.

Reproduce:

1. Go to the tours app on the demo instance.
2. Open a random tour, delete the name field and try to save the form.
The form displays a validation error.

3. Change the current language through the language switcher and save the form again.

The form saves without errors. A reopening of the form demonstrates that the required field has been saved without content.



 Comments   
Comment by Vivian Steller [ 08/Jul/15 ]

Affected version is 5.3.9

Comment by Andreas Weder [ 04/Sep/15 ]

Ok, so we've discussed this and have basically identified two approaches to handle this:

  1. We always validate all locales and show an error message, if there are errors in any locale.
  2. We only validate the currently selected locale and only allow you to switch locales, if there are no errors.

After some discussion, the pendulum swung more towards approach 2, as it seems to be simple and easy to understand. However, it seems that approach 1 is also straight forward to implement. Both approaches need some kind of empty form detection (see below) if done right, but we felt that approach 2 might work better without it. Both approaches also suffer from the drawback that there's currently no way to remove a specific locale, which especially works bad if you use one particular locale as fallback for all others.

However, we have to take this step-by-step. Since we're leaning more towards 2, I'd like to ask development to please research approach #2 some more, if need, and provide an estimate for it. If you happen to detect additional information on approach 1, please add them as well.

On the empty form detection

Both approaches are affected by the way locale switching is implemented currently. When you switch to a new locale, that new locale is immediately persisted. As a result, if you only switch to a new locale and enter no values, this causes errors by all required fields and others that don't validate. Since there's no way to remove a locale, you're stuck with having to fill-out that locale. One other consequence of this is that there's no way to return to a particular locale you might use as fallback locale.

One way to resolve this would be to implement a detection for empty forms: if you don't fill out any values, the locale is considered empty and thus no validation will take place. It seems, however, that this is not so easy to do reliably with how things are currently.

So this is why we felt that, instead of implementing a complex way of validating currently invisible locales, we feel that things remain easier to understand, if we just validate the currently selected locale when you attempt to switch to a different locale.

Comment by Jan Haderka [ 07/Sep/15 ]

Unfortunately both of the proposed solutions would result in quite serious undesired side effects. To that effect bigger conceptual work is necessary in regard on how to work with i18n-ized content apps. Due to the expected changes necessary in the framework to make convenient work with multiple languages possible, change cannot be done in minor release but will be included in one of the next major releases.

Thank you for your understanding.

Comment by Ngoc Nguyenthanh [ 23/Dec/16 ]

Copied the comment of mgeljic in DEV-334

Raised in prio meeting, to be discussed in Architects meeting next Tuesday.
— update from architects:

    solution is good to go and generally preferred over current status, even despite the described limitation
    we complement that with a tooltip over the language-selector, emphasizing this behavior

At a later stage:

    we want to synchronize the behavior of language-switching vs. cp13n variant-switching (the latter currently saves and reloads the dialog).

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