Different results for Schema information in different classes - why?

Question

I'm experiencing a very odd behaviour in my SF org. I have two classes that have an identical method:

/* works */
public with sharing class classA
{
    public static void getFieldDescriptions(sObjectType objType)
    {
        System.debug('Fields: ' + objType.getDescribe().fields.getMap().size());
    }
}

/* does not work */
public with sharing class classB
{
    public static void getFieldDescriptions(sObjectType objType)
    {
        System.debug('Fields: ' + objType.getDescribe().fields.getMap().size());
    }
}

Both classes are API v.34. One is new (created a couple of days ago), the other one about half a year and was just recently moved to v34.

Problem is: When calling either class's describe method (e.g. from the dev console), only one class lists all fields (standard + custom) fields - the other one doesn't (only custom). Since I did not add any fields to the Task object, one function thus returns 0 and the other one thirtysomething.

Sample invocation: classB.getFieldDescriptions(Task.sObjectType)

When outputting one map:

{accountid=AccountId, activitydate=ActivityDate, calldisposition=CallDisposition, calldurationinseconds=CallDurationInSeconds, callobject=CallObject, calltype=CallType, createdbyid=CreatedById, createddate=CreatedDate, description=Description, id=Id, ...}

the other:

{}

I'm logged in as a System Administrator, have full access to all objects, classes and fields (checked FLS) and can reproduce the problem for every other object as well: One class's method will return only the number of custom fields - the other one all fields (which of course is my goal). What I cannot do however is reproduce the issue in another org.

What else might (or might not) be relevant: There's a managed package being developed in the org. The first time I noticed the problem I was able to "fix" it by deleting and recreating the Apex class - after that all fields were returned even though no changes were made to the underlying code. I can't do that for the classes mentioned above however, since they're part of our managed package (which has already been deployed)...

Any thoughts or ideas that might point me into the right direction? I know this sounds strange but I've spends hours after hours narrowing it down but in the end didn't get anywhere. Any help is appreciated!

EDIT: Since describing in classA works fine I tried this: When I add another method to classA:

public static void callB()
{
    classB.getFieldDescriptions(Task.sObjectType);
}

and invoke it, the result will also be 0.

Answer 1

After a million more hours I finally found the answer to this question - I hope I can save someone some time....

The managed package was deployed having API restrictions in place (allowed were: Read access to accounts, contacts, leads, campaigns). Describing fields of these objects worked fine. All other objects however did not work.

I think you see were this is going... Removing the restrictions solved the describe-problem for all other objects. With regard to the above code: One class was already packaged and deployed (API restrictions enforced), the other one was new and not yet deployed (apparently API restrictions were not enforced). You can find the configuration here: Setup > Create > Packages > [your package] > API access (upper right).

Unfortunately there seems to be no way to just add API permissions for objects like tasks or campaign members...

Thanks for your help!

Answer 2

What you're describing doesn't seem to match with the behavior I'd expect as described in the ISVforce Guide. The code from the class in the managed package shouldn't even be visible to you from within the org it's been installed in. I'd also expect that it would only operate within the namespace of the managed package, especially since what you've posted hasn't been declared as Global. Here's some of what I'm specifically referring to:

• The code contained in an Apex class or trigger that is part of a managed package is automatically obfuscated and cannot be viewed in an installing organization. The only exceptions are methods declared as global, meaning that the method signatures can be viewed in an installing organization.
• You can use the deprecated annotation in Apex to identify global methods, classes, exceptions, enums, interfaces, and variables that can no longer be referenced in subsequent releases of the managed package in which they reside. This is useful when you are refactoring code in managed packages as the requirements evolve. After you upload another package version as Managed - Released, new subscribers that install the latest package version cannot see the deprecated elements, while the elements continue to function for existing subscribers and API integrations.
• Any Apex contained in an unmanaged package that explicitly references a namespace cannot be uploaded.
• Apex code that refers to Data Categories can’t be uploaded.
• Before you delete Visualforce pages or global Visualforce components from your package, remove all references to public Apex classes and public Visualforce components from the pages or components that you’re deleting. After removing the references, upgrade your subscribers to an interim package version before you delete the page or global component.