-
-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add WorkflowFlowActions
metadata support
#976
Conversation
WorkflowFlowActions
metadata support
Hi @mcarvin8 ! Thank you very much for this contribution. First I'm not sure the Also, I don't understand why there is a pilot on Workflow as it will be deprecated soon. In term of tests you can improve the inFileHandler.test.ts by adding the type here and by a on of the test to test this type in particular (just change the |
Here's an example of a flow action which does have the I understand it definitely is weird for them to have this now that workflows are deprecated, but in my org and with the current decomposed workflow preset, I was unable to deploy individual workflow children like Email Alerts with the workflows that had workflow flow actions since those flow actions were in the parent XML file. It seems like the decomposed workflow preset by Salesforce works best when the parent XML file remains an empty file. When I manually updated the This is probably a small use case of users who may experience this issue (i.e. ones who have any flow actions) but if they an old large org like my work org, they might have the same issue as me. "registryCustomizations": {
"childTypes": {
"workflowalert": "workflow",
"workflowfieldupdate": "workflow",
"workflowknowledgepublish": "workflow",
"workflowoutboundmessage": "workflow",
"workflowrule": "workflow",
"workflowsend": "workflow",
"workflowtask": "workflow",
"workflowflowaction": "workflow"
},
"strictDirectoryNames": {
"workflows": "workflow"
},
"suffixes": {
"workflow": "workflow"
},
"types": {
"workflow": {
"children": {
"directories": {
"workflowAlerts": "workflowalert",
"workflowFieldUpdates": "workflowfieldupdate",
"workflowKnowledgePublishes": "workflowknowledgepublish",
"workflowOutboundMessages": "workflowoutboundmessage",
"workflowRules": "workflowrule",
"workflowSends": "workflowsend",
"workflowTasks": "workflowtask",
"workflowFlowActions": "workflowflowaction"
},
"suffixes": {
"workflowAlert": "workflowalert",
"workflowFieldUpdate": "workflowfieldupdate",
"workflowKnowledgePublish": "workflowknowledgepublish",
"workflowOutboundMessage": "workflowoutboundmessage",
"workflowRule": "workflowrule",
"workflowSend": "workflowsend",
"workflowTask": "workflowtask",
"workflowFlowAction": "workflowflowaction"
},
"types": {
"workflowalert": {
"directoryName": "workflowAlerts",
"id": "workflowalert",
"name": "WorkflowAlert",
"suffix": "workflowAlert",
"xmlElementName": "alerts"
},
"workflowfieldupdate": {
"directoryName": "workflowFieldUpdates",
"id": "workflowfieldupdate",
"name": "WorkflowFieldUpdate",
"suffix": "workflowFieldUpdate",
"xmlElementName": "fieldUpdates"
},
"workflowknowledgepublish": {
"directoryName": "workflowKnowledgePublishes",
"id": "workflowknowledgepublish",
"name": "WorkflowKnowledgePublish",
"suffix": "workflowKnowledgePublish",
"xmlElementName": "knowledgePublishes"
},
"workflowoutboundmessage": {
"directoryName": "workflowOutboundMessages",
"id": "workflowoutboundmessage",
"name": "WorkflowOutboundMessage",
"suffix": "workflowOutboundMessage",
"xmlElementName": "outboundMessages"
},
"workflowrule": {
"directoryName": "workflowRules",
"id": "workflowrule",
"name": "WorkflowRule",
"suffix": "workflowRule",
"xmlElementName": "rules"
},
"workflowsend": {
"directoryName": "workflowSends",
"id": "workflowsend",
"name": "WorkflowSend",
"suffix": "workflowSend",
"xmlElementName": "send"
},
"workflowtask": {
"directoryName": "workflowTasks",
"id": "workflowtask",
"name": "WorkflowTask",
"suffix": "workflowTask",
"xmlElementName": "tasks"
},
"workflowflowaction": {
"directoryName": "workflowFlowActions",
"id": "workflowflowaction",
"name": "WorkflowFlowAction",
"suffix": "workflowFlowAction",
"xmlElementName": "flowActions"
}
}
},
"directoryName": "workflows",
"id": "workflow",
"inFolder": false,
"name": "Workflow",
"strategies": {
"adapter": "decomposed",
"decomposition": "folderPerType",
"transformer": "decomposed"
},
"strictDirectoryName": true,
"suffix": "workflow"
}
}
}, |
I can work on updating the inFileHandler.test.ts for this |
94f748a
to
db23be8
Compare
I see your point @mcarvin8 I'm a bit scared about the Then we could just work on the unit tests |
That is very fine, thank you @mcarvin8 ! |
If you wanna validate this with the cli-friends slack channel, go for it. I worked with Steve Hetzel in the SDR repo after I opened an issue in the main CLI issues repo. Didn't know they had a slack channel for outside help lol Here's what I had in their repos originally: (GitHub issue forcedotcom/cli#2563, source-deploy-retrieve PR forcedotcom/source-deploy-retrieve#1467) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job !
Thanks for the contribution
I want to wait for the validation from sfdx about the key
@@ -82,7 +83,7 @@ describe.each([true, false])(`inFileHandler -d: %s`, generateDelta => { | |||
// Assert | |||
expect(work.diffs.destructiveChanges.size).toEqual(0) | |||
expect(work.diffs.package.get('Workflow')).toEqual(new Set(['Account'])) | |||
expect(work.diffs.package.get('WorkflowAlert')).toEqual( | |||
expect(work.diffs.package.get('WorkflowFlowAction')).toEqual( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praises: nice
I think it is enough for the unit test
parentXmlName: 'Workflow', | ||
xmlName: 'WorkflowFlowAction', | ||
xmlTag: 'flowActions', | ||
key: 'fullName', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought: I'd really like a validation from sfdx
db23be8
to
0b6a2ab
Compare
Code Climate has analyzed commit 0b6a2ab and detected 0 issues on this pull request. View more on Code Climate. |
Rebased from |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #976 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 44 44
Lines 990 990
Branches 103 103
=========================================
Hits 990 990 ☔ View full report in Codecov by Sentry. |
I @mcarvin8 ! I come for news, have you been able to see with the sf cli team if the |
@scolladon - I wasn't sure how to validate with CLI team, to be honest I thought you were checking lol Looking at your earlier message about some slack channel, I'm not sure how to see that?? |
My bad, I thought you wanted to interact with them.
There is a slack channel named cli-friends where we can discuss with the engineering team of the sf cli product Give me your email and I'll add you |
@scolladon can you have Vivek please resend that slack invite to my work email instead? [email protected] Having issues joining with my personal email so it might be easier just to use the work one which already is connected to slack. |
https://developer.salesforce.com/docs/atlas.en-us.254.0.api_meta.meta/api_meta/meta_workflow.htm Explains why my org can use flow actions. Whomever opted into the pilot program can still use them. |
Here's a sample decomposed workflow flow action: Based on this, looks like <?xml version="1.0" encoding="UTF-8"?>
<WorkflowFlowAction xmlns="http://soap.sforce.com/2006/04/metadata">
<fullName>Populate_PBA_from_Primary_CDM_User_record</fullName>
<flow>Populate_Account_PBA_from_Primary_CDM_User_record</flow>
<flowInputs>
<name>AccountID</name>
<value>{!Id}</value>
</flowInputs>
<flowInputs>
<name>AccountOwner</name>
<value>{!CDM__r.Id}</value>
</flowInputs>
<label>Populate PBA from Primary CDM User record</label>
<language>en_US</language>
<protected>false</protected>
</WorkflowFlowAction> |
That is great, thanks for digging this @mcarvin8 Can you show the content of the workflow file when it is not decomposed please ? |
@scolladon - here's a screenshot from the original workflow file not decomposed. <flowActions>
<fullName>Populate_PBA_from_Primary_CDM_User_record</fullName>
<flow>Populate_Account_PBA_from_Primary_CDM_User_record</flow>
<flowInputs>
<name>AccountID</name>
<value>{!Id}</value>
</flowInputs>
<flowInputs>
<name>AccountOwner</name>
<value>{!CDM__r.Id}</value>
</flowInputs>
<label>Populate PBA from Primary CDM User record</label>
<language>en_US</language>
<protected>false</protected>
</flowActions> |
I think we've talked about this previously in my plugin, but Workflow Flow Actions was missing in the Salesforce metadata registry. When opting into Salesforce's decomposed workflows, this caused my flow actions in my org to be decomposed in the parent file.
I recently contributed to SDR via forcedotcom/source-deploy-retrieve#1467 to add Workflow Flow Actions to the overall metadata registry and the decomposed workflows preset. This was accepted by Salesforce and looks to be on track to be in the next CLI release. This will require sfdx-git-delta to be updated to detect decomposed workflow flow actions when this update is released to the public.
Based on the open PR in https://github.com/forcedotcom/cli, this update will be included in the 2.72.21 (Jan 15, 2025) build.
Does this close any currently open issues?
No open issues but this will cause an issue if left unresolved once Salesforce CLI 2.72.21 is released and users attempt to use sfdx-git-delta to detect changes to decomposed workflow flow actions afterwards.
Any particular element that can be tested locally
You have existing decomposed tests already, not sure if you want to update/add this specific metadata type to the test or not. This is my first true contribution to sfdx-git-delta, so I'll leave the call up to you if you want me to add/update any tests for this metadata registry update.
Any other comments
Depends on Salesforce CLI release 2.72.21 (Jan 15, 2025) build. Probably want to release it around then to coincide with users using the latest available CLI.