One of the cool new features of WSS 3.0 is item-level permissions, and a variation of that capability is carried forward in the "only their own" security setting.
In most WSS lists, it's possible to set the list security so that users have access to "only their own" items: each individual may add items to lists and will only be able to view and edit the content that he or she has created.
This feature can be found by visiting the List Settings for a list, then clicking on the Advanced Settings link.
I used this feature recently on a project where the intent for data within a WSS site was not for collaboration, but for a standardized approach to a business problem and easy portability between users (sometimes the data needs to transfer owners).
I was amazed, then, when I went to a document library looking for this same setting, and couldn't find it anywhere. I googled and dug around, but felt sure that I was just missing the setting somewhere.
Alas, I was not just missing something.
Burt came to my rescue with this explanation:
...if you look at the OM for WSS you’ll note that there is an SPDocumentLibrary class, an SPIssuesList class and an SPList class for all other list types. Also all three classes have getters and setters for the two properties ReadSecurity and WriteSecurity, the properties you set in the UI using the radio buttons. (So programmatically, you can set these if you need to do so.)
OK, so how is it behaving? Here is the relevant code from the page advsetng.aspx, the page called when the Advanced Settings link is clicked:
<!-- Security Settings -->
<asp:PlaceHolder runat="server" id="ItemLevelSecurityPanel">
<wssuc:InputFormSection runat="server">
Note the id of the placeholder.
And here is the code in the Microsoft.SharePoint.ApplicationPages.dll for the AdvancedSettingsPage class’s OnLoad event:
this.ItemLevelSecurityPanel.Visible = (type != 1) && (type != 5);
Where type is the base type of the list. (1=doclib, 5=issues).
So Microsoft went to some effort to explicitly exclude this from the UI (but not the object model) for document libraries and issue lists within WSS. I trust the WSS team's approach from a UI perspective, but I'm glad there's also a way around it. :-)
Here was my solution:
First, I took a look at MSDN's documentation for the
ReadSecurity and
WriteSecurity properties; unlike some of the WSS SDK, these items actually show the possible values and the meaning of each.
After that, I created a simple command-line utility that runs on the WSS server and allows properties to be set on lists that may or may not be available through the user interface.
The syntax of the utility is:
SPSetListProperty <Site URL> <Web URL> <List Name> <Property to Set> <Value for Property>
So to achieve the "only their own" functionality, the usage is something like this:
SPSetListProperty "http://mywssbox" "/TeamSite" "My Documents" "ReadSecurity" "2"
SPSetListProperty "http://mywssbox" "/TeamSite" "My Documents" "WriteSecurity" "2"
The commands need only be executed once to configure the list.
You can download the utility
here, and
view the code, if you want. (Disclaimer: this was quick and dirty code and not intended to be exemplary; feel free to improve it in your version...)
UPDATE 5/4/2007:
Krishnan makes a good point in the comments below. The "only their own" settings control the user interface, but are not truly item level permissions. (Burt reminded me of this misnomer as well.)
When opening the list using WebDAV (and via the API I assume, though I did not test this), the documents from other users ARE visible and available to copy, edit, etc.
Another way of saying it is that this is not a replacement for the true item-level permissions that WSS supports. When true item-level permissions are specified, WebDAV and the API do enforce the specified security.
Thanks for the heads-up, Krishnan.