More Ways to Maximize SharePoint's Out-of-the-Box Features

2. In the Site Settings page, click on the Advanced Settings under the Users and Permissions section.



Figure 13: Site Settings page

3. Click on Settings and Permission Levels.


Figure 14: Settings dropdown

4. Click on Add Permission Level.
5. Type in the name for the new Permission Level.
• Email Article
• Print Article



Click here for a larger image.

Figure 15: Create new Permission Levels page

6. Select the permissions that you would like to provide. In the example, this will be same as "Contribute" permissions except that you will uncheck Delete Items in List Permission section and Manage Personal View in the Personal Permissions section.
7. Click Create.
8. The new permission level will be displayed in the Permission Levels page.



Click here for a larger image.

Figure 16: Permissions Level page with new permission level

9. Now, the "Limited Contribute" permission level can be leveraged in the "Dream Bigger" list. This will allow the users to submit ideas but not allow them to modify existing or create new views. Additionally, users now cannot delete existing submissions, hence protecting the integrity of the list.

Taking It to the Next Level

Now that you have seen how to create permission levels, what happens if the permissions that you would like to provide do not exist in the list of permissions (Step 6 above)? This is where creating permissions by writing custom code would help solve the problem. Creating custom permissions would allow the administrators to further control permissions such as not allowing contributors to view the Site Actions menu on a Publishing Page. Once the permission is created, it can be deployed as a feature and will appear in list of permissions (Step 6 above) for the administrator to choose as a permission level.

Scenario 3: How to Retrieve Custom AD User Vields into SharePoint and View Them in Users' My Sites

The problem

A hospital would like to leverage the current intranet, on SharePoint 2007, to provide the company with pager number and specialty of each doctor. All this information is currently being stored in Active Directory (AD) and there is no direct method for all users to access this database. The hospital is currently utilizing My Sites and can only see the default fields from AD that have been imported when setting the Shared Service Provider (SSP).

The hospital is currently using a list within SharePoint to manage the name, pager number, and the specialty of the doctors. This effort is manual and requires duplication of efforts because the IT Department already manages this in AD.

The solution

To view the custom fields from AD into SharePoint 2007, a new user profile property field will be added and mapped to AD. In SharePoint 2007, users' profile information is not limited to the fields that were originally imported during the creation of the SSP. Custom properties that have been created in AD can be mapped and imported in SharePoint. The profile property information is one way to provide AD information to the target audience within the company.

Page 4 of 5



This article was originally published on September 17, 2008