Permission Sets for Site Guest User

Question

Managing permissions on a force.com site is one of my least favorite things to do. If you got it right in dev, then move to QA, you have to write down all the permissions because you can't deploy them.

I was excited when winter 13 allowed permission sets with a license type specified (Guest was never an option!) that can be assigned to any profile.

I said to myself, "Self! We can assign a permission set to the guest, and then migrate that with change sets and save us a ton of work!"

So I did...but here's the thing. The permission set migrates via change sets, but only the page permissions came with it. None of the object/field permissions were there. These were all custom objects.

I have not tried other migration options (IDE, workbench, etc). This was a brand new PSet, so I had not assigned it to anyone in the destination org yet.

Can anyone else repeat this, or know what might be wrong? Have you played with the no-license specified permissions and successfully migrated them?

Answer 1

I'm the product manager at salesforce.com responsible for profiles and permission sets. Any issues that come up are definitely a concern for my team and me to solve.

John Brock (one of our QE) and I just walked through both a MdAPI deploy using workbench (http://workbench.developerforce.com) as well as a change set deployment.

I was able to deploy both standard and custom object permissions through workbench and standard object permissions through change sets. Both deployments were successful. We don't migrate assignments of permission sets to users in the MdAPI, but just in case, I did make sure we were able to deploy the permission set that was assigned to the Sites user in both the sandbox and production.

Also, we spent a lot of time building validations into org-wide permission sets so if there was an invalid permission set assignment, we typically would fail the deployment with an error message rather than drop the permissions on the floor.

I'd like some more information on the issue you're encountering.

Can you please tell me: 1. are you migrating standard | custom | both standard and custom object permissions

1. if standard object permissions, which object and what are the permission settings (CRUD) on them

2. were any of the object permissions on managed package objects (which aren't supported in the MdAPI)

3. if custom object permissions, did you include the custom object as well in the change set or just the permission set

4. did you test this only in change sets or did you try either the Force.com IDE or a tool like workbench which supports MdAPI retrieves and deployments?

5. was the org-wide permission set assigned to the sites user only or other users (with other user licenses) and if so, which licenses

Please let us know more about your use case and we'll see if we can reproduce it. If we can reproduce it, we'll get a fix in there for you.

Sorry you're encountering this!

Adam

btw, @jkraybill if you encounter any missing features / bugs / unsupported enhancements, always feel free to reach out as we'd rather find out sooner than later and get it fixed as fast as possible for you. Thanks!

Answer 2

This looks like the metadata side of things has gone slightly awry as part of the latest release. I don't think the site guest user side of things is a factor, as that information is associated with the user record, not the permission set itself.

I have an old copy of a project in eclipse and the permission set files have the field accessibility for every field on every object (most are set to false, as I'm using it to provide access to a very small set of functionality). The files are huge and look very much like the profile files.

I've then refreshed this from the server and all of the field/object information has disappeared. This happens regardless of whether I tie the permission set to a specific license or make it organization-wide.

If I then deploy this permission set to my target org via eclipse, the object/field permissions disappear. However, if I use change sets it goes across fine. This is again regardless of whether I tie it to a particular license or not.

What is odd is that if I retrieve the permission set xml using the Force.com migration tool, all of the object and field information comes across. I originally suspected that the version number in package.xml was to blame, as eclipse will hit the endpoint supported by the plugin, but that's not the case as the version is 25.0 for both eclipse and the migration tool.

Answer 3

I've also had trouble deploying permission sets. Initially I added a permission set to our managed package, but it made the package uninstallable, so we had to have Salesforce support roll back the package and remove the permission set. After that we tried a different approach - publishing the permission set in an unmanaged add-on package. Here's the scenario:

1. Managed package with custom objects is installed in the target instance.

2. A dev org is set up to create an unmanaged package for the purpose of building and deploying a permission set to the target instance, and other instances like it.

3. The manage package is installed in the dev org and permission set created.

4. An unmanaged package containing the permission set is published and installed in the target instance.

5. Permission set is applied to a Community user profile (custom) which has access to the managed package.

End result: none of the visualforce pages, object permissions, or field permissions are applied to the Community user profile.