"sf project generate manifest --from-org pbo" generates a manifest including unexpected installed package metadata

[RupertBarrow]

Note
Before you submit your issue, make sure that:

• You're using the latest version of Salesforce CLI.
• You've searched both open and closed issues for related posts.
• You've used the doctor command to diagnose common issues.

% sf doctor
=== Running all diagnostics

pass - salesforcedx plugin not installed
pass - no linked plugins
pass - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches apiVersion
pass - [@salesforce/plugin-deploy-retrieve] default target DevHub max apiVersion matches default target org max apiVersion
pass - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches default target org max apiVersion
pass - using latest or latest-rc CLI version

• You understand that GitHub Issues don't adhere to any agreement or SLA.
  • If you require immediate assistance, use official channels such as Salesforce Customer Support.

Summary

sf project generate manifest --from-org generates a manifest which mentions packaged metadata, when the default is that it should not (see the "-c" option).

Steps To Reproduce

• log in to any production org which include an installed package. In my case, I am using a new PBO (partner business org), but I also got the error in a recent P10 Non Profit org with NPSP packages
• run the command sf project generate manifest --from-org pbo -d .
• open ./package.xmland search for "CustomObjectTranslation" where, among others, you will find package metadata (eg "CHANNEL_ORDERS__" or "sfcma__")

Expected result

The generated manifest file should not mention any packaged metadata

Actual result

The generated manifest file contains metadata of installed packages such as :

    <types>
        <members>CHANNEL_ORDERS__COA_BatchConfiguration__c-en_US</members>
        <members>CHANNEL_ORDERS__Customer_Order_Product_History__c-en_US</members>
        <members>CHANNEL_ORDERS__Customer__c-en_US</members>
        <members>CHANNEL_ORDERS__Partner_Contract_Terms__c-en_US</members>
        <members>CHANNEL_ORDERS__Partner_Pricebook_Entry__c-en_US</members>
        <members>CHANNEL_ORDERS__Partner_Product_Catalog__c-en_US</members>
        <members>CHANNEL_ORDERS__Service_Order_Detail__c-en_US</members>
        <members>CHANNEL_ORDERS__Service_Order_Log__c-en_US</members>
        <members>CHANNEL_ORDERS__Service_Order__c-en_US</members>
        <members>CHANNEL_ORDERS__System_Property__mdt-en_US</members>
        <members>CodeBuilder__Alert__e-ar</members>
        <members>CodeBuilder__Alert__e-bg</members>
        <members>CodeBuilder__Alert__e-cs</members>
        <members>CodeBuilder__Alert__e-da</members>
        <members>CodeBuilder__Alert__e-de</members>
        <members>CodeBuilder__Alert__e-el</members>

System Information

Shell : zsh

sf version --verbose --json :

{
  "architecture": "darwin-x64",
  "cliVersion": "@salesforce/cli/2.30.8",
  "nodeVersion": "node-v18.17.0",
  "osVersion": "Darwin 21.6.0",
  "rootPath": "/Users/rupert/.nvm/versions/node/v18.17.0/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@mkreth/sfdx-metadata-coverage 0.4.0 (user)",
    "@mshanemc/plugin-streaming 1.1.7 (user)",
    "@mshanemc/sfdx-sosl 1.1.0 (user)",
    "@oclif/plugin-autocomplete 3.0.9 (core)",
    "@oclif/plugin-commands 3.1.4 (core)",
    "@oclif/plugin-help 6.0.13 (core)",
    "@oclif/plugin-not-found 3.0.11 (core)",
    "@oclif/plugin-plugins 4.2.5 (core)",
    "@oclif/plugin-search 1.0.16 (core)",
    "@oclif/plugin-update 4.1.13 (core)",
    "@oclif/plugin-version 2.0.12 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.12 (core)",
    "@oclif/plugin-which 3.1.0 (core)",
    "@rupertbarrow/rapido-sf-plugin 1.11.6 (user)",
    "@salesforce/cli 2.30.8 (core)",
    "apex 3.0.25 (core)",
    "auth 3.3.13 (core)",
    "data 3.1.1 (core)",
    "deploy-retrieve 3.2.16 (core)",
    "dev 2.0.4 (user)",
    "info 3.0.27 (core)",
    "limits 3.1.10 (core)",
    "marketplace 1.0.25 (core)",
    "org 3.3.14 (core)",
    "packaging 2.1.10 (core)",
    "schema 3.1.3 (core)",
    "settings 2.0.27 (core)",
    "sobject 1.1.13 (core)",
    "source 3.1.15 (core)",
    "telemetry 3.1.13 (core)",
    "templates 56.0.16 (core)",
    "trust 3.3.10 (core)",
    "user 3.2.11 (core)",
    "@salesforce/sfdx-scanner 3.19.0 (user)",
    "shane-sfdx-plugins 4.43.0 (user)",
    "texei-sfdx-plugin 2.2.1 (user)"
  ]
}

Additional information

[github-actions]

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.

[git2gus]

This issue has been linked to a new work item: W-15247671

[shetzel]

I reproduced it. Thanks for the excellent repro steps!

[shetzel]

I think this depends on the type of installed package. For managed and unlocked packages it behaves as expected, and you need to use the -c managed | unlocked to get that metadata. I think it might be unmanaged packages where the metadata is included by default. @RupertBarrow - does this align with what you're seeing?

[RupertBarrow]

@shetzel No, I run the command without the -c option so : "by default, metadata in packages [should be] ignored", but they are still retrieved (as shown in my example).

