Skip to content
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

Retrieving and deploying Nested Lightning Email Templates and Folders fails #2902

Open
amtrack opened this issue Jun 4, 2024 · 6 comments
Open
Labels
investigating We're actively investigating this issue known issue there's an official Salesforce Known Issue for this owned by another team The Salesforce CLI team does not own this work but will pass on the information to the correct team. validated Version information for this issue has been validated

Comments

@amtrack
Copy link

amtrack commented Jun 4, 2024

Summary

There are multiple issues with retrieving and deploying Nested Email Templates and Folders using the sf CLI:

  1. retrieving metadata using source tracking (sf project retrieve start) does not retrieve nested EmailTemplateFolder components:

    • sf project retrieve start
    • level1 is retrieved
    • level2 and level3 is not retrieved
  2. deploying a nested EmailTemplate by Metadata API name fails:

    • sf project retrieve start --metadata EmailTemplate:level3/template_level3_1715081809012
    • sf project deploy start --metadata EmailTemplate:level3/template_level3_1715081809012

      Error (1): No source-backed components present in the package.

Note

This requires Email > Lightning Email Templates > Folders and Enhanced Sharing to be switched on.

Screenshot 2024-06-04 at 14 27 16

Given the following directory structure with 3 nested folders (level1/level2/level3) and one template in each level.

$ tree fixtures
fixtures
└── email
    ├── level1
    │   ├── level2
    │   │   ├── level3
    │   │   │   ├── template_level3_1715081809012.email
    │   │   │   └── template_level3_1715081809012.email-meta.xml
    │   │   ├── level3.emailFolder-meta.xml
    │   │   ├── template_level2_1714984832364.email
    │   │   └── template_level2_1714984832364.email-meta.xml
    │   ├── level2.emailFolder-meta.xml
    │   ├── template_level1_1714984698883.email
    │   └── template_level1_1714984698883.email-meta.xml
    └── level1.emailFolder-meta.xml

5 directories, 9 files

Apparently different names are being used in the Metadata API / SourceMember Tooling API / FileResponse:

Metadata API [1] SourceMember [2] FileResponse [3]
EmailTemplateFolder:level1 EmailTemplateFolder:level1 EmailTemplate:level1
EmailTemplateFolder:level2 EmailTemplateFolder:level1/level2 EmailTemplate:level1/level2
EmailTemplateFolder:level3 EmailTemplateFolder:level1/level2/level3 EmailTemplate:level1/level2/level3
EmailTemplate:level1/template_level1_1714984698883 EmailTemplate:level1/template_level1_1714984698883 EmailTemplate:level1/template_level1_1714984698883
EmailTemplate:level2/template_level2_1714984832364 EmailTemplate:level2/template_level2_1714984832364 EmailTemplate:level1/level2/template_level2_1714984832364
EmailTemplate:level3/template_level3_1715081809012 EmailTemplate:level3/template_level3_1715081809012 EmailTemplate:level1/level2/level3/template_level3_1715081809012

[1]: listing folders using sf org list metadata -m EmailTemplateFolder and listing templates in a folder e.g. sf org list metadata -m EmailTemplate --folder level3
[2]: query SourceMember records using sf data query --use-tooling-api --query "SELECT MemberType, MemberName FROM SourceMember"
[3]: retrieve metadata with --json flag sf project retrieve start --json --metadata xxx # see .result.fileProperties

Steps To Reproduce

Tip

Or checkout the repositories for reproduction linked at the bottom

  • Create a Scratch Org
  • Switch on Email > Lightning Email Templates > Folders and Enhanced Sharing
  • Create 3 levels of Email Folders with one Email Template per level
  • Try retrieving using sf project retrieve start -> does not retrieve folders in level 2 and 3
  • ✅ Retrieve a nested EmailTemplate in level3 by Metadata API name (e.g. --metadata EmailTemplate:level3/template_level3_1715081809012)
  • ❌ Try deploying the retrieved component with the same Metadata API name

Screenshot 2024-06-04 at 14 26 32

Expected result

  • retrieving and deploying should work
  • The same API names should be used throughout the Metadata API, SourceMember and FileResponse

Actual result

  • fails to retrieve nested Email Template Folders
  • uses different names in the Metadata API, SourceMember and FileResponse

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.42.6",
  "nodeVersion": "node-v20.10.0",
  "osVersion": "Darwin 23.5.0",
  "rootPath": "/Users/john.doe/.local/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.18 (core)",
    "@oclif/plugin-commands 3.3.4 (core)",
    "@oclif/plugin-help 6.0.22 (core)",
    "@oclif/plugin-not-found 3.1.9 (core)",
    "@oclif/plugin-plugins 5.0.21 (core)",
    "@oclif/plugin-search 1.0.24 (core)",
    "@oclif/plugin-update 4.2.12 (core)",
    "@oclif/plugin-version 2.1.2 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.19 (core)",
    "@oclif/plugin-which 3.1.10 (core)",
    "@salesforce/cli 2.42.6 (core)",
    "apex 3.1.11 (core)",
    "auth 3.6.11 (core)",
    "data 3.3.5 (core)",
    "deploy-retrieve 3.6.14 (core)",
    "info 3.2.8 (core)",
    "limits 3.3.7 (core)",
    "marketplace 1.2.5 (core)",
    "org 4.1.10 (core)",
    "packaging 2.4.4 (core)",
    "schema 3.3.6 (core)",
    "settings 2.2.6 (core)",
    "sobject 1.4.2 (core)",
    "source 3.3.12 (core)",
    "telemetry 3.3.7 (core)",
    "templates 56.2.7 (core)",
    "trust 3.6.11 (core)",
    "user 3.5.8 (core)"
  ]
}

Additional information

Repositories for reproduction:

@amtrack amtrack added the investigating We're actively investigating this issue label Jun 4, 2024
Copy link

github-actions bot commented Jun 4, 2024

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

@github-actions github-actions bot added the validated Version information for this issue has been validated label Jun 4, 2024
@amtrack amtrack changed the title Retrieving and deploying **Nested** Lightning Email Templates and Folders fails Retrieving and deploying Nested Lightning Email Templates and Folders fails Jun 4, 2024
@shetzel
Copy link
Contributor

shetzel commented Jun 4, 2024

@amtrack - As always, excellent issue report! 🏆 This is a known server side bug. If you're willing, you can contact support and have them add your case to the existing internal work item: W-15633963. That will help prioritize a fix.

If this helps, I think you can deploy using the full path of the email template. E.g.:
sf project deploy start --metadata EmailTemplate:level1/level2/level3/template_level3_1715081809012

@shetzel shetzel added the owned by another team The Salesforce CLI team does not own this work but will pass on the information to the correct team. label Jun 4, 2024
Copy link

github-actions bot commented Jun 4, 2024

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

@amtrack
Copy link
Author

amtrack commented Jun 5, 2024

@shetzel Thanks for your fast response!
✅ I've now contacted support about this.

Do you know who can create and link Known Issues to the Metadata Coverage Report?
It would be great if other people could see that there are some issues with EmailTemplate and EmailTemplateFolder:

Screenshot 2024-06-05 at 08 20 35

@shetzel
Copy link
Contributor

shetzel commented Jun 5, 2024

@amtrack - a known issue is in the works. Typically, Customer Support handles this in tandem with the owning developer team.

@amtrack
Copy link
Author

amtrack commented Jun 10, 2024

@mshanemc mshanemc added the known issue there's an official Salesforce Known Issue for this label Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
investigating We're actively investigating this issue known issue there's an official Salesforce Known Issue for this owned by another team The Salesforce CLI team does not own this work but will pass on the information to the correct team. validated Version information for this issue has been validated
Projects
None yet
Development

No branches or pull requests

3 participants