Namespace accessible classes/methods are not retrieved in the offline symbol table

Issue #2582 resolved
Rreicks created an issue

I would like to reopen this issue: https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/2495/namespaceaccessible-attributes-and-methods

it still seems to still be an issue. See attached screenshots but general reproduction steps are as follows:

  • Create a package in a namespace with a class and method that is @NamespaceAccessible
  • Install package in new scratch org with the same namespace
  • Create a new apex class and try to reference the namespace accessible class/method.
  • Pull offline symbol table
  • Notice that the type does not resolve but you are able to push the code to your scratch org

Official response

  • Scott Wells repo owner

    Okay, I managed to test this a bit today and it’s unfortunately unchanged from how it was last time I checked. Basically non-global Apex symbols from installed managed packages are not reported to external clients, so IC2 has no way to include those symbols in its generated offline symbol tables.

    To provide a little more context, I uploaded a 2GP managed package version with namespace ic2gp and the following class:

    @NamespaceAccessible
    public with sharing class Issue2582 {
        @NamespaceAccessible
        public void issue2582() {}
    }
    

    I then installed that package into a scratch org that also has namespace ic2gp. When I generated the offline symbol table, ic2gp.Issue2582 was not included, and it’s because of the following:

    SELECT NamespacePrefix, Name, Body FROM ApexClass
    
    NamespacePrefix  Name       Body
    ic2gp            Issue2582  (hidden)
    

    As you can see, the org isn’t providing any useful information about the @NamespaceAccessible class/method even though that class' namespace is the same as the org’s namespace.

    I’ll raise this with Salesforce again as it seems like such types should yield the @NamespaceAccessible interface from the perspective of the subscriber org. However, until that’s addressed by Salesforce, the only way that IC2 could include those symbols is if they’re added to the project somehow in source form.

Comments (7)

  1. Scott Wells repo owner
    • changed status to open

    I'll be happy to investigate. I think the last time I looked at this, the issue was that Salesforce wasn't including those symbols in the published symbol tables of the installed namespaced packages, minimally managed packages but I also think perhaps unlocked packages with namespaces. If they're not including that info, then it's simply not available without the source for those packages.

    Do you have an installable package with such symbols or a scratch org with such a package installed that I could use? I can fabricate one myself, but if you have something already handy, that would certainly accelerate the diagnostic process. Note that I'm not looking for anything with proprietary contents, though. Just seeing if you have something that can be safely shared directly with me long enough for me to see what's available through the API. If not, I'll set everything up myself. If that's the case, can you clarify whether this is a managed package or an unlocked package with a namespace?

  2. Rreicks reporter

    Awesome! If there is anything I can look at on your behalf I can look at that as well. I unfortunately do not have any non-proprietary packages handy. I only work with managed packages currently. I can take a look at creating something I can share, I don’t know how sharing a namespace goes with it having to be registered to a DevHub.

    can you clarify whether this is a managed package or an unlocked package with a namespace

    I have been running into this case with a managed package. I have not attempted unlocked packages, but I do have one that I can try today.

    Thank you!

  3. Scott Wells repo owner

    No issues. I should be able to create a simple managed package with some @NamespaceAccessible symbols, install it into a scratch org, and see whether or not they’ve resolved the issues that prevented those symbols from ending up in the generated OST. That probablyh won’t happen until next week at the earliest, but I’ll let you know what I find.

  4. Scott Wells repo owner

    Okay, I managed to test this a bit today and it’s unfortunately unchanged from how it was last time I checked. Basically non-global Apex symbols from installed managed packages are not reported to external clients, so IC2 has no way to include those symbols in its generated offline symbol tables.

    To provide a little more context, I uploaded a 2GP managed package version with namespace ic2gp and the following class:

    @NamespaceAccessible
    public with sharing class Issue2582 {
        @NamespaceAccessible
        public void issue2582() {}
    }
    

    I then installed that package into a scratch org that also has namespace ic2gp. When I generated the offline symbol table, ic2gp.Issue2582 was not included, and it’s because of the following:

    SELECT NamespacePrefix, Name, Body FROM ApexClass
    
    NamespacePrefix  Name       Body
    ic2gp            Issue2582  (hidden)
    

    As you can see, the org isn’t providing any useful information about the @NamespaceAccessible class/method even though that class' namespace is the same as the org’s namespace.

    I’ll raise this with Salesforce again as it seems like such types should yield the @NamespaceAccessible interface from the perspective of the subscriber org. However, until that’s addressed by Salesforce, the only way that IC2 could include those symbols is if they’re added to the project somehow in source form.

  5. Scott Wells repo owner

    After chatting with Salesforce I’ve found a way to incorporate @NamespaceAccessible symbols into the OST and have committed the required changes. They should be included in the next official build.

  6. Scott Wells repo owner

    Delivered in 2.3.2.0. Please let me know if things don't look quite right upon regenerating your OST after updating to this build (or later).

  7. Log in to comment