In my example, you can see the CHANNEL_ORDERS and CodeBuilder packages which are both Salesforce-provided packages, but I'm pretty sure the same behaviour happens with other packages : their metadata is always retrieved, although I am not passing the -c option.

[shetzel]

Ok, I see what's happening. In short, it's a bug and maybe there's something the CLI can do to improve the accuracy, but the bug is with the server responses the CLI uses to distinguish between packaged metadata and non-packaged metadata. I'm going to create a few internal bugs for some server side teams to fix. I'll post bug numbers to this GH issue. When they are there, if you could contact support and point them to those internal bugs it will help prioritize the bug fixes with those teams.

More info:
The sf project generate manifest --from-org pbo command uses all the metadata types supported by the source-deploy-retrieve library and makes listMetadata calls to the org. The CLI gets the responses for those calls and excludes metadata that match a known pattern for managed and unlocked packages. There is no reliable pattern for metadata in unmanaged packages so that metadata will always be included. Additionally, if the listMetadata response for a specific metadata type is incorrect it will not be excluded. This is what's happening in your usecase.

From the snippet of the generated manifest you provided above, those entries are for the CustomObjectTranslation metadata type. For managed packages like CodeBuilder and CHANNEL_ORDERS, the response for a listMetadata API call should have properties of manageableState: "installed" and (e.g.) namespacePrefix: "CodeBuilder". But for CustomObjectTranslation metadata types (and a few others) it's not included or it's wrong. As an example, here is a listMetadata response for one of the CustomObjectTranslation metadata:

{
    "createdById": "005Rm00000AnsEWIAZ",
    "createdByName": "shetzel",
    "createdDate": "1970-01-01T00:00:00.000Z",
    "fileName": "objectTranslations/CodeBuilder__Alert__e-ar.objectTranslation",
    "fullName": "CodeBuilder__Alert__e-ar",
    "id": "",
    "lastModifiedById": "005Rm00000AnsEWIAZ",
    "lastModifiedByName": "shetzel",
    "lastModifiedDate": "1970-01-01T00:00:00.000Z",
    "namespacePrefix": "",
    "type": "CustomObjectTranslation"
  }

There is no namespacePrefix or manageableState, which is why the CLI didn't exclude it from the manifest. You can see this yourself if you run this command: sf org list metadata -o pbo -m CustomObjectTranslation and inspect the entries. Compare that with the responses from this command: sf org list metadata -o pbo -m CustomObject and you will see that the CustomObject metadata type handles this correctly. That's why you won't see CustomObject metadata from managed packages in the generated manifest.

However, there might be a workaround for this that we can add. I think we should be able to first ask the org for installed packages, then use those entries as filters applied to metadata fullNames.

[shetzel]

@RupertBarrow - Here are the internally tracked bugs: W-15665146 for CustomObjectTranslations and W-15665627 for TopicsForObjects. If you see other types in your generated manifest please note them in this issue. Also, it helps get these fixes prioritized by the server teams if you contact support and ask them to attach cases to those issues.

[RupertBarrow]

@shetzel In my case, I see this occurring on CustomObjectTranslation, CustomTab, Flow, Layout (of Custom Metadata), ListView, TopicsForObjects.

I have opened Case #467310377

[shetzel]

@RupertBarrow Not including CustomObjectTranslation and TopicsForObjects entries, are these the packaged metadata entries you're seeing?

CustomTab: `sfcma__PaymentIntent__c` & `CHANNEL_ORDERS__Customer__c`
Flow: `MHolt__Org_Expiration_Notification`
Layout: `CodeBuilder__CodeBuilderSetting__mdt-CodeBuilderSetting Layout`
ListView: `CHANNEL_ORDERS__Customer__c.All1` & `sfcma__PaymentIntent__c.All`

If so, these are different in that the ListMetadata response entries are not wrong for all metadata. I'm not sure why certain entries are correct and others aren't. That mystery requires more investigation.

Thanks for opening the case. I know that the owning team for CustomObjectTranslation has already started investigating the bug so it definitely helped.

[shetzel]

@RupertBarrow - are you reporting this because it's causing a problem in one of your workflows or because the behavior doesn't match the documentation?

[RupertBarrow]

It's not (yet) a problem in my workflow.
But I am counting on the feature to exclude package members of an SFDX project generated from production.

[jayree]

@RupertBarrow as this behaviour is related to the metadata api.
I have created a workaround for this use case some time ago:

The command sf jayree manifest cleanup --manifest package.xml --file cleanup.xml removes entries from the manifest file.

In the cleanup.xml file you can define rules in various ways like:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <name>CustomObjectTranslation</name>
    <members>CodeBuilder__*</members>
  </types>
  <version>60.0</version>
</Package>

[jasmine-anzx]

@shetzel Hi Steve, I don't know if this bug causes the issue I'm having so please let me know if I need to raise a separate bugs. My question is: Is there a reason why when I ran: sf project generate manifest -t package -d output -p force-app/main/default/objects/Access_Request__c

I got all the fields when the only thing changed is the object label in Access_Request__c.object-meta.xml . The manifest should include ONLY the object right? This is causing the artifact to be bigger and takes more time to validate, because I only change 1 file (the object) but now the deployment will validate the object + its 17 fields. Is this how it's supposed to work? Thank you

[shetzel]

@jasmine-anzx - that's the expected behavior. since that metadata type has children (e.g., CustomFields) it will include parent and children when creating the manifest.