changeset create: handle properties of complex Metadata Types (e.g. CustomObject)

[amtrack]

Handling changes in named children of complex Metadata Types is already supported (changes in a CustomField within a CustomObject).
However changes in properties of its own Metadata Type aren't supported yet (e.g. searchLayouts of a CustomObject).

The approach should be as @froucher drafted:

Given we create a change set with force-dev-tool
When a list of independent child is added/modified
Then it will create a change set with the list of independent "component" 
 And excluding any metadata of the parent metadata

Given we create a change set with force-dev-tool
When a list property that doesn't belong to an independent child is added/modified
Then it will create a change set with the all "metadata" 
 And excluding all independent child metadata

Given we create a change set with force-dev-tool
When a list of independent child is added/modified
 And a list property that doesn't belong to an independent child is added/modified
Then it will create a independent "component" with the property value
 And it will create a change set with the all "metadata" 

Looking at the code, I think most of the changes could be applied in metadata-file-container.js (parse, diff, toString).

[froucher]

Hello,

Then I will start with this PR.

Sorry but I think I found some issues in the behaviours definition:

Given a list of independent child that has been added/modified in the git repository
 When a user launches a change set with force-dev-tool
 Then it will create this change set with the list of independent "component" 
  And excluding any metadata of the parent metadata

Given a list of parent properties that doesn't belong to an independent child has been added/modified/removed in the git repository
 When a user launches a change set with force-dev-tool
 Then it will create this change set with all parent metadata
  And excluding all independent child metadata

Given a list of independent child has been added/modified in the git repository
  And a list of parent properties that doesn't belong to an independent child has been added/modified/removed in the git repository
 When a user launches this change set with force-dev-tool
 Then it will create a change set with the list of independent "component" and with all parent metadata

Right now, I am not sure about which must be the behaviour when some independent child is removed. @amtrack can you help me defining which is the expected behaviour?

Thanks and regards

[froucher]

Hi again,

Maybe the behaviour with a removed child is:

Given a list of independent child has been removed in the git repository
 When a user launches this change set with force-dev-tool
 Then it will create a destructive change with the list of independent "component"

Given a list of independent child has been removed in the git repository
  And a list of parent properties that doesn't belong to an independent child has been added/modified/removed in the git repository
 When a user launches this change set with force-dev-tool
 Then it will create a destructive change with the list of independent "component"
  And it will create this change set with all parent metadata

Thanks

[amtrack]

@froucher your last comment seems to be correct.

BTW creating a destructiveChanges.xml for e.g. a CustomField is already implemented: https://github.com/amtrack/sfdx-playground/tree/objects/config/deployments/expected

[froucher]

ok, thanks, I will keep you informed with the progress of the PR

[amtrack]

Thank you!

[froucher]

This is the PR #230 that we are working

[froucher]

Hello @amtrack, I am working to develop Compact Layout changes.

The PR #230, right now, works fine, it deploys right the changeset with new compact Layout.

Now I have found a new issue with Compact Layout, the destructiveChange.xml with compactLayout need to considered as a different component as the parent object to be removed.

This means that the solution need to consider CompactLayout as parent metadata when it is new or modification, but when it is removed it needs to be consider as a child component.

Do you agree with this?

Thanks

[amtrack]

@froucher I think CompactLayout can be treated as a named (standalone) metadata type.
I've adjusted the test. Please cherry-pick the commit if you agree: 72c2bca

Looking at the docs, I think the following indicates that the Metadata Type can be retrieved/deployed individually:

This type extends the Metadata metadata type and inherits its fullName field.

[froucher]

Hello @amtrack,

This is related to the issue #226, which talks about Compact Layout deployment and how it depends on 'label' property. We thought that the way to resolve this is that compact Layout was not treated as a named metadata.

Now, maybe we need to think about other solution.

Do you agree?

Thanks

[amtrack]

So the initial assumption about CompactLayout was wrong but we now know that CompactLayout can be treated similar to CustomField as an independent and named child type.

On the other hand, SearchLayouts still have to be seen as an essential part of CustomObject. I think the solution you developed is still very much needed.
We just have to be clear about which Metadata Type requires which solution.

[froucher]

Yes, you are right, thanks, I have checked your commit with Compact Layout test and it is an independent child, I do a rollback of the related changes, and I will fix that currently force-dev-tool creates a wrong package.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
-        <members>CustomObjectTest__c</members>
-        <name>CustomObject</name>
+        <members>CustomObjectTest__c.compactLayoutTest</members>
+        <name>CompactLayout</name>
    </types>
    <version>46.0</version>
</Package>

[froucher]

Hello @amtrack,

It seems it was very easy to resolve "Compact Layout" fix.

Please check the 723f8bd commit, I have added "isNamed: true" in the "lib/describe-metadata-service.js". Is it right?

Thanks

[froucher]

About SearchLayouts, it is working, I have added two tests in the following commit a228d8c

[amtrack]

🎉 This issue has been resolved in version 2.6.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