Closed Amit-Tripathi closed 1 month 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.
The CLI writes the file paths from the Metadata API response and that's how they are sent when the --package-name
flag is set. That affects the RetrieveRequest
made to the metadata API and it's not clear from the docs (here) what the expected behavior is. I'll ask that team if this is a bug or working as designed.
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.
After some investigation, the retrieve command behavior with the --package-name
flag is working as designed. However, as a result of this issue and the support case there will be multiple doc updates to clarify expectations. Thank you for bringing this to our attention.
History: the packageNames
attribute on the RetrieveRequest
was originally added to support the now deprecated Eclipse IDE and was meant more as a reference than metadata to be source controlled for deploys and retrieves.
The directory contains a lot of Metadata that will not redeploy to the org, for instance the Apex classes are just stubs and the user has no permission to modify the Apex classes in a Managed Package.
Metadata is represented differently based on its container. In this context it is assumed that it exists in the Package container, the Metadata is not fully qualified with the Package's Namespace. This is similar to how an Apex class in Namespace Foo can access other classes in the same Namespace without full qualification.
Summary
Retrieving Managed Package from the org brings metadata without Namespaces
Steps To Reproduce
Expected result
The managed Package metadata should have been retrieved with the namespace.
Actual result
The managed Package metadata doesn't have the namespace. So if I make any changes like adding a field to the managed custom object in the project and deploying it will not update that object but rather creates a new object or update some existing object. Refer to the screenshot below, same object when retrieved via manifest has namespace orgbrowser__hello but when retrieved via command sf project retrieve start --package-name it creates a OrgBrowser folder and has the object listed as just hello without namespace.
System Information
Additional information