@info – The practical side of SharePoint

Posts Tagged ‘Permissions’

Service Requests and Sensitivity

Posted by sharepoinTony on January 25, 2010

I recently implemented a customized version of the Microsoft Help Desk template for SharePoint 2007.  Quickly after launching I adjusted things based on feedback and input that never came prior to the launch.


The service request system, implemented via the help desk template, by default requires that all employees have access to submit requests.  The open-nature of SharePoint (and most IT departments) also dictates that users be able to see the pending service requests.  This visibility is normally thought of as a good thing for IT and helps promote self-service internally.  One of the customizations that I put in place was a notification workflow that sent email to the help desk staff telling them of newly submitted requests.  This workflow also automatically responded to the customer via email providing confirmation that their submission was successful.  The email provides a link back to the service request list so the customer could see all of the pending requests, including their own.

The Request

One significant post-launch request came from Human Resources.  They occassionally make requests that are sensitive in nature, such as terminations.  HR felt that those requests should not be visible to all employees.  This posed a problem for the service request list.  There is no doubt that it is a valid request, and the desire to keep most requests visible to users hadn’t changed, so I now had an exception to deal with.
Options considered were limited for various reasons.  One option would be to simply make a duplicate request list for sensitive HR requests.  But that meant managing two lists for the help desk, tracking two lists worth of requests for IT management, and created a possibility that a request might sit un-noticed.
Another option was to avoid using the service request list for all sensitive requests.  HR could send an email request as they had done historically in this small company.  Everyone was already “comfortable” with that process, however no improvements would easily fit into the old email process.  Reverting back to an old process just didn’t sound good unless there wasn’t a better solution.

The Solution

The solution concept chosen was to install a CodePlex feature that would allow a workflow to change the permissions on specific requests.
The concept was that sensitive requests could easily be identified since HR knew at the time of submission whether or not the request was sensitive, and could simply ‘mark’ the request as sensitive.  The workflow could check the column used for this purpose and based on its value could change permissions on that specific item.  We could limit the visibility to the appropriate staff without significantly changing the existing service request system.

The “Useful SPD Workflow Activities” feature from CodePlex was installed on a test server and the concept was examined closer.  After successful examination and testing it was decided that this would provide a very acceptable solution to the situation, and a quick response to the request from HR.
I created a new workflow to manage these permissions changes for two reasons.  First, I like keeping workflows as simple as possible.  Second, I wanted to be able to provide the flexibility to execute this behavior without sending emails that may be confusing which might come from adding these steps into the existing notification workflow.
The new workflow is very simple.  I check the designated column in the service request list and if it indicates that the item is sensitive then I remove a SharePoint Group’s permissions to the list item. I use several SP Groups to provide access, one contains all users, one contains appropriate HR staff, and one contains help desk staff.  When I remove all permissions from the group containing all users then only the members of the HR and Help Desk groups can see the item in the service request list.  There is no impact to other users or other requests.

Because the workflow can be started manually, we have the flexibility to “hide” any request that comes in by simply modifying the designated field and initiating the workflow.  This means that if HR forgets to “flag” a request, or if any other request is deemed sensitive we can quickly and easily “fix” it without having a workflow running all the time to monitor changes to requests.  Everyone is happy with this solution and it took longer to write this blog post than it did to implement in production.
Footnote: This CodePlex feature was installed and implemented on a 64-bit Windows Server 2008 system running MOSS 2007.

Posted in Lists, Permissions, SharePoint Tools, Workflow | Tagged: , | Comments Off on Service Requests and Sensitivity

“User Manager” Custom Permission Level

Posted by sharepoinTony on May 17, 2009

We needed to set up a group that would be allowed to add users to their SharePoint site, but not allowed to make changes to the site.  The default SharePoint “Owners” group provides for Full Control, and the existing Permission Levels provide for Designers etc. to allow you to control who is modifying the look and functionality of the sites.  Nothing exists to let you give people the permissions to add users to their site or to specific SharePoint groups.   Fear Not, SharePoint does provide the means for you to create this functionality…through the creation of a Custom Permission Level.

This is my story of creating such a permission level, shortened  to save your sanity and to save you time.  Follow along if you want to create a new permission level like the one described herein.


Our requirements sound simple:  provides the ability for designated users to manage users (specifically, add and remove users from specific SharePoint groups) for specific sites within a large site collection.

  • The users should not be able to grant permissions beyond their own permission set.
  • The users should not be able to modify or create lists, add web parts, or do any other modifications to the site.
  • The users should not be able to create new SharePoint groups.
  • The users should be limited to adding and removing users from designated groups.

