15

InstallHandler is the interface you implement for a post-install script in a managed package. Per the docs:

It runs as a special system user that represents your package, so all operations performed by the script appear to be done by your package. You can access this user by using UserInfo.

I just added some functionality to a previously working install script to populate a new custom field the package installs against Lead, but unexpectedly got

System.QueryException: sObject type 'Lead' is not supported.

when it ran as part of the InstallHandler. When the same code is executed in the target org by a normal user it runs fine.

I'm theorizing that this "special system user" has a limited set of permissions, and although I've worked around it for now I'd like to know what other limitation it has so I can avoid them. I can't find any docs on this though. Anyone know more than what's on the docs page above?

Improve this question
9
  • Does your package have any API restrictions by chance?
    – ca_peterson
    Aug 9, 2012 at 16:24
  • Nope, it's unrestricted, but it appears that perhaps the install handler runs before those preferences are applied?
    – jkraybill
    Aug 10, 2012 at 1:44
  • 1
    I can't see any more public documentation than that, but I'll see if I can find someone that can provide more detail.
    – metadaddy
    Aug 16, 2012 at 21:56
  • Can you post your code? I've been fighting intensely with some InstallHandler bugs over the past month and might be able to shed some light. Is all of your code within the class that implements InstallHandler (as opposed to some of it being extracted out into other classes)? Is it a "with sharing" class?
    – zachelrath
    Aug 21, 2012 at 16:56
  • 1
    @metadaddy yep that's cool with me. As long as folks get the info they need to avoid this hassle, i don't care who posts it :)
    – zachelrath
    Nov 1, 2012 at 11:31

1 Answer 1

Reset to default
9

No docs, but zachelrath has written an awesome blog post on the subject of install scripts: Migrate your post-install and uninstall tasks to Apex Install Scripts. I'm pasting the relevant info below, but go read the whole post!

In the absence of documentation, the only way to find out was to either ask questions of the SFDC community, or find out through experimentation. I did both, and here are some things I discovered:

  • Install Scripts execute as a totally unique User and Profile
    • Neither the User nor Profile exist in either Source or Destination orgs.
    • This User / Profile has essentially ‘God’ / System privileges
    • This User / Profile can create / modify records of Standard objects as well as Custom Objects / Custom Settings that come with the package being installed.
  • DML operations fail if they are not initiated from the class which implements the InstallHandler interface
    • A DML operation executed from a helper class will fail due to SObjectExceptions such as “Field Name is not accessible”
    • Simply extracting this code back in to the class which implements InstallHandler can avoid this issue
  • Schema Describe Information on Object or Field Accessibility always returns FALSE
    • Calls such as Contact.Name.getDescribe().isAccessible() will universally return FALSE regardless of Profile permissions in either Source or Destination org
    • Consequences: Do NOT try to dynamically determine whether to permit DML based on permissions from within Install Scripts. You will get very frustrated.
    • Timeline for Resolution: Spring 13 release (Safe Harbor — got this from SFDC support)
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .