Permission Set possibly preventing installation of managed package

Question

We just uploaded a new small revision to our managed package. It had a few code changes, one new tiny test class, and a permission set. Previously the package did not contain a permission set.

Upon attempting to install this package into a new test org, I am getting the error

Your requested install failed. Please try this again.

None of the data or setup information in your salesforce.com organization should have been affected by this error.

If this error persists, contact salesforce.com Support through your normal channels and reference number: 1804561346-77209 (-1710372099)

Installation failures occur both on upgrade and fresh install attempts.

I have filed a Case with partner support, but hoping that someone else has seen this before and knows of a workaround.

I'm not certain that the permission set is the culprit but it seems the most likely candidate. It is a pretty basic permission set, it contains permissions for read and read/edit access on a number of standard and custom objects and their fields. But of course since I uploaded a released managed package, I am unable to remove the permission set from the package to test my theory.

The only other difference I can think of is that in our packaging org, since the last release, we have enabled Push Major. Seems an unlikely cause though since these errors were encountered upon manual installation.

Any ideas much appreciated!

EDIT: I'm now 90% sure this is the cause: https://success.salesforce.com/issues_view?id=a1p30000000SbMUAA0 and am removing M/D permissions as a workaround.

EDIT 2: I have confirmed this was the cause. After removing all my Master/Detail object permissions, the installation worked. Sure hope that platform bug gets fixed soon.

Answer 1

you were dead on - when I looked up the issue, I found that you were creating a dependency on the Campaign standard object.

Unfortunately, we don't have the ability to break containment of a package to set permissions on things that aren't in the package (like Campaigns).

We have discussed this issue internally and are trying to work out a way to allow this through the various install and upgrade paths where admins are aware that you may be giving access to something that is not explicitly defined in the package. It's not an easy problem to solve technically or functionally but we know it's important to address it so that you can continue to build applications on top of standard [CRM] functionality.

There is an idea on ideaexchange around this: https://success.salesforce.com/ideaView?id=08730000000kmm6AAA - please comment, vote, and evangelize this to other members of the community.

There is a work around. You can define a lookup relationship to the Campaign object (lookup doesn't require the antecedent permission). You can then use the post install apex script functionality to create a new permission set with access to the standard object. This is sub-optimal for a number of different reasons but may help provide your subscriber with the access to campaigns that you may need.