Setting permission(Grant) to person column with multiple persons

Nov 16, 2008 at 6:48 PM
Edited Nov 16, 2008 at 6:50 PM
Does anyone know how I could utilize the excellent Grant permission capability when I have mulitple people stored in a person column? Any ideas on a workaround? I assume the Grant extension only works for granting to a single user or group.  I.E. The first item entry for this person column contains employee1;employee2. I'd like to grant both employee1 and employee2 read permission at the item level? The second entry for this column is employee2, employee3, and employee4.
Oct 29, 2009 at 3:17 PM
Edited Oct 29, 2009 at 3:18 PM

    For the second step, add a condition, If AllowedToSee01 is not blank, then Grant Permission on Item to AllowedToSee01

There is a workaround for this, but it involves a series of calculated columns and workflows. You can handle up to 20 people this way (well, see NOTES below).

Assumption is that you have a field called AllowedToSee which holds all the people that should get permission

1. Create some fields:

        AllowedToSee01       Calculated ... this field grabs the first user from AllowedToSee. e.g. all our ids are 10 char long, so I just use the following as the formula "=LEFT(AllowedToSee,10)". But you may have to do some trickier stuff like "find the 1st occurrence of a semi-colon" and take the midstring from that.

        AllowedToSee02       Calculated "=MID(AllowedToSee,13,10)"

        AllowedToSee03       Calculated "=MID(AllowedToSee,25,10)"

        ....  

        AllowedToSee20     Person or Group

2. Create a workflow that uses the SPDActivities Grant Permission.

    For the first step, add a action "Inherit List Permissions" on the current item.

    For the second step, add a condition, If AllowedToSee01 is not blank, then Grant Permission on Item to AllowedToSee01

    For the third step, add a condition, If AllowedToSee02 is not blank, then Grant Permission on Item to AllowedToSee02

    ... 

    For the twenty-first step, add a condition, If AllowedToSee20 is not blank, then Grant Permission on Item to AllowedToSee20

 

This does work, but there are a couple of notes:

* The Inherit List Permissions step is run everytime in the event that someones comes back in and modifies the person or group field, this makes sure things are clean to start.

* You would think you can do more than 20, but there is a limitation in this logic. String manipulation only takes the first 255 characters from the person or group field. We can do 20 because all our user ids are 10 long + space + ; = 12 long per user id = 240 characters for 20 users (we could actually handle 21 users, but no matter). Anyways, if you have variable length ids, then you may want to drop down that length to something different (e.g. just put in the field description that it only accepts 10 users or something).

 

Dec 1, 2010 at 2:24 PM

so if I understand you correctly, I need to create a calculate column (lets call it RestrictedUsers)that would contain the following:

I have a single value people picker field called 'Authorized By', I have another single value people picker field called 'Requested By' and a group I created on this site ca''ed 'Attendance Managers'

The issue I am having is those people picker columns are not showing up as choices for my calculate column - so what should I do?

Also, what are the ACCESS levels I can grant?

and do you mean 'Reset List Permissions Inheritance' before I start changing permissions? I don't have 'inherit list permissions'

 

Dec 1, 2010 at 9:10 PM

SharePoint has a list of various permissions you can grant; you can either use the defaults, or create your own levels using SPD.
For permissions, from what I recall, I typically use “Read”, “Contribute”, and “Full Control” since they’re out of the box and generally take care of what we need.
Let's take an example for a list called Change Requests.

The workflow is set to run when an item is created or modified.
The first action will be “Inherit list permissions on Change Requests"
(Note: When selecting from the actions dropdown, it says "Reset List Permissions Inheritance" ... choose that one to get the above text to show.

Then, I generally have a group setup with group permissions that contains anyone adding anything to the list.
In this example, I would have a group called "Change Requests Contributors"
So, my second action is to "Delete permission assignment in Change Requests for Change Requests Contributors".

The third action is to give contribute rights to the field "Authorized By"
After clicking everything, the action will say "Grant Contribute Permission on Change Requests to Change Requests:Authorized By"

The fourth action is to give contribute rights to the field "Authorized By"
After clicking everything, the action will say "Grant Contribute Permission on Change Requests to Change Requests:Requested By"

The final action is to give contribute rights to the field "Attendance Manager"
After clicking everything, the action will say "Grant Contribute Permission on Change Requests to Attendance Managers"

Does that help?

Jan 10, 2011 at 6:56 PM

for some reason now something is wrong.

 

it was working but now my Managers can't run the workflows and approve the requests. It's a custom approval workflow.

The workflow says 'access denied'

They have 'Approve' access. Do they need approve AND contribute? or does approve not even matter because it's a custom workflow?

They are a part of a group that has Approve AND Contribute to the list... but I guess that gets restricted down to 'Approve' as an individual?

How can I do both? Levels? How?

Jan 13, 2011 at 1:38 PM

If it used to work, but now it says "Access Denied", then permissions got changed somewhere for the managers. I would consider a couple of different things:

* Make sure the Managers still have Contribute permission.

* Did the Approve role get changed? It typically only gives the user the ability to promote a minor version to a major version and maybe somebody added more permission to that, but then reset it back to its limited rights.

* I would open the workflow and look at it again and possibly republish. Maybe the workflow is doing something else that is causing the access denied error.

That's all that comes to mind at this time.