You need to sign in to do that
Don't have an account?
Shiztastic
Message Edited by Shiztastic on 10-21-2008 02:45 PM
Schema.getGlobalDescribe
Is there any reason the Schema.getGlobalDescribe() method would suddenly stop returning anything? I have noticed this strange intermittent behavior seems to start when I run test cases. Sometimes the getGlobalDescribe will just stop returning anything for a day or so and then it just magically starts back up again.
Any info on why this happens would be much appreciated. Thanks.
Shiztastic
Message Edited by Shiztastic on 10-21-2008 02:45 PM
For closure, it looks like Spring 09 addressed this issue. From the release notes:
API Access Change for Dynamic Apex Scripts
Prior to Spring '09, when the API Access for a package was set to Unrestricted, dynamic Apex scripts only had access to the custom objects contained in that package. Now, when API Access for a package is set to Unrestricted, dynamic pex scripts have access to the custom objects contained in the package as well as all standard and custom objects in the ubscriber's organization.
All Answers
I don't understand how there could be a difference between the two methods. Are there multiple sets of compilers operating on different components? Seems like everything would be compiled and run on the same code base.
Here is what my code looks like:
Running the above in the System Log's "Execute Apex" box, the "options values: " debug line returns the following:
Everything is working just fine. However, when I try to execute the code in Apex (via a Visualforce page), I get this:
Which points at line 12 in the TestClass:
Communication between the Visualforce page and this Apex TestClass (added as an extension in the Visualforce page) is valid (previous tests affirmed this).
Could this be a temporary bug from the Winter '09 update?
If I take the class out of the package and run tests then globalSchemaDesc.size() == 161, it sees all objects
The documentation references limitations for packaged describe statements (http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_dynamic_describe_objects_understanding.htm):
Understanding Describe Information Permissions
Apex generally runs in system mode. All classes and triggers that are not included in a package, that is, are native to your organization, have no restrictions on the sObjects that they can look up dynamically. This means that with a native script, you can generate a map of all the sObjects for your organization, regardless of the current user's permission.
Dynamic Apex scripts, contained in managed packages created by certified Apex partners, that are installed from Force.com AppExchange, have restricted access to any sObject outside the managed package. Partners can set the API Access value within the package to grant access to standard sObjects not included as part of the managed package. While Partners can request access to standard objects, custom objects not included as part of the managed package and can never be referenced or accessed by dynamic Apex scripts that are packaged.
The behavior I'm seeing, however, does not appear to match SF's description. I would expect the packaged class to at least see the custom objects that are in the package. In addition, my package is setup with "API Access Unrestricted [Package contains S-Controls]" so I would also expect to see standard objects too.
Can someone at SF shed some light on this?
While Salesforce has been strangely silent on this it appears that the problem has to do with the API Access field on the package. My understanding is that in order to reference standard objects in any form of Dynamic Apex or Describe calls then the "restrictions" must be enabled for the standard objects. However, I experienced similar errors with a custom object that is included in the package. Such behavior seems like a bug. When I enabled Read permissions for all the standard objects listed the errors for my custom object ceased.
Apart from everything else the nomenclature seems backward. To permit accessing the objects then we "Enable Restrictions" and if we don't want to allow access then it's "Disable Restrictions"
Anyone else experiencing this?
Yet when I disable restrictions, all is fine and the communication lanes are open.
Actually, when I think about it, this functionality is most likely intended. It is the previously mentioned global describe functionality that seems to work backwards with the restrictions.
Hopefully a SF admin will be able to shed some light on this.
The work-around appears to be to avoid using packages with dynamic apex/SOQL until that fix is out."
System.QueryException: object is not accessible in query due to package restrictions
Namespaced(fRecruit) Dynamic code has access to fRecruit__Canidate__c sobject. But if the subscriber adds a field to the object, Dynamic code cannot operate on this custom field.
2) By default, namespaced code should have complete dynamic access on the namespaced objects/fields - regardless of whether PAC is enabled.
Hi Greg,
Shiztastic and I could probably reproduce this for you. It happens intermittently, but pretty (annoyingly!) frequently, too. We could do a web meeting, and sure would love to sort this thing out.
If that sounds good, please contact me at dancingjake <at> gmail.com
Thanks!
-Jake
http://www.sundog.net/index.php/sunblog/entry/getting-dynamic-apex-to-work-in-managed-applications/
BTW, this works well as long as you are only trying to interact with the 13 standard objects that are listed. Unfortunately there are a LOT of objects that are left out, such as the User object. Out of the 125 default objects that are visible in an unpackaged application, only 39 are visible once you package it.
Message Edited by NodakPaul on 01-08-2009 09:40 AM
For closure, it looks like Spring 09 addressed this issue. From the release notes:
API Access Change for Dynamic Apex Scripts
Prior to Spring '09, when the API Access for a package was set to Unrestricted, dynamic Apex scripts only had access to the custom objects contained in that package. Now, when API Access for a package is set to Unrestricted, dynamic pex scripts have access to the custom objects contained in the package as well as all standard and custom objects in the ubscriber's organization.
Yes, it did the trick-
Shizz and I have been able to reliably put out new releases ever since the little frog jumped on the scene.
uncaught exception: {faultcode:'sf:INSUFFICIENT_ACCESS', faultstring:'
I am not 100% sure this is related to this thread, but it was the only one that came up when I search for the above, so thought I might as well post it for anyone else to know.
I got the above error, when our users in Germany was using a button that called a S-control webservice
... sforce.apex.execute('ApexClass' , 'serviceName',...
What I found out was:
That in the Setup->Develop->Apex
The security for that particular class had to allow the user role, which makes senses, but was not obvious when developing using an admin account :).