Lists inherit permissions from their parent site. You can restrict access to an entire list or to items within a list.
To restrict who has access to a list:
On the list toolbar, click Settings -> List Settings, and click “Permissions for this list” under the Permissions and Management heading in the middle of the page. SharePoint displays the Permissions page.
Click Actions -> Edit Permissions. SharePoint displays a warning that you are creating unique permissions.
Click OK to proceed. SharePoint changes the display of the Permissions page so that you can edit the permissions.
Select a user or group and click Actions -> Remove User Permissions to remove access to the list for those users as shown in Figure 4-19.
Figure 4-19. Restricting access to a list
Figure 4-19 shows removing permissions for all users except the Administrator. That means only the Administrator can see the list; it is hidden from everyone else and if someone tries to access it, SharePoint displays an Error: Access Denied page (see Figure 4-20). Those two points confuse some folks:
In SharePoint, you generally can’t see what you can’t access. That means some lists, libraries, and sites may not appear on the Quick Launch or link bar for some users. That makes instructing users interesting sometimes!
The Access Denied page lets you sign in as a different user. Most folks have only one account, so that makes little sense to them. But when you’re helping someone, it’s handy to sign in as yourself, grant that person access, and then sign out by closing the browser (be sure to do that so the user doesn’t proceed with your credentials).
Figure 4-20.What the user sees if he/she doesn't have permissions to access something
You can also restrict access to individual items in a list. To do that:
Click Manage Permissions on the list item’s Edit menu, as shown in Figure 4-21.
Follow the same steps as for restricting access to a list.
Notice that I’ve only talked about restricting access. Actually, you can increase permissions as well, but that’s a much less common practice. In general, permissions are more restricted the deeper you go into a site hierarchy.
Figure 4-21. Use the edit menu to restrict access to individual items
Part of the reason for that is simplicity—it’s way too hard to remember how permissions are set if they don’t follow the physical structure. The other reason is visibility: as I mentioned above, SharePoint hides restricted items, so if a user has read access to a list within a site that she can’t see...it’s very hard for her to find that list.
SharePoint lists use these web pages to add, edit, and view items:
NewForm.aspx Creates a new item and adds it to the list.
EditForm.aspx Edits an item from the list.
DispForm.aspx Displays an item in read-only mode.
AllItems.aspx, MyItems.aspx, and so on Display a view of the list; views are stored as .aspx files alongside the add/edit/display pages.
These files are stored in the list’s folder within the site. For example, the Problem Reports new item page is stored at ./Lists/Problem%20%Reports/NewForm.aspx.
Why is that important? Because you can edit those pages to hide fields, add web parts, or change them in any other way. To edit pages directly, you’ll need SharePoint Designer. SharePoint Designer is “new” for 2007, but really it is just an updated and renamed version of Microsoft FrontPage.
There are a number of reasons why you might want to edit one of these standard pages:
To restrict what information is entered in new items
To display additional information on the page
To create a page that combines tasks
In the following sample, I’ll use SharePoint Designer to create a custom page to submit problem reports. I won’t go into detail on how to use SharePoint Designer (that’s a subject for another book); I’ll just cover the basics required to complete these application requirements:
Managers don’t want users to assign problems, set their priority, change their status, or categorize problems. Those tasks will be performed once the item is reviewed by a technician.
Users need a single place to go to submit items—they don’t want to navigate deep into a site or lose their place once they’ve submitted an item.
Users want to see the items they’ve submitted so they can tell if the issues have been resolved.
The following sections address each of those needs in turn.
The first task is to remove the unwanted fields from the NewForm.aspx page. To do that:
Open the web site in SharePoint Designer.
Open the NewForm.aspx page from the ./Lists/Problem%20%Reports/ folder.
Click on the Problem Reports list web part and change theIsIncludedelement tofalsein the code pane as shown here:
<IsIncluded>false</IsIncluded>
Click Insert -> SharePoint Controls -> Custom List Form. SharePoint Designer displays the List or Document Library Form.
Select the Problem Reports list and the New item form, and clear the Show standard toolbar checkbox as shown in Figure 4-22. SharePoint Designer adds a list form web part that can be edited.
Select the Assigned To, Issue Status, Priority, Category, and Related Issues table rows and press Ctrl+X to remove those rows.
Save the page and review the changes in SharePoint by clicking New on the list toolbar. It should look like Figure 4-23.
The Assigned To and Due Date fields are blank for new problem reports. You can set default values for those fields from the list settings page. You might want to set the default Due Date to [Today] + 14, and the default Assigned To person to the department manager. Since the Due Date appears on the NewForm.aspx page, it can be changed by the user; but since Assigned To doesn’t, new items are always assigned to that default person.
If this were a real application, you’d go back to your customer at this point and ask what default values he wants—that information was left out of the spec!
Figure 4-22. Replacing the form web part with a custom list form in SharePoint Designer
Figure 4-23. The vastly simplified form for entering Problem Reports
Under the current scheme, users need to know to go to the Problem Report list and click on New to submit a report. Once the report is submitted, they are returned to the Problem Reports list. That’s more clicking than they should really need to do. We can simplify their task by adding a tab to the site’s home page for the NewForm.aspx page. To do that in WSS:
Click Site Actions -> Site Settings, and then click Top link bar tab under the Look and Feel heading. SharePoint displays the Top Link Bar page.
Click New Link and enter the full address of the NewForm.aspx page; enter the label for the tab in the description field, and then click OK. SharePoint adds a tab to the top link bar for submitting problem reports.
To add a top link bar tab for the new item form in MOSS:
Click Site Actions -> Site Settings -> Modify All Site Settings, and then click Navigation under the Look and Feel heading. SharePoint displays the Site Navigation Settings page.
In the Global Navigation section, select “Display only the navigation items below the current site” to stop inheriting link bar tabs from the parent site.
In the Navigation Editing and Sorting section, select Global Navigation, click Add Link, and enter the full address of the NewForm.aspx page. Enter the label for the tab in the description field; then click OK. SharePoint adds a tab to the top link bar for submitting problem reports.
Providing Feedback After Submitting
When a user completes the new item form and clicks OK, SharePoint automatically displays the default view of the list. That’s not great feedback and it leaves the user with a few questions: Was the new item accepted? Which one is it? What do I do next?
To solve those problems, modify the default view of the list to display the new item clearly and to let the user know what to do next. To create the new view, follow the steps in “Creating Views,” earlier in this chapter, to create a new standard view for the Problem Reports list with the settings shown in Table 4-4.
Table 4-4. Create View page settings for the Submitted view
Section
Field: Setting
Name
View Name: Submitted
Make this the default view: Checked
Create a Public View: Selected
Columns
Select: Attachments, Issue ID, Type, Title, Assigned To, Due Date
Table 4-4. Create View page settings for the Submitted view (continued)
Section
Field: Setting
Sort
Modified, descending order
Filter
Current is equal to Yes
And
Created By is equal to [ME]
Group By
Issue Status, ascending order
By default, show groups: Expanded
Style
Shaded
Item Limit
20, display items in batches
The new view displays only the items the current user has submitted, and new items appear at the top of the list under the Active group with a green New! icon beside them. That’s clearer feedback, but the user still won’t know what to do next. To fix that, edit the view page to add a web part containing instructions:
Display the Submitted view.
Click Site Actions -> Edit Page. SharePoint displays the view in Edit mode.
Click Add a Web Part in the middle of the page, select the Content Editor Web Page, and click Add. SharePoint adds the new web part to the page.
Click the “Open the tool pane” link on the web part, click the Source Editor button, and enter the following code:
<script type="text/javascript"> if(document.referrer.indexOf("NewForm")>=0) document.write("<h3>Thank you for your report</h3> <a href='./NewForm.aspx'>Click here</a>to submit another report or <a href='../..'>click here</a> to go Home."); </script>
Click Save and then click OK to close the property pane of the web part.
The preceding example shows how to create a web part that runs client-side code. I call those client-side web parts, and they are powerful tools for customizing SharePoint. In this case, the web part displays a thank you message if the user has just submitted an item. That message is not displayed if the user just clicked on a link to the list.
When complete, the changes to NewForm.aspx and Submitted.aspx establish the simple Problem Reports workflow shown in Figure 4-24.
Figure 4-24. The completed Problem Reports application
SharePoint Designer sometimes breaks the link between the pages used to view, edit, and create list items. If the list starts showing Page Not Found errors, you’ll need to reset the form files for the list. To do that:
Open the web site in SharePoint Designer.
Expand the Lists folder in the Folder List pane on the left side of the screen.
Right-click on the list in the Folder List pane and select Properties. SharePoint displays the list properties.
Click the Supporting Files tab and select the correct new item form as shown in Figure 4-25.
Saving the List As a Template
Part of the beauty of SharePoint is that you can easily reuse your work. In the case of the Problem Reports list, this means you can save the list as a template, and then use that template to create new lists that include your unassigned and alert views, and any other customizations. Saving a list as a template is very similar to saving a site as a template.
Figure 4-25. Resetting the form pages used by the list
To see how this works:
On the list toolbar click Settings -> List Settings, and then click “Save list as template” under the Permissions and Management heading. SharePoint displays the Save as Template page.
Enter the settings in Table 4-5 and click OK. SharePoint saves the list as a template and adds it to the site collection’s list template gallery.
Click Site Actions -> Create, and then click Problem Report Sample 1.0 beneath the Tracking heading to create a test list based on the template.
List templates are saved at site collection level. That means the ProblemReport10 template is available to all sites in the site collection. Deploying a list template is very similar to deploying a site template. To deploy the template to another site collection:
Navigate to the top-level site in the source site collection.
Click Site Actions -> Site Settings, and click “List templates” under the Galleries heading. (In MOSS, click Actions -> Site Settings -> Modify All Site Settings.) SharePoint displays the List Template Gallery.
Click the ProblemReport10 link in the gallery. SharePoint asks if you want to save the file.
Click Save to download the template. Be sure to store it in your Templates folder on your computer to stay organized.
Navigate to the site collection where you want to install the template and repeat step 1 to display the List Template Gallery for that site collection.
Click Upload on the gallery toolbar and upload the file you created in step 3. SharePoint copies the file into the List Template Gallery.
Lists that include Lookup columns will have problems when used in other site collections since the source list for the lookup won’t exist in the new location. Avoid Lookup columns when creating lists for reuse as list templates. The exceptions to that rule are when the list template is reused within the current site or when the lookup is a site column and the template is reused within the current site collection.
Best Practices
Create a gallery containing sample lists created from the built-in list templates and any general-purpose custom list templates you create.
Use Lookup columns to link lists together and to provide drill-down.
Lookups link lists together. Site columns span site boundaries. You combine them to create master lists that cross site boundaries.
Use calculated columns to create alert dates within lists. You can then filter on those dates to create views that highlight items before they are overdue.
Create a style guide for creating list views. This will help views have a more consistent appearance across sites and save users a lot of time trying out different settings.
Avoid Lookup columns when creating lists for reuse as list templates.
Restrict permissions as you go deeper into the site hierarchy. Permissions should follow the physical structure.
Create a custom default view to display feedback to users after they submit new items.
Use a client-side web part to display a conditional message confirming new items.