Apex Code Development You need to sign in to do that
Don't have an account?
ChadMeyer Field visibility change in Summer '12 for managed package installs
We are seeing what appears to be an undocumented change in Summer '12 regarding the default field visibility for fields included in managed packages.
In Spring '12 and earlier, when you installed a package for System Administrators only, all internal users had visibility to fields included in the package. I agree this is odd, but it made setup easier on the installer.
In Summer '12, only System Administrators have field visibility (security) when installing for System Administrators only.
We are seeing this new behavior with 3 different packages we have.
I agree that the new behavior is logical, but partners will need to update their setup instructions quick.
Anyone have any info on this?
@ChadMeyer, The package installation wizard obfuscates a lot of granular information about how users will have access to package components post installation. However, the overall security is pretty clear in the wizard when selecting that an admin should be the only one with full access. We did discover that the installation wizard was telling the subscriber one thing and doing something else in this regard. From an ISV perspective, I can completely understand how this may be a desired behavior, but from a subscriber's standpoint, additional access was being granted incorrectly creating potential security issues. Trust is the most important value we have here so we had to make sure the wizard respects the security settings that an installer selects.
I would suggest using permission sets in your packages more to help with this desired behavior. They can maintain the field permission configurations that you want, allowing a subscriber to better understand the impact of those field permissions and determining how they want to assign the permission set post installation.
Chad didn't have an issue with the fact that this was changed so much as the fact that we, as developers, were not notified.
I haven't combed through the release documents myself to that level, but if this is the case, it definitely raises an eyebrow making me wonder what else was changed, and we weren't told about.
@craigmh - I understand your concern but one thing has nothing to do with the other - nothing else changed in our service because this changed.
This was about truing up the package interface wizard expectation. The wizard interface dictated the correct behavior all along which was that mapping should work as expected when mapping field level security rather than enabling it differently than you had configured in your profile setting. I think it's a great idea to have more control over the mapping process to be able to choose whether you get full field level security or an accurate mapping; however, at a minimum, we need to do what we were already telling you we were doing.
In hindsight, we should have put a note in the release notes to let you know that we are now doing what we originally told you we were doing.
Yeah, I don't think anyone feels misled, and you summed up everything perfectly in your last sentence.
Thank you for your responses.
Packaged profile permissions are causing internal server errors on installs in PE:
Thrown: lib.gack.GackContext: moduleapi.isv.packaging.exception.PackageInst=
allException: 00D80000000dXLm: Multiple install problems encountered [Case_=
Flags_End_User: Insufficient Privileges: You do not have the level of acces=
s necessary to perform the operation you requested. Please contact the owne=
r of the record or your administrator if access is necessary.]
Thrown-StackTrace:=20
I can't find any documentation stating that Profile Permissions are either not-compatible with or ignored when installed into a Professional Edition org. I have case# 07832385 open but I thought I'd share my experience here too.