-
Notifications
You must be signed in to change notification settings - Fork 405
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
API version in manifest or sfdx-project.json has no impact on retrieve and org explorer #3151
Comments
Hi @fishygeek91 - Thanks for reaching out. We are working on a fix for this. You are correct on the workaround to uncheck that setting for now. With the setting unchecked, these commands use the CLI directly for these commands vs. the new library for deploy/retrieve. You will see better performance with the library, so I suggest turning this setting back on once we have this fixed. We'll update the issue once we merge a fix. |
This issue has been linked to a new work item: W-9179305 |
@smaddox-sf could you give us a sense of the timeline for this fix? We are trying to decide if we should invest in upgrading all of our projects to use the Experimental flag or just waiting for the fix to come out. Thanks |
Hi @fishygeek91, what are the differences you are seeing in the CustomObject XML? Are they formatting differences, or are actual values in the CustomObject different? If you or @ChuckJonas could provide a screenshot or code snippet example that highlights the difference that would be great. Appreciate it! |
@brpowell
but pulling down from the org browser
|
Looks like the new deploy/retrieve logic does need to respect the SFDX project api version, whether that's resolved from a local or global config when going the source path or org browser route. If you use the manifest deploy/retrieve commands, it respects the version defined in the manifest currently. @ChuckJonas this should be a relatively easy fix, might be able to get this in for next week's release or the week after. |
Closing. This issue should now be resolved as of release v51.12.0. Thank you for reporting this problem! |
Summary
When retrieving object metadata via the Org Explorer or right clicking on a file, the returned results differ from using force:source:retrieve -x “path/to/package.xml”. This is causing issues for developers who are diffing meta files from production with source control, and is dependent on the way the source is retrieved.
Steps To Reproduce:
Expected result
force:source:retrieve -x “path/to/package.xml” returns same metadata as Org Explorer or right clicking on file to retrieve source
Actual result
force:source:retrieve -x “path/to/package.xml” returns different metadata as Org Explorer or right clicking on file to retrieve source
Additional information
https:/forcedotcom/cli/issues/528
Feel free to attach a screenshot.
VS Code Version:
SFDX CLI Version:
OS and version:
The text was updated successfully, but these errors were encountered: