[DestructiveChanges] Do not try to delete Standard Object Translation

[arafesthain]

Fail to deploy destructiveChanges when it contains standard object translation :

{
   "changed": "false",
   "componentType": "CustomObjectTranslation",
   "created": "false",
   "createdDate": "2020-07-03T14:33:59.000Z",
   "deleted": "false",
   "fileName": "destructiveChanges/objectTranslations/Activity-fr.objectTranslation",
   "fullName": "Activity-fr",
   "problem": "The CustomObjectTranslation called '\''Activity-fr'\'' is standard and cannot be deleted",
   "problemType": "Error",
   "success": "false"
 }

Describe the solution you'd like

SGD do not add those meta to destructiveChanges.xml. Only add inFile deletion.

(Parse the name and if it does not contains "__c" don't add it)

Describe alternatives you've considered

Re-add an "empty" translation file.

[scolladon]

I think we should debate if this should be handled by the command line.

My point of view is that the command line should not manage those kind of implicit behavior of the metada except if it explicitly documented (best scenario would be this information is fetchable via API). It could be subject to change / removal / addition without clear and explicit notice at each Salesforce release.

This is the responsibility of the metadata repository owner to either not make commit to delete them Or post process them to add the empty file Or just create an intermediary commit with the removal and use sgd from this commit (to avoid having the deletion).

What do you think guys @alex9138 @mehdisfdc ?

[arafesthain]

@scolladon you're right it will quickly be a nightmare to add such specific code in sgd. Repo owner should handle this. I'm going to re-add it (empty or not) and put if in .forceignore if needed 👍

So to conclude, in my opinion such specific cases should be handled in forceignore (to start).

[arafesthain]

Hello @scolladon

<?xml version="1.0" encoding="UTF-8"?>
<CustomObjectTranslation xmlns="http://soap.sforce.com/2006/04/metadata">  

</CustomObjectTranslation>

I just checked and the file exists in the branch and is empty. So in this case I think SGD should'nt add it to destructive.

[scolladon]

What is the result of the command :

$ git diff --name-status --no-renames <from> <to>

[arafesthain]

$ git diff --name-status --no-renames origin/master . | grep objectTranslations | grep -i activity D force-app/main/default/objectTranslations/Activity-fr/DM_Compte_client__c.fieldTranslation-meta.xml D force-app/main/default/objectTranslations/Activity-fr/DM_ID_du_Contactc.fieldTranslation-meta.xml D force-app/main/default/objectTranslations/Activity-fr/Ev_nement_candidaturec.fieldTranslation-meta.xml

[scolladon]

git diff is saying the files are deleted, this is why sgd is adding them in the destructiveChanges.xml The file are deleted but still in the branch and empty ?

[arafesthain]

git is not saying that parent has been deleted :)

and destructive changes does :

    <types>
        <members>Activity-fr</members>
        <name>CustomObjectTranslation</name>
    </types>

[scolladon]

I don't understand precisely what is the issue here :D @alex9138 could you describe in detail what happen, why it is an issue and what you want it to do ?

[arafesthain]

What happen : sgd destructiveChange output -->

 <types>
        <members>Activity-fr</members>
        <name>CustomObjectTranslation</name>
   </types>

but this object has never been deleted (git said it) File content:

<?xml version="1.0" encoding="UTF-8"?>
<CustomObjectTranslation xmlns="http://soap.sforce.com/2006/04/metadata">  

</CustomObjectTranslation>

What has been deleted is translation fields below:

D force-app/main/default/objectTranslations/Activity-fr/DM_Compte_client__c.fieldTranslation-meta.xml
D force-app/main/default/objectTranslations/Activity-fr/DM_ID_du_Contact__c.fieldTranslation-meta.xml
D force-app/main/default/objectTranslations/Activity-fr/Ev_nement_candidature__c.fieldTranslation-meta.xml

What I want it to do: Do not try to delete objectTranslation-meta.xml if it has not been deleted :)

PS: Maybe I miss something too with this meta so don't hesitate to clarify

[scolladon]

Thank you very much @alex9138. I understand now.

You're right this is definitly an issue. I think I have a way to solve this and it involves creating another handler for this kind of use case.

I start the development asap and I will update this issue via a PR.

[scolladon]

@alex9138 could test the PR #42 and see if it resolves the issue on your side with your dataset please ?

[arafesthain]

@scolladon NOGO on my side :

1) force-app directory is generated without '-d' parameter

$ ../../sgd/bin/cli -t HEAD -f origin/master -r . -o output
{
  "error": null,
  "output": "output",
  "success": true,
  "warnings": null
}

$ ls output/force-app/main/default/
objectTranslations

$ ls output/force-app/main/default/objectTranslations/
Activity-fr  Lead-en_US  Lead-fr  Opportunity-en_US  Opportunity-fr  WorkOrder-fr

2) OK for Translation object it doesn't appear anymore in the destructive file

