Add ability to Manage a Destructive Changes subscription
Hi Scott,
I have a couple of asks.
- I was curious on the feasibility of adding a feature for synchronizing a destructive changes file with a metadata set - or similar functionality to the add to metadata subscription, “add to a destructive subscription”. I like using this feature for keeping my package.xml in sync and would be useful for keeping a destructive changes set in sync too. The IDE can delete from my currently connected org - but I would also like it maintain that reference so that it can be deleted from upstream orgs if deployed. Typically I deal with a bit of renames on classes / objects / fields to keep consistent, but sometimes these metadata sets have already been deployed to several orgs upstream.
- If a file is deleted from source - and the wizard doesn’t end up removing it from the metadata package. I find I have to clear out the package.xml in the manifest and then re-add everything to the metadata subscription. Is there any easier way to keep the package.xml in sync with what’s in the source repository? such as a check for remove items not in src / force-app but in the package.xml manifest / subscription?
Comments (11)
-
repo owner -
reporter Scott,
I’m glad
#1is on the radar - I’ll just patiently wait for this.To provide clarity on the
#2- my settings are set to the same as the screenshot you posted except I sort the package. It typically prompts for add’s ok, or I can force it to prompt for any missing entries. Here is the workflow I just tested. I did it both with a Custom Field on a Custom Setting and also an Apex Class.- Create a new Custom Field via copy and paste. Add to Git, Add to metadata subscription - then deploy (ensured that the object was not in CustomObject section and only CustomField section of package.xml). Similarly I did the same process with an Apex class.
-
Delete the custom field from IC - Yes to the wizard to delete from the Org and No to the wizard to update the metadata subscription (Yes is the right answer here - but sometimes this gets missed).
- The items stay in the package.xml because I did say no.
-
If I reload the project - or even re-add all of the metadata content - the deleted item stays in the package.xml.
- The only workaround I could find in this case was to delete the package.xml to have empty contents and then re-add the entire metadata set back into source control.
Environment Details:
IntelliJ CE, Up to Date IC. OS: macOS - Big Sur. Project - SFDX with Manifest.
-
repo owner Ben, thanks for the steps. I'm not sure I follow the issue, but I'm sure I'm misunderstanding something. What I'm reading, though, is that in step 2 after the field was deleted, you were prompted to remove the deleted field from your
package.xml
and you declined the prompt, correct? Then in step 3 it sounds like you're concerned that no further action was taken w.r.t. thepackage.xml
to square it up with the removed field? If that's a correct read, that's by design. You're given the option by IC to update thepackage.xml
once at the time that the change is detected. If you decline, IC won't prompt you again assuming you had a good reason for declining it.Perhaps the issue is that there's no "sync metadata subscription" action along the lines of the "add to metadata subscription" action. As a result, if you decline one of those prompts for removal, after that it's a manual operation. As you pointed out, the only way to simulate a sync is to clear your package.xml and use "add to metadata subscription" on the entire project. Is that the concern?
-
reporter That’s exactly it. I want a sync button. If I remove it by any other means - file system, text editor or merge a branch where someone else removed a file from source but did it from VS code and didn’t update package.xml - it can get out of sync. The branch merge is the more common case.
-
repo owner Gotcha. Do you mind opening a distinct enhancement request for that just so I can prioritize/work on the two separately?
-
reporter Created #1797 to capture this request. Thanks again.
-
repo owner Issue
#2057was marked as a duplicate of this issue. -
repo owner Issue
#2257was marked as a duplicate of this issue. -
Just logging (after a preference is toggled?) would be a huge help at least for those who track changes in VCS.
Maybe the toggle can modify the question after a metadata piece file is deleted from “Delete in connection?” to “Add to destructive changes log?”
-
I’m curious to know as well. Is a button that works similarly to “Add to Metadata Subscription” but for destructiveChanges.xml instead in the plans?
-
repo owner - removed version
- changed component to Module Configuration
- Log in to comment
Ben, this has been on my list for a while. I looked for a corresponding existing issue in the issue tracker and didn't find one, though I could have sworn one existed. I'll keep looking but for now will use this as the tracking issue. What I'd like to do is allow the user to optionally choose
destructiveChanges.xml
,destructiveChangesPre.xml
, and/ordestructiveChangesPost.xml
whenever using apackage.xml
-based subscription, then those would be included in deployment requests. The trick is with selective deployments and deciding when those should also be included in the deployment manifest as most of the time they wouldn't be applicable. That can be figured out, though.As for the second issue you're reporting, if I'm reading it correctly you're saying that when you remove a file from the source tree, IC isn't properly removing it from your
package.xml
? That should be happening, for sure. Look at the Metadata Subscription options documented here:https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/wiki/User_Guide/Configuring_Application_Settings#markdown-header-validation-and-deployment
If that's not working properly for you, let's investigate and understand why. IC should take care of subscription adds/removes when the associated files are added/removed.
Of course, related to that in the context of destructive changes, when that's implemented IC would ideally help to migrate an entry that was removed from
package.xml
intodestructiveChanges*.xml
(likely prompting if there are both pre- and post- files), though again the devil is very much in the details since it should only do that for things that have previously been committed and not those that are part of a transient working set. Again, plenty to consider...