search

scolladon / sfdx-git-delta

Generate the sfdx content in source format from two git commits
Other
414 stars 112 forks source link

feat: deactivate Flow instead of trying to delete #893

Closed amtrack closed 1 month ago

amtrack commented 1 month ago

Explain your changes

When a Flow is detected in destructiveChanges.xml and the --generate-delta flag is given

Does this close any currently open issues?

closes #588, #366

Any particular element that can be tested locally

Any other comments

codeclimate[bot] commented 1 month ago

Code Climate has analyzed commit 2ab1198c and detected 0 issues on this pull request.

View more on Code Climate.

codecov[bot] commented 1 month ago

Codecov Report

Attention: Patch coverage is 59.25926% with 11 lines in your changes missing coverage. Please review.

Project coverage is 98.99%. Comparing base (f79d3dc) to head (2ab1198).

Files Patch % Lines
src/post-processor/deactivateFlowProcessor.ts 57.89% 8 Missing :warning:
src/utils/packageHelper.ts 25.00% 3 Missing :warning:
Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #893 +/- ## =========================================== - Coverage 100.00% 98.99% -1.01% =========================================== Files 39 40 +1 Lines 1066 1093 +27 Branches 115 119 +4 =========================================== + Hits 1066 1082 +16 - Misses 0 11 +11 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

scolladon commented 1 month ago

Hi @amtrack,

Thanks for your work here, it made the topic hot again !

We discussed this with @mehdicherf and we tried to think of how it would change the usage of sgd and how it would force or allow users to have their own workflow. What came out is that we prefer to not force the user to follow this workflow as it based on FlowDefinition (v44 or below). We prefer users to not follow any workflow and prefer allowing anyone to build their own using the tool.

What we think could be done in this PR is to just add a warning inside the work object (work.warnings.push basically) just to let the user know he is trying to add Flow into a destructiveChanges.xml and it will probably not do what he expects. It could use the content here and create a section in the README the message can point to.

So you could create another service extending standardHandler, just for Flow. and override the handleDeletion to add the warn while calling super.handleDeletion. I can take care of creating this new PR, make the change in the README and add you as a reviewer if you like ?

amtrack commented 1 month ago

@scolladon OK, I understand this decision. Having a warning message printed asking the users to upvote the Salesforce Known Issue and pointing out some workarounds sounds good to me. Yes, please take over implementing the warning message.