[LIVECOPY-159] Fields under composite/switchable/multi fields are not protectable independently on parent field Created: 09/Sep/19  Updated: 16/Aug/22  Resolved: 19/Jul/22

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

Type: Improvement Priority: Neutral
Reporter: Evzen Fochr Assignee: Laura Delnevo
Resolution: Won't Do Votes: 2
Labels: blocked
Remaining Estimate: Not Specified
Time Spent: 1h 11m
Original Estimate: Not Specified

Attachments: PNG File city-protected.png     Zip Archive live-copy-test.zip    
Issue Links:
dependency
depends upon MGNLUI-5909 Subfields of complex fields do not sh... Closed
depends upon MGNLUI-7081 Provide the appropriate context for c... Closed
duplicate
is duplicated by LIVECOPY-313 Protecting single fields within a com... Closed
relation
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:
Epic Link: AuthorX Support

 Description   

Add protect/un-protect icon to fields that are under composite/switchable/multi field



 Comments   
Comment by Marvin Kerkhoff [ 03/Mar/22 ]

Hi guys, we have saw this issue in our enviornment. The current state is critical for us. All switchable link fields are not protected anymore. How could we solve this? Is there a workaround?

Comment by Patrik Jeller [ 17/Mar/22 ]

Some additional information:

With LiveCopy 3.2.3 nested fields were protectable but were not actually protected which leads to content being overwritten (this was at least the case for compositeFields and the PrefixNameDecorator), which is a major issue for us.

With the update to LiveCopy 3.2.7 the situation changed. Now it appears that in addition to the problem above, all nested fields (switchable, composite, etc) are missing the button to protect a field completely.
The cause of the issue may be located in the ProtectFieldButton class here:

if (dialogDefinition instanceof ConfiguredFormDialogDefinition) {
  return ((ConfiguredFormDialogDefinition)dialogDefinition).getForm().getProperties().stream().noneMatch((property) -> {
    return fieldDefinition.getName().equals(property.getName()) && this.checkIsAssignableFrom(fieldDefinition, property);
  });
} else { 

The code seems not to consider nested properties of the dialogDefinition instance and will therefore suppress the protect button for the nested field.

Comment by Pooja Bhavsar [ 24/May/22 ]

Hello Laura,

Is there an estimated timeframe for a solution for this ticket?  Currently, we have attempted all the suggestion by Magnolia however until the bugfixes are available, users will not be able to appropriately use the protect/unprotect feature.

Comment by Adrian Brooks [ 13/Jun/22 ]

After talking to Laura last week, a note has been added to the top of this section (for the time being): https://docs.magnolia-cms.com/product-docs/6.2/Special-Features/Live-Copy/Live-Copy-usage.html#_fields_in_a_component

Comment by Pooja Bhavsar [ 13/Jun/22 ]

Hi Adrian,

The note is useful however, how can we assist users working in Magnolia with this issue?  For example, our website has many country trees which are being pushed from master in multiple languages.  The protect/unprotect function is used to protect certain fields that should not be overridden. 

Comment by Laura Delnevo [ 17/Jun/22 ]

Hi pbhavsar, I am Laura, PM for Author Experience. Thanks for your comments. We are looking at your further feedback, and I will be posting an update as soon as we can. 

Comment by Pooja Bhavsar [ 01/Jul/22 ]

Hi ldelnevo,

 

Is there any update on this ticket?  We have completed all actions suggested but are still seeing this issue.  Thanks.

Comment by Pooja Bhavsar [ 18/Jul/22 ]

Hi ldelnevo,

I noticed that this ticket would not be fixed and is closed.  Can you please provide a workaround and reason as to why this is closed without a resolution?

Comment by Laura Delnevo [ 19/Jul/22 ]

Hi pbhavsar 

Sure thx for asking. The blocker we're facing is a vaadin8 dependency that does not support the desired functionality in multi/complex fields. Atm, I'm afraid that there's no existing workaround that we're aware of that could be considered. 

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