Note that this article is focused on creating this permission level for a MOSS 2007 site collection.

Solution Concepts

The initial concept was to create a custom permission level, assign the user that permission level and taadaa task complete.  Not so fast. When we assign the permission level directly to the user we get some additional administration maintenance.  So, our solution consists of a few components.  We will need a Custom Permission Level, and a new SharePoint Group.

The concept is that our Permission Level will limit the user to the tasks we designate and by assigning the permission level to a new Group we make it easy to manage and maintain these users.  We also gain the ability to segregate this privilege by site because we can create groups for each site and provide grant these permissions to that site only.  Additionally, we want to control which groups the user can add or remove people and that is fairly easily done with a  group as you will see.

In our situation, we realized that the folks who would be getting this new permission level would also have Contribute rights to the site.  That being the case, I wanted my custom permission level to contain the permissions associated with standard Contribute and just add the ability to add/remove users.

Creating the Custom Permission Level

There is plenty of help out there that walks you through creating a custom permission level.  The tough part of this assignment is figuring out what permissions you give to this customized permission level.  The pitfall is that you DO NOT want to give “Manage Permissions” or else you will be enabling those folks to hand out Full Control permissions to themselves and their buddies.  The key to this is providing Enumerate Permissions.

I suggest the following steps to create this new Permission Level:

  1. Go to Site Settings > Advanced Permissions > Settings > Permission Levels
  2. Select Contribute, scroll to the bottom
  3. Click on the “Copy Permission Level” button
  4. Name your Custom Permission Level – I will call it “User Manager” for this article
  5. I suggest filling out the Description with something like “Contribute and Enumerate Permissions” or whatever will make sense for your environment
  6. Scroll down to the Site Permissions section, find and check the check box for Enumerate Permissions
  7. In our environment we removed the check from the Use Self-Service Site Creation check box because we didn’t want that for our users.  Make any other permissions adjustments that make sense for your scenario and environment
  8. Click on the “Create” button
Custom Permission Level

Custom Permission Level

As you can see I added View Usage Data and Manage Alerts because we wanted our User Managers to have those abilities.  Notice that Browse User Information and Browse Directories is also checked.  Your User Managers will need those two items as well.

Now you should see this new Permission Level on the Permission Levels screen.  Hurray, part one done.

Creating a new SharePoint Group

In our scenario we want to assign the new User Manager Permission Level to a SharePoint Group.  Since I want to be able to segregate which users will have these permissions for which sites I actually created a SharePoint Group for each site in our site collection where this would be used.  You will have to map out how you need to use this and go forward based on that.  For the sake of this article, I will only walk through adding one group, this stuff should be pretty familiar to you if you have done any security administration for your SharePoint sites.

  1. Navigate to your Site Settings > Advanced Permissions > Settings
  2. This time select New Group from the New menu in the Site Permissions screen
  3. Name your group – I named mine “site-name User Managers” where site is the name of the site where this group will have authority
  4. For About Me, I suggest a description something like “This group has User Manager permissions to add and remove users on the site-name site”
  5. Scroll down and select your new custom permission level “User Manager” in the Give Group Permissions to this Site section
  6. Click Create

You can choose to add users now to this group or do it later.  By default you will be added as a member of this group.  I like to remove myself from the SharePoint groups that I create simply because I don’t need to be in all of these groups and I feel it is a “clean” way to manage groups.  Part two done.

Adjusting Group Ownership

Now that we have a SharePoint Group with the User Manager Permission Level, we can use it to control what Groups can be “managed” by that group.  Sound confusing?  Hopefully that won’t be the case as we walk through these steps.  First, take a look at the Groups in your site and decide which groups you want your User Managers to be able to add and remove users.  I didn’t want them adding users to the “Owners” Group, but I do want them to add/remove users in the “Visitors” and “Members” Groups for example.  Here are the steps you should take, repeating them for each Group that you want the User Managers to manage.

  1. Click on Groups in the Quick Launch
  2. Click on the Edit icon next to a Group you want the User Managers to manage (“Site Members” for example)
  3. In the Change Group Settings screen, go to the Owner section and delete the owner that is listed
  4. Enter the SharePoint Group you created for this site in the previous steps.  in this example it is site-name User Managers
  5. Scroll down and click on the OK button
  6. Repeat for each site Group you want managed by the site-name User Managers

By making this Group the owner of the Members group SharePoint will allow the members of the site-name User Managers group to add and remove users to that group.  Part three done.

Grand Finale

