forcedotcom / cli

Salesforce CLI
https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/
BSD 3-Clause "New" or "Revised" License
474 stars 77 forks source link

Standard Lookup field references are not retrieved on custom profile using sf project retrieve start --manifest #2908

Closed LeeCunningham closed 3 weeks ago

LeeCunningham commented 4 weeks ago

Summary

Using the command sf project retrieve start --manifest results in standard lookup fields not being retrieved in the profile definition. Other standard fields are retrieved, but those where data type = 'lookup' are not retrieved along with the profile.

If the entire customobject is retrieved then the lookup fields appear in the profile definition, but retrieving with only the fields specified results in the FLS for the field not being retrieved in the profile.

For example, the following manifest will result in the FLS for the field not being retrieved;

<?xml version="1.0" encoding="UTF-8"?>

Test STND Retrieve Profile Contact.AccountId CustomField 60.0

However if the manifest is changed to reference the custom object, then the FLS is returned in the profile definition.

<?xml version="1.0" encoding="UTF-8"?>

Test STND Retrieve Profile Contact CustomObject 60.0

Steps To Reproduce

Is reproducible in any project

  1. Modify FLS for Contact.AccountId on a custom profile
  2. Create manifest in local project which contains the profile and Contact.AccountId field
  3. Run command sf project retrieve start --manifest from the local project
  4. The profile returned does not have any reference to the field Contact.AccountId

Expected result

FLS for the Contact.AccountId field is returned in the profile definition

Actual result

FLS is missing for the field

System Information

Which shell or terminal are you using? zsh

Paste the full output of the sf version --verbose --json command below -->

{ "architecture": "darwin-arm64", "cliVersion": "@salesforce/cli/2.42.6", "nodeVersion": "node-v20.12.2", "osVersion": "Darwin 23.4.0", "rootPath": "/Users/leecunningham/.local/share/sf/client/2.42.6-2b3c407", "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)"

github-actions[bot] commented 4 weeks ago

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[bot] commented 4 weeks ago

Hello @LeeCunningham :wave: None of the versions of sf you shared match the latest release.

Shared: 2.42.6 Latest: 2.44.8

Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue. You can also try the rc and nightly releases! (docs)

After updating, share the full output of sf version --verbose --json

LeeCunningham commented 4 weeks ago

Confirmed that it is still happening after updating version

{ "architecture": "darwin-arm64", "cliVersion": "@salesforce/cli/2.44.8", "nodeVersion": "node-v20.13.1", "osVersion": "Darwin 23.4.0", "rootPath": "/Users/leecunningham/.local/share/sf/client/2.44.8-c60512e", "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.10 (core)", "@oclif/plugin-plugins 5.1.3 (core)", "@oclif/plugin-search 1.0.24 (core)", "@oclif/plugin-update 4.2.14 (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.44.8 (core)", "apex 3.1.13 (core)", "auth 3.6.17 (core)", "data 3.4.3 (core)", "deploy-retrieve 3.8.3 (core)", "info 3.3.3 (core)", "limits 3.3.9 (core)", "marketplace 1.2.8 (core)", "org 4.1.14 (core)", "packaging 2.4.5 (core)", "schema 3.3.9 (core)", "settings 2.2.7 (core)", "sobject 1.4.6 (core)", "source 3.3.18 (core)", "telemetry 3.3.11 (core)", "templates 56.2.9 (core)", "trust 3.7.3 (core)", "user 3.5.11 (core)" ] }

cristiand391 commented 3 weeks ago

this is an issue with how the API works, see https://github.com/forcedotcom/cli/issues/1396#issuecomment-1033792989

LeeCunningham commented 3 weeks ago

Hi - thank you for the confirmation but I do not see where this is documented. As per the MDAPI documentation referenced in the linked article

"Metadata API intentionally makes it difficult to include standard fields in retrieve() calls to prevent unexpected profile changes. However, you can still retrieve and deploy profile permissions for custom and standard fields in standard objects, such as Account."

However it does not state that in order to retrieve standard lookup fields FLS the entire object definition must be retrieved. Including as a type will result in the FLS not being retrieved onto the profile. Is this documented somewhere?

carlosabella commented 3 weeks ago

Hi @cristiand391 , I think the issue here is different. The one you point out: https://github.com/forcedotcom/cli/issues/1396#issuecomment-1033792989 is related to source-tracking and the usage of pull.

This issue is different. Here we are retrieving not pulling. We are using the following command: sf project retrieve start --manifest package.xml

And inside package.xml we have the profile and the field. We are not using source tracking here, so ... how is this same issue? Thanks for the help here.

cristiand391 commented 3 weeks ago

And inside package.xml we have the profile and the field. We are not using source tracking here, so ... how is this same issue? Thanks for the help here.

It's been a while since I played with profiles but from what I remember (and MDAPI docs/Shane's comment), your package.xml should have the object and field for it to work.

@LeeCunningham mentions it above:

If the entire customobject is retrieved then the lookup fields appear in the profile definition, but retrieving with only the fields specified results in the FLS for the field not being retrieved in the profile.

See also: https://github.com/forcedotcom/cli/discussions/1785