search

scolladon / sfdx-git-delta

Generate the sfdx content in source format from two git commits
Other
429 stars 115 forks source link

SharingRules and Workflow Subtypes extracted #99

Closed DougMidgley closed 3 years ago

DougMidgley commented 3 years ago

Issue verification check :

[No] does the current repository is fully deployable at the commit sha given to the from parameter of the command ?

What is the problem

When getting deltas for SharingRules and Workflows the subtypes are extracted instead of the main types. For example WorkflowAlert instead of Workflow SharingCriteriaRule instead of SharingRules

It seems that these subtypes are not able to be deployed but no errors are thrown.

What is parameter and their value you used

sfdx sgd:source:delta --to origin/$source --from origin/$target --output src_delta/ -d -a $(apiversion)

What is the expected result

Extracted files match the main metadata package.xml OR at least are deployable.

`<?xml version="1.0" encoding="UTF-8"?>

SOMEworkflow Workflow 51.0 ` ### What is the actual result Extracted package.xml for sharingrules or workflow subtypes are essentially ignored ` SOMEworkflow WorkflowAlert 51.0 ` ## Steps to reproduce generate delta containing one of the examples mentioned above ## Execution context Windows 10 Node 15.5.1 sgd 4.2.0 ## Optional more information
scolladon commented 3 years ago

Hi @DougMidgley !

Thanks for your issue ! Very detailed !

The plugin checks for the changes in the files in order to being able to deploy only the changed sub elements. This allow the plugin to detect when a WorkflowRule has changed in the file and to deploy only this change. Or it allow the plugin to detect when a WorkFlowFieldUpdate has been deleted and to put it in the destructiveChanges.xml.

What do you mean by

It seems that these subtypes are not able to be deployed but no errors are thrown.

What is the issue here exactly and how should I reproduce it ?

barouchk commented 3 years ago

Hi Scolladon,

The issue is, that SFDX doesn't know to deploy SharingCriteriaRules with the SharingRule attached to it. So, when there is a change in SharingCriteriaRule you MUST add the Sharing rule tag as well.

example:

Lead SharingRules 
<types>
    <members>Lead.criteria1</members>
    <members>Lead.criteria2</members>
    <name>SharingCriteriaRule</name>
</types>

the workaround for this issue is to create manually package.xml with the sharing rule.

Hope you can fix this issue quickly, it can be very helpful !!

Thanks.

scolladon commented 3 years ago

Hi @barouchk !

That's a nice gack in the sfdx command line you just find ! Here is what I tried and the result :

Deploying only SharingOwnerRule

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Lead.Test</members>
        <name>SharingOwnerRule</name>
    </types>
    <version>50.0</version>
</Package>

Using sfdx force:source:deploy => The command return. Fail silently No results found

Using sfdx force:mdapi:deploy => The command display an error. Fail explicitly Error manifest/package.xml Lead.Test An object 'Lead.Test' of type SharingOwnerRule was named in package.xml, but was not found in zipped directory

Deploying the full SharingRules works

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Lead</members>
        <name>SharingRules</name>
    </types>
    <version>50.0</version>
</Package>

sfdx force:source:deploy -x manifest/package.xml => Lead SharingRules force-app/main/default/sharingRules/Lead.sharingRules-meta.xml

Until now everything follows the documentation :

You can’t retrieve, delete, or deploy manual sharing rules or sharing rules by their type (owner, criteria-based, territory, or guest user).

Do you think this is weird ? Hum, yes quite weird but go on reading...

Retrieving the full SharingRules works

As the SharingOwnerRule is deployed, I tried to retrieve it using the explicit metadata type : 

<!--package.xml-->
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Lead.Test</members>
        <name>SharingOwnerRule</name>
    </types>
    <version>50.0</version>
</Package>

sfdx force:source:retrieve -x manifest/package.xml And it worked !! the SharingOwnerRule has been retrieved...

Deleting the full SharingRules works

As the SharingOwnerRule is deployed, I tried to delete it using the explicit metadata type : 

<!--package.xml-->
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Lead.Test</members>
        <name>SharingOwnerRule</name>
    </types>
    <version>50.0</version>
