Closed froucher closed 4 years ago
Hey @froucher, thank you very much for your very detailed report! I really appreciate that! 🙏
Yes, I agree that the changeset create
command needs to include required properties.
Additionally to CustomObject
this should also be the case for PermissionSet
, Profiles
and probably more Metadata Types.
Do you already have an idea on how to implement this? As you know, I've deprecated this project long time ago and didn't want to start new development but I'm open to collaborating on this. How about a web meeting to brainstorm and discuss a rough plan?
Hi,
Yes I would really appreciate your help with a web meeting.
During these days I have reviewed the code, but I am not sure where is the best point to add it.
Maybe the end of the 'changeset' process:
changeset.js
:
es.merge(stdin, metadataContainer.getStream())
.pipe(MetadataContainer.completeMetadataStream())
.pipe(MetadataContainer.outputStream({
apiVersion: apiVersion
}))
.pipe(vinylFs.dest(deploymentPath))
.on('end', function() {
callback(null, "exported metadata container to " + path.relative(proc.cwd, deploymentPath));
});
Inside of the function completeMetadataStream()
and completeMetadataWith()
MetadataContainer.completeMetadataStream = function(opts) {
opts = opts || {};
return miss.through.obj(function(metadataContainer, enc, cb) {
metadataContainer = metadataContainer.completeMetadataWith({
path: opts.path || 'src'
}).filter(metadataContainer.manifest);
metadataContainer.manifest.rollup();
metadataContainer.destructiveManifest.filterUnnamed();
cb(null, metadataContainer);
});
}
But not sure if it is the best point to add this patch.
Thanks.
I am working in the PR #228
As we have talked, we will reject the PR, because the solution must be implemented differently due to "Compact Layout" isn't a "independent child", that means can't be treated separately from the rest of the metadata file. So we are going to remove "Compact Layout" from ChildXmlName.
So the solution I understood in our talk is more o less:
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"
Do you agree with the above behaviours?
Thank you for your support.
@froucher Yes, I agree.
Let's continue this in #13 .
This is the new PR #232
resolved by #232
Custom Object with Compact Layout
When a Compact Layout is added to a Custom Object the change set can't be deployed, and it returns the following error:
Steps to reproduce the error
Create a new repository
Create the simplest Custom Object and commit
Init the folders
Add a
src/package.xml
file:Then, create a new file
src/objects/CustomObjectTest__c.object
with the following content:Commit this change
And deploy these changes in a new Salesforce Sandbox called
testSandbox
Add a Compact Layout and commit the change
Add a Compact Layout to
src/objects/CustomObjectTest__c.object
:Or if you want to create the Compact Layout directly in the Salesforce Setup then remember to retrieve the changes:
Commit this change:
And deploy these changes in a new Salesforce Sandbox called
testSandbox
Create a change set
Check differences between two last commits:
Will return:
So create a change set
The delta generates the following file
publish/delta/objects/CustomObjectTest__c.object
:If you try to deploy:
It will return the following in sequence errors:
Fixing the missing metadata then it will work:
Solution
I think the change set in Custom Object must always contains the following xml properties:
Do you agree with this solution? If you do then please let me know if I can help developing the required changes...