[LIVECOPY-265] Protected Fields in combination with defaultLocal Created: 16/Jun/21  Updated: 16/Sep/21  Resolved: 18/Aug/21

Status: Closed
Project: Live Copy
Component/s: None
Affects Version/s: 3.2.3
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Tobias Kerschbaum Assignee: Chuong Doan Huy
Resolution: Won't Fix Votes: 1
Labels: VN-Analysis, cm-team-support, maintenance
Remaining Estimate: Not Specified
Time Spent: 3d 5h
Original Estimate: Not Specified

Attachments: File config.modules.multisite.config.sites.pageA.yaml     File config.modules.multisite.config.sites.pageB.yaml     PNG File protectedFieldsWithDefaultLocale.png     PNG File protectedFieldsWithoutDefaultLocale.png     XML File website.xml    
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
Documentation update required:
Yes
Date of First Response:
Epic Link: Live Copy maintenance
Sprint: Content Mngmt 10
Story Points: 5

 Description   

Steps to reproduce

  1. Import Site configuration and website workspace as attached
  2. Create a Text/Image Component in SiteA
  3. Push the changes to SiteB
  4. Protect all the headline fields of the pushed component
  5. Look into the jcr of the component and check the property propertiesToIgnore
  6. Delete the defaultLocale property from the site config of pageB
  7. Delete the propertiesToIgnore property of the component
  8. Protect the headline fields again
  9. Look again into the jcr of the component

Expected results

I would expect that the defaultLocale has no impact on the behavior of field protection. 

Actual results

As you can see on the Screenshot, when the defaultLocale is set, the wrong fieldKey is protected.

With default locale:

 

Without defaultLocale:

Workaround

Development notes



 Comments   
Comment by Fabian Bading [ 16/Jun/21 ]

This bug is an issue for our go-live of the new Aurubis Page.

Comment by Chuong Doan Huy [ 16/Aug/21 ]

Hi tobias.kerschbaum,
after investigation how i18n's currently working, i would say that this use case is not supported yet even in Magnolia system, not just only Livecopy. Because defaultLocale/masterLocale is very important, it is used to define how to load and save values. For example, if you have 3 locales : en, fr, nl and setting en as default locale, en will be preselected AND MORE IMPORTANTLY, the input values wil be saved like this : headline (no suffix) for default locale (en), headline_fr and headline_nl
Because the one with no suffix will be automatically matched with default locale, when you create a Livecopy page, and change defaultLocale/masterLocale to another one that is not en, for exemple nl, problem happens : when you open page/dialog, preselected language is nl, but value will be en (because it get the property with no suffix for default locale)
This is also why protect feature of LC also not working correctly.
----------
So defaultLocale/masterLocale is super important, it decides preselected and PROPERTY NAME of a field, so changing defaultLocale after values are saved will affect the system greatly. Currently the only workaround for this is re-enter values for your new defaultLocale.

Comment by Tobias Kerschbaum [ 16/Aug/21 ]

Hey chuong.doan ,
In principle, this is exactly what I tried to describe in the briefing call back then. I'm sorry if I couldn't convey it so clearly. From my point of view, the only way to fix this would be to always append the language suffix to the properties, regardless of whether it is the fallbackLocale or not.

If there is no other good way, however, we should definitely point out in the documentation that this doesn't work and may create overhead if the fallbackLocale needs/should be changed.

Comment by Chuong Doan Huy [ 16/Aug/21 ]

Thank you for the clarification. I agree that always append language suffix is a good way to overcome this pain.
Although that proposal changes probably won't happen in the near future due to complexity and huge affect, feel free to create a ticket in Platform or dx-core module to mention it.
Within Livecopy scope, i will add this limitations to the documentation, thanks.

Generated at Mon Feb 12 02:27:04 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.