Note
This post originally appeared on my MSDN blog:
Since
I no longer work for Microsoft, I have copied it here in case that blog
ever goes away.
For a couple of months now, I have been using the following command to add myself
to a Microsoft Office SharePoint Server (MOSS) 2007 site restored from a different
server:
This site is backed up from our Test environment (where the business users specify
the data) which happens to reside in a different domain. Consequently when the site
is restored, even the user restoring the site does not have permission to access
the site (that is, until running the above command).
Earlier today, I was helping another developer on our team debug a permissions
problem and we wanted to grant read-only access on the site to everyone.
I initially suggested the following command:
However, we quickly discovered that "Read" wasn't quite right. After spending
no less than 10 minutes unsuccessfully trying variations -- such as "Read-only"
and "read only" -- and searching the Web for the documented list of available policies,
I ended up telling my colleague to just "punt" and use the UI instead.
Revisiting the issue a few hours later, I just spent a couple of minutes cranking
out a console application to help me understand the available options for the
permissionlevel parameter:
static void Main(string[] args)
{
Uri siteUrl = new Uri("http://foobar/sites/Migration");
SPWebApplication application = SPWebApplication.Lookup(siteUrl);
foreach (SPPolicyRole policyRole in application.PolicyRoles)
{
Console.WriteLine(policyRole.Name);
}
}
The output is as follows:
Full Control
Full Read
Deny Write
Deny All
Therefore the command that I should have suggested to my colleague is: