[MGNLUI-6306] Investigate the need for supporti18n property in non-deprecated context Created: 09/Oct/20  Updated: 18/Feb/21  Resolved: 17/Feb/21

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: 6.2.7

Type: Improvement Priority: Neutral
Reporter: Šimon Demočko Assignee: Šimon Demočko
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 40m
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by MGNLUI-5821 Introduce supportI18n property for Jc... Closed
Relates
relates to DOCU-2129 supportI18n in 6.2.1 release notes is... 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)
Release notes required:
Yes
Date of First Response:
Epic Link: MultiFields compatibility
Sprint: UI FW 22
Story Points: 1

 Description   

Current situation

Definition is not checked for supporti18n in info.magnolia.ui.editor.JcrIndexedChildNodeProvider#constructTargetSubNodeName the same way it is checked in info.magnolia.ui.editor.JcrChildNodeProvider#constructTargetSubNodeName
 
It seems like info.magnolia.ui.editor.JcrChildNodeProviderDefinition#supportI18N was introduced for compatibility purposes but leaks to new UI.

Desired situation

I18n logic should likely rely on i18n of ConfiguredComplexPropertyDefinition instead of supporti18n (or rely on i18n config of when using the childNodeProvider)

There are now three ways of configuring i18n in, e.g., a multi.

  • On the inner field level,
  • on the multi-field level, and also
  • on the child provider level. The third one should not be made available. We need to test what consequences would use of it introduce. (consider if the fact that it's released means we cannot remove it anymore)

Write a test for the behavior of this. 



 Comments   
Comment by Šimon Demočko [ 08/Feb/21 ]

The field was introduced only to support reading data from old Magnolia. You can see an example here]. 

In new Magnolia, the usage of this property should be clearly marked as deprecated. This should have also been marked in https://docs.magnolia-cms.com/product-docs/Releases/Release-notes-for-Magnolia-CMS-6.2.1.html#_new_supporti18n_property_in_jcrchildnodeprovider, consult possibility of adding the deprecation note retroactively or mark it as deprecated now and note in new release notes. Otherwise, the release notes sound as if this was a new feature we introduced we're okay with customers using (though we don't have documentation for it).

Implementation-wise, there's nothing we can do about it at the moment, it needs to stay there as long as we support reading and writing such structures.

We should mark the property as deprecated though. 

Comment by Šimon Demočko [ 16/Feb/21 ]

Removed release notes and documentation update required because of split to DOCU-2129

Comment by Šimon Demočko [ 17/Feb/21 ]

checked Release notes again as per https://magnolia-cms.slack.com/archives/DQB8U1ZM4/p1613561328004900?thread_ts=1613560858.002700&cid=DQB8U1ZM4 

From Ashraf to release doc person: It should probably say something along the lines of: "With this release, the supportI18N property has been deprecated. Setting supportI18N to false is still necessary in certain compatibility configurations (for example, when porting configurations
that use Magnolia 5 UI multi field transformers)."

Comment by Ashraf Khamis [ 17/Feb/21 ]

For more context, see the updated 6.2.1 release note: https://docs.magnolia-cms.com/product-docs/Releases/Release-notes-for-Magnolia-CMS-6.2.1.html#_new_supporti18n_property_in_jcrchildnodeprovider.

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