3) NOK Deleted translation fields are not in the destructive file (but as they are deleted into customFields it will work for this time, won't work if we are only deleting translations I guess)

$ cat output/destructiveChanges/destructiveChanges.xml
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>DWIN2_ServiceFacturation\HbWITcnSNgGPMWfXXGPTXeSxaLTvOW</members>
        <members>DWIN2_ServiceFacturation\SBFsLwQICPTezHwogEDeAaHBWjrAPG</members>
        <name>Dashboard</name>
    </types>
    <types>
        <members>DCOM_Logos_Icones\DentMaster_Logo_2018_bleu_png.document</members>
        <name>Document</name>
    </types>
    <types>
        <members>DWIN2_CommercialFolder\DWIN2_AccountOpen_VGF</members>
        <members>DWIN2_Lead_FolderFolder</members>
        <members>DWIN2_Lead_Folder\DWIN2_Lead_UnservedArea</members>
        <members>DWIN2_Lead_Folder\DWIN2_Lead_VQ_RequestAcknowledgment</members>
        <members>DWIN2_Lead_Folder\DWIN2_NeedPictures</members>
        <members>DWIN2_Lead_Folder\DWIN2_NewConvertedLead</members>
        <members>DWIN2_Lead_Folder\DWIN2_NewQuoteVehicule</members>
        <members>DWIN2_Lead_Folder\DWIN2_QuoteReminder</members>
        <members>DWIN2_Lead_Folder\DWIN2_UNANSWERABLE</members>
        <members>DWIN2_Lead_Folder\DWIN2_UNANSWERABLE_CONDITION_NOTMET</members>
        <members>DWIN2_Lead_Folder\DWIN2_UNANSWERABLE_EXCESSIVE</members>
        <members>DWIN2_Lead_Folder\DWIN2_UNANSWERABLE_NO_ANSWER</members>
        <members>DWIN2_Lead_Folder\DWIN2_VehiculeQuoteAcknowledgment</members>
        <name>EmailTemplate</name>
    </types>
    <types>
        <members>DWIN2_ADM_Tech</members>
        <name>Group</name>
    </types>
    <types>
        <members>DWIN2_Account_HailEvent__c-DWIN2_Account_HailEvent Layout</members>
        <members>DWIN2_Contact_HailEvent__c-DWIN2_Contact_HailEvent Layout</members>
        <members>DWIN2_Contract_HailEvent__c-DWIN2_Contract_HailEvent Layout</members>
        <name>Layout</name>
    </types>
    <types>
        <members>Activity.DM_Compte_client__c</members>
        <members>Activity.DM_ID_du_Contact__c</members>
        <members>Activity.Ev_nement_candidature__c</members>
        <members>Activity.TECH_isRecurringVisitToPlan__c</members>
        <members>Activity.Type_de_RV__c</members>
        <members>Campaign.Categorie_de_campagne__c</members>
        <members>Campaign.Sous_categorie__c</members>
        <name>CustomField</name>
    </types>
    <types>
        <members>Log__c.All1</members>
        <members>Opportunity.DWIN2_AllQuoteToSend</members>
        <members>Opportunity.DWIN2_AllQuoteWaitExpert</members>
        <members>Opportunity.DWIN2_AllQuoteWaitWorkOrder</members>
        <members>Opportunity.DWIN2_AllVhehiculeQuote</members>
        <members>Opportunity.DWIN2_MyVehiculeQuote</members>
        <members>Opportunity.DWIN2_VehiculeQuoteWaintAnswer</members>
        <name>ListView</name>
    </types>
    <types>
        <members>DWIN2_ADVqueue</members>
        <members>DWIN2_RH_Queue</members>
        <members>DWIN2_SCqueue</members>
        <name>Queue</name>
    </types>
    <types>
        <members>DWIN2_Sales\DWIN2_Opportunity_VehicleQuote\DWIN2_Lead_VehicleQuoteRequest_Open</members>
        <name>Report</name>
    </types>
    <types>
        <members>Case</members>
        <members>Survey</members>
        <name>Settings</name>
    </types>
    <version>48.0</version>
</Package>

[scolladon]

@alex9138 could catch for the point 1. The next commit in the PR has fixed this.

For point 3 I don't see any way to do it properly because CustomFieldTranslation is not a metadata type that is fetchable via package.xml... The way to retrieve CustomFieldTranslation is to write a package.xml to retrieve the CustomObjectTranslation for the language and the object containing the field you want the translation. And also add a member in the CustomField metadata type for the fields you want to retrieve the translation This way the metadata will retrieve the translations for the fields.

Then I don't see how to delete a specific CustomFieldTranslation using destructiveChanges deduced from delta based on commit diff... I think it is possible to delete CustomFieldTranslation by using command like :

$ sfdx force:source:delete --sourcepath ./path/to/customFieldTranslation

@mehdisfdc and @alex9138 do you see the point here ? Do you think there is a way to workaround this ? If what we see here is true then maybe it is a blind side of the source format we need to address at the product level

[arafesthain]

Don't see any workaround apart from your proposed one, force:source:delete (that effectively works well in this case)

To be send to product level I think.

source:delete -p PATH won't work if source has already been deleted from git so SGD can't do anything here :D The sourcepath "C:\Users\alexis.rafesthain\Documents\projets\DentMaster\Repo\azureRepo\force-app\main\default\objectTranslations\Account-fr\D_pt__c.fieldTranslation-meta.xml" is not a valid source file path. I think this one too should go to product level, because, to delete something it shouldn't be mandatory to have the file in our repository..

Maybe source:delete -m will be better but as you said fieldTranslation is not a metadata type..

[mehdicherf]

Hi guys! Regarding Pt3 (missing translation fields from the destructive file), I believe that the proposed behaviour in the PR is OK:

• When the associated fields are deleted, translations should be deleted as well (even if not explicitly part of the destructive change)
• If there is a need to delete just the field translation (and not the field itself), as you mentioned it's currently hard to automate. With the current behaviour of the CLI, I don't see any obvious solution to handle that situation with SGD.

So in my opinion it's ok if SGD doesn't put the translation fields in the destructive file, at least for now.

[scolladon]

sgd v3.2.0 available