[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: |
|
||||||||||||||||||||||||
| 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: | |||||||||||||||||||||||||
| 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. 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:
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 detectionBoth 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).
|