</Package>

<!--destructiveChanges.xml-->
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Lead.Test</members>
        <name>SharingOwnerRule</name>
    </types>
</Package>

sfdx force:mdapi:deploy -d manifest --ignorewarnings And it worked !! the SharingOwnerRule has been deleted...

Synthesis

So my take away here are :

  1. Deploying sharing rules works only if the deployment deploy the whole file
  2. Retrieving sharing rules works with the subtype
  3. Deleting sharing rules works with the subtype

So, according to the documentation, the points 2 and 3 should not be possible... My point of view in term of developer experience is that point 2 and 3 are good and it should also be possible to deploy subtype, not only retrieve/delete, for those reasons :

Workflow have the same behavior, I just tested. This is not possible to deploy Workflow subtype and possible to retrieve/delete subtypes CustomLabels work very fine with explicit manifest in deploy, retrieve and delete

What I suggest is to fix that by adding a SharingRule/Workflow type with the Object API name as member when catching changes in those files (.sharingRules-meta.xml .workflow-meta.xml) to ensure deployability, only in package.xml. It could be a clean way to workaround this behaviour until it is fixed in the sfdx command line (I did not find a bug related to that already on their side). The only drawbacks is it will deploy all the content of the file if only using the generated package.xml, but not if using the generated delta files ;)

Should we implement this in a minor fix ? Could be done prettry fast.

Should we generate a bug in the sfdx CLI ?

What do you think @mehdisfdc @barouchk ?

PS version of the sfdx command line used for the tests : sfdx-cli/7.82.1-0 darwin-x64 node-v15.8.0

barouchk commented 3 years ago

Hi Scolladon,

Nice Investigation !!!

I just test again: if you have one SharingRule with 5 SharingRuleCriteria

  <types>
        <members>Lead</members>
        <name>SharingRules</name>
    </types>
    <types>
        <members>Lead.criteria1</members>
        <members>Lead.criteria2</members>
        <members>Lead.criteria3</members>
        <members>Lead.criteria4</members>
        <members>Lead.criteria5</members>
        <name>SharingCriteriaRule</name>
    </types>

and you are pulling only 2 of them like that:

    <types>
        <members>Lead</members>
        <name>SharingRules</name>
    </types>
    <types>
        <members>Lead.criteria1</members>
        <members>Lead.criteria2</members>
        <name>SharingCriteriaRule</name>
    </types>

you will get all 5 SharingCriteriaRules inside the Lead.SharingRule XML file.

The same thing will happen if you will pull only the Lead.SharingRule.

So I don't think you need to implicit the SharingCriteriaRule type inside the package.xml when deploying but only in the destructive package.xml

struthe commented 3 years ago

Hi all,

I noticed today that the same issue occur when deploying changed Workflow. If your create a new Workflow the subtypes and the workflow itself will be added to package.xml and the deployment works fine.

When you modify an existing workflow the subtyes are added but not the workflow itself. Now the force:source:convert command does not add the workflow metadata to the output directory and the deployment ignores the Workflow changes.

Logging forward for a fix of this "issue"

Kind regards

DougMidgley commented 3 years ago

Hey Guys! Indeed seems to reflect the issues I have been having. From my side, we use the tool to reduce the time to deploy overall, so if making it work means we have to deploy all Workflow Rules rather than just specific ones, that's life. From a code perspective, it shouldn't actually cause any issues, since it would deploy only things that are in the branch, but it would mean that the deploy could be slightly longer - I would see it as a fair trade off. There is indeed an issue, but seems ignored by the SFDX team :( https://github.com/forcedotcom/cli/issues/6 (technically it says owned by another team but i find that a little poor as an excuse without a comment at least) I also see the documentation here - https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_sharingrules.htm - showing a package.xml example with SharingCriteriaRule which seems contradictory to the statement at the top of the same page (which you rightly state above).

scolladon commented 3 years ago

Thanks for your comments guys, I see a lot of traction here.

We will ship soon a minor patch to cover this gack in the sfdx cli.

Stay tuned !