Unable to Retrieve Name spaced metadata in OrgBrowser

[Amit-Tripathi]

Summary

Org Browser is not fetching name spaced metadata like Custom Objects, Flows, Page Layout, Custom metadata, Flexipages, Custom Settings and labels.
Org Browser is wonderful if we are working with unpackaged metadata but makes it difficult to support metadata from namespaces that are editable like objects, flows etc.
There was a fix pushed for issue- #1998, but it doesn't seem to be working hence raising another one.

Steps To Reproduce:

1. Install any Managed Package with Custom Object, Flows, Flexipage, Page Layout, and Custom metadata in an org
2. Connect it to VScode and run org browser
3. The Name spaced component does not show up as listed hence there is no ability to fetch them

Expected result

All the components from the org with namespace should be listed in the org browser

Actual result

Only Unmanaged metadata with no namespace is listed in the org browser

Additional information

Feel free to attach a screenshot.

Salesforce Extension Version in VS Code: 61.1.2

Salesforce CLI Version: @salesforce/cli/2.45.6

OS and version: Windows_NT x64 10.0.22631

VS Code version: 1.90.2

Most recent version of the extensions where this was working: Not sure

[svc-idee-bot]

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.

[svc-idee-bot]

Hello @Amit-Tripathi 👋 It looks like you didn't provide all the required basic info in your issue.

If you haven't already, please provide the following info:
Salesforce Extension Version in VS Code:
Salesforce CLI Version:
OS and version:
VS Code version:
Most recent version of the extensions where this was working:

Here's an example of a set of required info that will pass the validation:
Salesforce Extension Version in VS Code: 60.13.0
Salesforce CLI Version: @salesforce/cli/2.42.6 darwin-arm64 node-v18.18.2
OS and version: MacOS Sonoma 14.5
VS Code version: 1.89.1
Most recent version of the extensions where this was working: 60.11.0

A few more things to check:

• Make sure you've provided detailed steps to reproduce your issue, as well as all error messages that you see.
  • A repository that clearly demonstrates the bug is ideal.
  • Error messages can be found in the Problems Tab, Output Tab, and from running Developer: Toggle Developer Tools in the command palette.
• Make sure you've installed the latest version of the Salesforce Extension Pack for VSCode. (docs)
• Search GitHub for existing related issues.

Thank you!

[svc-idee-bot]

Hello @Amit-Tripathi 👋 Have you tried updating to the latest version of the Salesforce Extension Pack?

Latest: 61.1.2

We suggest you to update to the latest version of the Salesforce Extension Pack in the VSCode Extensions view and confirm that you're still seeing your issue.

[eriksinnard]

Salesforce Extension Version in VS Code:61.1.2
Salesforce CLI Version:@salesforce/cli/2.46.6 darwin-x64 node-v20.11.1
OS and version:MacOS Sonoma 14.5
VS Code version:1.90.2
Most recent version of the extensions where this was working:N/A

This issue was reported on my behalf - the requested version details are above.

[CristiCanizales]

Hi @eriksinnard, thanks for creating the issue. I was wondering if you tried refreshing the org browser (Open Command Palette > Run command SFDX: Refresh Types). There's a current issue with duplicated namespaces in Org Browser, but at least they show up. I'm curious on why you don't even see the metadata. For example I see it like this

[eriksinnard]

@CristiCanizales I performed a refresh using the refresh button in the org browser and using the SFDX: Refresh Types command at the command palette and I still do not see any namespaced components in the org browser.

I tried this against all of the org types I have access to; scratch orgs, sandboxes, and trialforce production orgs and I see the same behavior.

To eliminate any issues with local configuration, I set up a new SFDX project in a Salesforce CodeBuilder instance and connected to a default org with several managed packages installed. In all of these cases, I still do not see any managed components in the org browser.

Please let me know if I can provide any additional detail.

Thanks!

[daphne-sfdc]

Hi @Amit-Tripathi @eriksinnard, I spoke with my team and CLI Team, and we believe the org browser is working as expected. The reason the components in managed packages are not visible in org browser is that they shouldn't be retrieved - they're able to be used but users aren't supposed to see their code and thus we would have to figure out how to implement this limited visibility to make the components read-only.

That being said, your issue is a very common feature request, and we do agree that we haven't added adequate support for package-based development across a number of our features. Given the recent uptick of this issue across IDEx and CLI Teams, we'll be revisiting this in our next planning session.

Thank you for your patience, and we'll keep you in the loop with any updates.

[eriksinnard]

@daphne-sfdc that is an excellent point when it comes to managed components containing code. I used Apex Classes in my testing to correspond with @CristiCanizales example, but in the real world I wouldn't expect the org browser or the CLI to return the code of an apex class/VF page/Aura Component/LWC. So where those components are concerned I totally agree with your analysis.

Where components are managed but can still be modified or extended by subscribers is truly the use-case we're hoping to address. As an example, all our subscribers add custom fields to our managed objects, but because the managed objects do not show in the org browser, interacting with these components becomes more difficult.

I was expecting that this recent PR would update the functionality to expose managed components such as custom objects, flexipages, layouts, etc in the org browser, which would be extremely useful for a lot of our internal teams and our subscribers. With the additional context of this discussion I wonder if this PR was focused on exposing namespaced components from unlocked packages but still excluding namespaced components from managed packages? I'm inclined to think that may be why @CristiCanizales and I were seeing different behavior.

[daphne-sfdc]

@eriksinnard

With the additional context of this discussion I wonder if this PR was focused on exposing namespaced components from unlocked packages but still excluding namespaced components from managed packages? I'm inclined to think that may be why @CristiCanizales and I were seeing different behavior.

Yes, the example that @CristiCanizales provided above is with an unlocked package - from investigating this issue we realized that namespaced components from managed and unlocked packages are treated differently, and rightfully so.

Where components are managed but can still be modified or extended by subscribers is truly the use-case we're hoping to address. As an example, all our subscribers add custom fields to our managed objects, but because the managed objects do not show in the org browser, interacting with these components becomes more difficult.

We did not consider this use case, but now that you mention it, it makes sense why you would want managed components to be visible in the org browser and why this is such a popular feature request. Our team will be talking about how we want to implement this during our planning.

[eriksinnard]

@daphne-sfdc That sounds great, thank you for the update! Don't hesitate to reach out if we can provide any additional context or feedback.

[git2gus]

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

[svc-idee-bot]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming session. We prioritize feature requests with more upvotes and comments.

[aldoforce]

While it's unbelievable that since the launch of OrgBrowser this feature is not yet available, there are two good news:

1. a work item is loaded in Gus, which i'm sure it's already assigned to someone and a fix will be available soon.
2. the CLI provides a mechanism to do this with ease:

|  Retrieve a custom object called ExcitingObject that's in the SBQQ namespace:           
│  $ sf project retrieve start --metadata CustomObject:SBQQ__ExcitingObject 
│                                     
│  Retrieve all custom objects in the SBQQ namespace by using a wildcard and quotes:                           
│  $ sf project retrieve start --metadata 'CustomObject:SBQQ__*'                 

[eriksinnard]

While it's unbelievable that since the launch of OrgBrowser this feature is not yet available, there are two good news:

1. a work item is loaded in Gus, which i'm sure it's already assigned to someone and a fix will be available soon.
2. the CLI provides a mechanism to do this with ease:

|  Retrieve a custom object called ExcitingObject that's in the SBQQ namespace:           
│  $ sf project retrieve start --metadata CustomObject:SBQQ__ExcitingObject 
│                                     
│  Retrieve all custom objects in the SBQQ namespace by using a wildcard and quotes:                           
│  $ sf project retrieve start --metadata 'CustomObject:SBQQ__*'                 

It's definitely doable with the CLI and that's a great option for folks comfortable working at the command line. The audience I'm trying working to enable is more on the app builder end of the spectrum. If I can give them the tools to get their work done without having to add working in at the command line to their skillset it opens up the platform to a larger pool across our team, our partners, and our customers.