Method Not Visible within package

Question

I just started working with Managed Packages and did some experimenting with my first package and ran into a strange problem. Although, I was able to resolve it, I don't know why it works that way.

Please shed some light if you could...

I packaged my application as Managed Release and deployed it using the link on another instance of SF. Everything worked fine.

Now, I realized I want to include a utility class meant to be run on its own via Execute Anonymous or with code of course. So, I create another version of the package with this change and deploy it.

So, I try to access the class making sure to include the namespace:

trmn.Update_Criteria_Value_Field.populateCriteriaString('a02G000000AgTDk');

and I get: Method Not Visible.

The class was defined with access modifiers like this (pseudo):

global class Update_Criteria_Value_Field {

  public static void populateCriteriaString(String AlignmentId)
  {
     ....

  }

   private static Map<Id,String> getCriteriaString(String alignId)
  {

  }

}

When I changed all the access modifiers to global...it worked.

My assumption here is that to access a package class from outside the packaged code, the modifiers must be global, but from code with the package, regular rules apply.

Is this correct?

Thank you.

Answer 1

"Private" means "available only within the outer class", "public" means "available only within the same namespace", and "global" means "available anywhere the code is visible, including organizations the package is installed in."

You can't access "private" or "public" members of a managed package from outside the managed package, even if the class itself is global. This allows you to have "helper" functions that are available only within the class or your package, but still export "global" functions that can be used in unmanaged code or managed code from other namespaces.

For example, a global function might call a number of helper functions for legibility purposes, and those functions themselves might not be visible because they are in local utility classes. This can also help protect intellectual property while still granting "hooks" into your managed package.