Skip to content

September 12, 2005

Preventing users from using the UI to manage web parts

There has been a fair amount of talk lately about how any web part page in SharePoint — including many pages like list pages that people don’t think are web part pages — can have the web parts manipulated by simply adding parameters to the query string.  Those parameters cause the ToolPartPane to appear even if there was no administrative control on the page to cause it to appear.

This is true of the existing pages, but you can create your own site definition that doesn’t allow users to use the user interface to modify the web part placement or even add new items to the web part zone.  The WebPartZone class (and consequently the WebPartZone tag) support three interesting attributes/properties…

  • AllowCustomization – Indicates whether customization is allowed or not.
  • AllowPersonalization – Indicates whether personalization is allowed or not
  • LockLayout – Indicates whether the layout of the zone is fixed — and can not be edited.

Quick testing shows that AllowCustomization must be set to true and LockLayout must be set to false for SharePoint to even show the web part zone in design mode.  Further investigation has shown that using the web services calls to modify web parts in the web part zone still seems to work — and editing the page in front page including web part placement still seems to work as well.  In other words, it’s possible to prevent users from modifying web parts in special zones, like navigation, while retaining the ability to control web parts in these special zones via code.

Folder Taxonomy, Path Limitations, and Meta Data

I was searching out some things and ran across an old blog entry from Bil Simser talking about the limitations of using folders because of path length limitations.  Here are a few observations from a recent client experience.

1) The path limitation is indeed 255 (or 256 characters).  It’s documented in some of the planning documents (and in a KB article as well if memory serves.)

2) The idea of using meta data to categorize information instead of folders has at least two limitations …

a) WebDAV doesn’t natively support the assignment of meta-data during a save operation.  Therefore saving with applications which are not fully SharePoint aware is a bad experience.  The documents end up in the “root” of the view since they have no data to categorize them.

b) Retreiving files without context from a SharePoint document library can be very difficult without the property information.  Since the WebDAV File-Open dialog doesn’t understand the meta data it can be frustrating to find the right document to email to someone when the file name doesn’t contain all of the useful information.  One solution around this particular problem is to use the free Outlook Power Tool for SharePoint from Winapp Technology.  Of course, that doesn’t solve the problem when you’re trying to use a file from another application.

In general… Use meta data if you need the ability to reorganize the data in multiple hierarchies.  Use folders to make it easy to use within non-SharePoint enabled applications.

As a sidebar, the experience on SharePoint with WebDAV is much better in Windows XP vs. Windows 2000.  Every application I’ve tested has been able to save to SharePoint via WebDAV in Windows XP.  The same applications have trouble with Windows 2000’s support for WebDAV.  XP also allows files to be dragged from one WebDAV folder to another where Windows 2000 does not.

Recent Posts

Public Speaking