I am confused what Salesforce Support is telling me regarding my cases also reflected in those questions:
- Tracking errors in batch impossible as Dev Console stops logging or breaks with Server error
- Best Practice to pinpoint bugs in your managed code that only occur in customer orgs
As @Andrew Fawcett proposed I started debugging customer bugs in their org using “Granted Login Access”. I then faced the problem that for long running code the logs are not reliably kept. Neighter in the Debug Logs section of the setup nor in an open Dev Console.
After I opened a case Salesforce Support helped me pinpoint this error (but the linenumber they told me was wrong due to Incorrect line reference from NullPointerException).
I asked supported why I cannot do this alone and they asked me to open another case to activate “Managed namespaces to log in Apex Debug Log” permission for that single customer org.
Now I am really confused!
- Why is the Subscriber support not working for me?
- What will this extra permission allow me to do? What can I see without it?
- Why do I need to enable it per customer and not for my ISV package?
- Why is this only temporarily activated by Salesforce?
- What is an efficient, repeatable way to pinpoint errors in managed batches in customer orgs??**
Why is the Subscriber support not working for me?
We use this feature extensively, and it is solidly reliable. Try checking your browser settings, clearing the cache, etc, the usual things that you should do when using salesforce.com. Assuming you are security-reviewed, you should be able to obtain logs normally through the Developer Console.
What will this extra permission allow me to do? What can I see without it?
This permission isn’t documented anywhere that I could find, so it’s probably an undocumented feature (this sounds redundant, but some features are documented, just hard to find). From the description of it, it sounds like the feature will allow an organization to obtain the logs from managed code (instead of just seeing “ENTERING_MANAGED_CODE” … “EXITING_MANAGED_CODE” lines, they can see everything between).
It doesn’t grant you any extra permission. It grants your client the ability to obtain debug logs for your managed code (thus exposing your IP to the client). This would be necessary for code that you can’t run under your own context. For example, you can schedule a class, but that class would run in the user’s context, not your own “Subscriber” context (which exposes your managed code logs). Also, the Debug Logs setting runs in the org user’s context and not the Subscriber context, so using this logger requires the permission. The Developer Console should always expose your managed code for you, including asynchronous calls and API calls made while your console is open.
Why do I need to enable it per customer and not for my ISV package?
Why is this only temporarily activated by Salesforce?
I think I’ve already answered this by the previous answer, but in case it’s not clear, if this feature were tied to your package, /all/ of your clients would be able to debug your code, not just the one having problems. This exposes your Intellectual Property (one of the primary reasons for having the package managed to begin with), and bloats their log files with code that they shouldn’t need to see. This feature would also degrade their performance slightly, since logging takes up CPU time. Like the Creatable Audit Fields permission, it’s more of a hack than a feature, and meant to be used only if absolutely necessary.
What is an efficient, repeatable way to pinpoint errors in managed batches in customer orgs??**
You should be able to use the Developer Console; it should “reliably” work. Furthermore, as long as “Notify Apex User” is set, you should also get emails when something breaks. While this is somewhat dodgy (it doesn’t always get to you), make sure that setting is correct.