Managed Package 'Push Upgrade' with System Administrator profile privileges

Question

When I push upgrades to organizations that have already installed my applications, new Apex Classes and Custom Fields get created by a user with the 'Package Manager Profile' even though the package was originally installed by a user with the 'System Administrator' profile.

This means all of the Visualforce components that we push through the 'Push Upgrade' feature are not visible to users of the client org, because no one in the client org has the 'Package Manager' profile. The only way to give them access is to bundle in PermissionSets and assign those to every user in the org, which seems intrusive.

This problem does not occur if a SysAd in the client org installs the upgrade via the installation link.

Is this a bug in the 'Push Upgrade' feature? If a client has already given our package certain permissions during installation with his 'System Administrator' profile, shouldn't those permissions continue during future pushed upgrades?

Answer 1

I expect this is by design. Since the administrator of the organization has no control over what you're pushing, I would expect the administrators to have to go through a "post-upgrade" step to determine which feature(s), if any, should be enabled. When the administrator chooses to install an upgrade, they are given three choices: "admin only", "everyone", or "let me choose." This gives them the ability to control what features are deployed to their users. A default model of "all off" makes far more of a security argument than "all on." Most every IT department will tell you that upgrades are always vetted before they're released to their users (e.g. upgrading Windows, Microsoft Office, etc). In this way, it makes sense that since the upgrades are forced upon administrators (hence the "push"), that they should get an opportunity to choose which features are available to users.