7

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?

Improve this question
2
  • I'd put my money on missing feature / bug / unsupported. There are a few ways in which the Sites guest user is a second-class citizen of the User world.
    – jkraybill
    Dec 18, 2012 at 0:43
  • I agree J. But let's separate what I'm doing with the PSet from the fact that I couldn't migrate objects/fields on a no-license PSet.
    – Shane McLaughlin
    Dec 18, 2012 at 5:11

3 Answers 3

Reset to default
5

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!

Improve this answer
7
  • Adam, thanks for the response. I made some edits to my original question to answer some of yours. All custom objects, non-assigned Pset, moving via change set from full sandbox to PRD org.
    – Shane McLaughlin
    Dec 18, 2012 at 19:36
  • Hey @ShaneMcLaughlin - was just talking with one of my devs about this. Another issue might be if you have a master detail relationship to an object that is not supported by the Sites Guest user license - although I would think this would fail if you had assigned this permset to the guest user in the sandbox. Can you provide some more information about the custom objects and the permissions you are trying to set on this permission set? thanks!
    – Adam Torman
    Dec 18, 2012 at 19:56
  • 4
    Awesome to see the product managers engaging through this channel.
    – Bob Buzzard
    Dec 18, 2012 at 22:21
  • 2
    Really glad to see the salesforce stackexchange take off!! It's an awesome forum for discussing developer and administrator challenges!
    – Adam Torman
    Dec 18, 2012 at 23:39
  • Thanks for engaging here, Adam. Honestly I've given up submitting to Ideas which is what I've always been told in the past. But since you're volunteering, the lowest hanging fruit IMO would be additions of power edit tools like "select all" to every row and column in the profile checkbox-city editor. Also the ability to edit all profiles at once, or select which profiles, for every permission and setting. Customers with 30+ profiles drown under the weight of clicks required for every deployment. The UI "upgrade" actually made click volume worse for many customers.
    – jkraybill
    Dec 19, 2012 at 3:04
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.

Improve this answer
0
0

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.

Improve this answer

You must log in to answer this question.

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