When you have completed the above steps in all three parts, and have added users to your new SharePoint Group(s) then your work is done.  Almost.  I suggest getting together with one of your users that has been placed into a User Managers group and testing it out.  Have them go to the site they should have permissions to and have them go into Site Actions, Site Settings (or Site Actions, Site Settings, Modify All Site Settings).  They should now see Advanced Permissions under the Users and Permissions section of the page.  When they click Advanced Permissions they will see the Site Permissions page and should have the New menu item above the list.  Have them add a user and remove a user…it is good for you to see them do it and good practice for them to learn how to do that task. Now you are done.

Posted in Permissions, SharePoint 2007 | Tagged: | 7 Comments »

Document Library Permissions

Posted by sharepoinTony on February 26, 2009

This is a true story where the names where changed to protect the innocent. That doesn’t make it a valuable story. I will let you decide what makes it valuable to you, I already got my value out of it.

The Beginning
A site owner went to their SharePoint Site Collection Administrator (SCA) with a problem. The owner had multiple document libraries and had created multiple folders in each library. She set permissions on each library and on each folder in each library by ‘breaking’ inheritance from the site and granting permissions to individuals and groups appropriately.

The site owner granted Read permissions to a specific user on each of the libraries. She also gave that user Read permissions to several specific folders within each of the libraries.

[Before anyone gets excited, you should know this department handles personnel files, awards & bonuses, reviews, new positions, etc. In this environment it is appropriate to create this structure because it allows staff to maintain all of these documents in one general area while also allowing segregation of information and the application of proper security for various people with varying needs.]

The Problem
The user with Read permissions reported that he could see all of the libraries and the folders he expected to see, but could not see the files in several of the folders. He could see the files in one folder in one of the document libraries.

The Questioning
The SCA verified what the user could see and not see specifically. Learned that the user could see everything that was expected, based on permissions, in the one library. He also learned that this user could browse through the site to the other libraries and see the appropriate folders in each. The user appeared to be ‘in’ a folder with a message saying there were “no items to display” just as when you navigate into a folder with no files.

The First Attack
The SCA checked the permissions at the Document Library and Folder levels. He checked the files within the libraries folders to see that the user in question did in fact have Read permissions within the folders. After checking and comparing the permissions between the library where the user could see the files with those “that didn’t work”, he went up a level and checked permissions for the site.

Everything seemed correct.

The Second Attack
The site owner said she had only added this user at the Library and Folder level, maybe the ‘auto-addition’ of the user at the site level was somehow corrupting something. (When you add a user to a Document Library that did not previously have access to the site housing the library, that user gets “Limited Access” permissions set on the site). Maybe we just need to start fresh. Yeah, let’s just remove all of this users permissions and try again very methodically and carefully. That didn’t improve anything.

The Third Attack
Maybe a test is called for. This is a permissions problem isn’t it? The SCA found a user who did not have access to any of these libraries, who could be temporarily trusted to see the files contained there. Adding this new user with Read permissions, exactly as had been done with the ‘problem user’ would be a good test. If the new user could see the files as expected then there must be something outside of the application of permissions causing this behavior. If the behavior was the same, then we swear quietly and dig in further.

Swearing Completed
So the same exact behavior befell the new user. What is missing…hmm, lets look at all of the settings for these Libraries. So the SCA set about to systematically look at every setting in the “good” Document Library and catalog the ‘notable’ items. Moving on to the other Libraries and comparing the settings he finds one significant difference. Versioning is turned on for the Libraries where the user cannot see the files as expected.

Hmm, let’s see what happens if we check that little radio button that tells us it will allow anyone with Read access to see Draft documents. Whattayaknow, the test user can suddenly see those files.

The Learning
When Versioning is on, your uploaded files are considered Drafts until you either Approve them if approvals are enabled, or Publish a Major Version. All of the files were uploaded and left as Drafts. Clicking the helpful link to “Learn more” about drafts will provide a very helpful explanation of how the process works and the impact on permissions.

Drafts are not visible to people with Read permissions, only to those with Contribute or Edit permissions for that Document Library/Folder/File.

This makes sense. If you are working on a document you probably don’t want everyone to see it while it is a draft. Once you are ready you make it available to the viewing public (Readers) by publishing it. Handy, if you know that is how it works. Neither our site owner or SCA knew of this feature, but they do now.

The wrap-up consisted of determining a) if versioning really was needed or not and b) if versioning was going to be used, then did they want Readers to see Drafts or would they learn to publish a major version and turn off the option selected during the test.  If versioning wasn’t truly needed, then simply turning off versioning would solve the problem.

Posted in Document Library, Permissions, SharePoint 2007 | Tagged: , | Leave a Comment »