Sharepoint: July 2011

Sunday 31 July 2011

Browser compatability Allignment

For safari

@media screen and (-webkit-min-device-pixel-ratio:0)

{

}

Ie 7

Ie 8:

\0/ !important;

Wednesday 27 July 2011

Receiving Page details

Guid currentSiteGuid = SPContext.Current.Site.ID;
using (SPSite site = new SPSite(currentSiteGuid))
{
using (SPWeb web = site.OpenWeb())
{
web.AllowUnsafeUpdates
PublishingWeb publishingWeb = PublishingWeb.GetPublishingWeb(web);
PublishingPageCollection pages = publishingWeb.GetPublishingPages();
foreach (PublishingPage page in pages)
     {

      SPFile file = web.GetFile(web.Url + "/" + page.Url);
       file.CheckOut();
      if (page.Name == "AdministratorInformation.aspx")
       {
         page.Title = "Administrator Information";
         page.Update();

        }
       else if (page.Name == "AdministratorPage.aspx")
       {
          page.Title = "Administrator Page";
          page.Update();
        }
  else
         {
            page.Title = "";
         }

         file.CheckIn("pagename");
         file.Publish("Publish");
        file.Approve("Approve");
        file.Update();
        //Including Pages in current Navigation
        publishingWeb.IncludeInNavigation(true, page.ListItem.UniqueId);
        publishingWeb.ExcludeFromNavigation(true, page.ListItem.UniqueId);
      }
      publishingWeb.Update();
       web.Update();
       web.AllowUnsafeUpdates = false;
}
}

Receiving datas from MasterPage gallary

Guid currentSiteGuid = SPContext.Current.Site.ID;
using (SPSite site = new SPSite(currentSiteGuid))
{
using (SPWeb web = site.OpenWeb())
{
SPQuery query = new SPQuery();
query.Query = "<Where><Eq><FieldRef Name='FileLeafRef' /><Value Type='Text'>Insidedefault.master</Value></Eq></Where>";
Microsoft.SharePoint.SPList gallery1 = site.GetCatalog(Microsoft.SharePoint.SPListTemplateType.MasterPageCatalog);
SPListItemCollection col = gallery1.GetItems(query);
if (col.Count > 0)
{
foreach (SPListItem item in col)
{
//web.AllowUnsafeUpdates = true;
item.Web.AllowUnsafeUpdates = true;
item.File.CheckOut();
item.File.CheckIn("check in");
item.File.Publish("publish");
item.File.Approve("dsf");
web.Update();
// item.Web.AllowUnsafeUpdates = true;
//web.AllowUnsafeUpdates = false;
}
}
}
}

13.SharePoint 2007 Deployment: Using Resources in Features

Why should I use Resources?

In my opinion, you should always use resource files for your features. Why?

First, because it’s easy to do even if you only have one language.
Second, because if you do, all the objects you are provisioning in SharePoint will be localized and will be displayed in the correct language of the website (provided you have deployed the resource file for that language).

Examples of things that should be placed in resource files:

Title and Description of you feature, so that they will be displayed in the language of the website;
Site column display name and description;
Content type name and description;
List template name and description;
List instance title and description;
Custom action title and description.

How do I use it?

There are three steps to use resources in a feature:

Build the resource (.resx) files;
Place the resource files in the correct folder;
Use the resource strings in the feature manifest and element manifests.

Note: The next sections show how to use feature-specific resources. I’ll briefly discuss shared resources in the end of the post.

Building the resource (.resx) files

The best way to build the resource files is using Visual Studio 2008, but you can do it manually on any text editor since they’re just XML text files.

<?xml version="1.0" encoding="utf-8"?>
<root>
  <resheader name="resmimetype">
    <value>text/microsoft-resx</value>
  </resheader>
  <resheader name="version">
    <value>2.0</value>
  </resheader>
  <resheader name="reader">
    <value>
      System.Resources.ResXResourceReader, 
      System.Windows.Forms, 
      Version=2.0.0.0, 
      Culture=neutral, 
      PublicKeyToken=b77a5c561934e089
    </value>
  </resheader>
  <resheader name="writer">
    <value>
      System.Resources.ResXResourceWriter, 
      System.Windows.Forms, 
      Version=2.0.0.0, 
      Culture=neutral, 
      PublicKeyToken=b77a5c561934e089
    </value>
  </resheader>
  <data name="MyFeatureName" xml:space="preserve">
    <value>My Feature Name</value>
  </data>
  <data name="MyFieldDisplayName" xml:space="preserve">
    <value>My Field Display Name</value>
  </data>
  <data name="MyFieldChoice1" xml:space="preserve">
    <value>My Choice 1</value>
  </data>
  <data name="MyFieldChoice2" xml:space="preserve">
    <value>My Choice 2</value>
  </data>
</root>

See above an example of a resource (.resx) file. The <data> elements are the ones that hold the localized strings:

The name attribute is the key used to retrieve the localized string;
The <value> child element is the localized string itself.

Each language must have its own resource file which follows a specific naming convention:

The main resource file must be called Resources.resx. This is the culture neutral resource file (or fall back resource file) which will be used by SharePoint whenever there is no resource file for a specific culture.
All culture specific resource files must be named Resources.[culture].resx. Some examples:
- Resources.en-US.resx (english – United States)
- Resources.pt-PT.resx (portuguese – Portugal)
- Resources.fr-FR.resx (french – France)
- Resources.pt-BR.resx (portuguese – Brazil)

Placing the resource files in the correct folder

These files must be placed in a Resources folder inside your feature’s folder. So, if your feature’s folder is C:\…\12\TEMPLATE\FEATURES\MyFeature, the resource files need to be placed in the folder C:\…\12\TEMPLATE\FEATURES\MyFeature\Resources.

Resources and the Feature Manifest

After you have created the resource files and placed the in the correct folder, you can now used them in your feature manifest (feature.xml).

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="$Resources:MyFeatureName"
         Scope="Site"
         Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="SiteColumns.xml"/>
    <ElementFile Location="Resources\Resources.resx" />
    <ElementFile Location="Resources\Resources.pt-PT.resx" />
    <ElementFile Location="Resources\Resources.es-ES.resx" />
  </ElementManifests>
</Feature>

The sample above, shows a feature manifest that uses resources to specify the feature title. As you can see, the value of the Title attribute is $Resources:MyFeatureName. This tells SharePoint that it should check the resource file for the current website’s culture and retrieve the string that has the key MyFeatureName.
Notice the use of <ElementFile> elements to reference the resource files in the feature. This is required if you are deploying this feature through a solution package (.wsp).
Important: because we are using feature-specific resource files (resource files that are only used for this specific feature), you cannot use the DefaultResourceFile attribute on the <Feature> element. If you do, SharePoint will not look for resource files in the local Resources folder for this feature.

Resources and the Element Manifest

Besides using localized strings to specify the feature title and description, you can (and should) use localized strings for most feature elements.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Field Type="Choice"
         DisplayName="$Resources:MyFieldDisplayName"
         Required="FALSE"
         Format="Dropdown"
         FillInChoice="FALSE"
         ID="{485b2176-4cfc-4923-8085-c003b85dab36}"
         StaticName="MyField"
         Name="MyField">
    <Default>$Resources:MyFieldChoice1</Default>
    <CHOICES>
      <CHOICE>$Resources:MyFieldChoice1</CHOICE>
      <CHOICE>$Resources:MyFieldChoice2</CHOICE>
    </CHOICES>
  </Field>
 </Elements>

The sample above specifies a choice field, and uses localized strings for:

Field display name
Each of the field’s choices
The field’s default choice

The theory is exactly the same as it was used for the feature manifest: you use the expression $Resources:[key] whenever you want SharePoint to retrieve a localized string from the resource file of the current website’s culture.

Shared Resource Files

The method shown in the previous sections assumed that each feature has its own resource files. However, that is not always the case and SharePoint itself uses shared resource files. That is, resource files that can be shared by multiple features.
There are only two differences when using shared resource files:

The folder where the resource files are placed;
The way you reference the localized string in you feature manifest and element manifests.

Other than that, the file format and contents can be exactly the same.

Folder for Shared Resources

Shared resource files must be placed in the folder C:\…\12\Resources instead of the local Resources folder inside the feature folder.

Referencing Shared Resources

Because the shared resources files can have any name you want, you must reference the localized strings in a more specific way, so as to tell SharePoint which resource file holds a particular string.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="$Resources:MyResources,MyFeatureName"
         Scope="Site"
         Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="SiteColumns.xml"/>
  </ElementManifests>
</Feature>

As you can see in the above sample, instead of $Resources:MyFeatureName I’m referencing the localized string with $Resources:MyResources,MyFeatureName. This tells SharePoint to look for:

A localized string whose key is MyFeatureName
In a resource file named MyResources.[Culture].resx
In the C:\…\12\Resources folder

If all your strings are in the same shared resource file, then you can specify that file as the default resource file and reference the strings as shown in the first sample.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="$Resources:MyFeatureName"
         DefaultResourceFile="MyResources"
         Scope="Site"
         Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="SiteColumns.xml"/>
  </ElementManifests>
</Feature>

The sample above does exactly the same as the previous one. The only difference is that it specifies MyResources.[culture].resx as the default resource file and, because of that, you don’t need to specify it on all references to the localized strings.

Additional Notes

So, how does SharePoint choose which resource file to use when loading the localized strings?

Looks for the resource file of the exact culture of the website. If you have a website based on a portuguese (pt-PT) site template, it will look for the Resources.pt-PT.resx. If it’s there, it loads all the strings from it.
If it’s not there, it looks for any resource files of the same culture, even if it has a different location. So if your website’s language is pt-PT (Portuguese – Portugal) and you don’t have a Resources.pt-PT.resx file, but you have a Resources.pt-BR.resx (Portuguese – Brazil) file, then SharePoint will use it.
If there is no resource file for the website’s culture, SharePoint will use the fall back resource file (Resources.resx).

Samples

You can download samples for:

These samples include:

The solution manifest file (manifest.xml).
The solution cab structure file (solution.ddf).
The feature manifest file (Feature.xml).
The element manifest file (SiteColumns.xml).
The resource files (.resx)
A batch file (build.bat) that creates the solution package

Warning: Do not install both solutions in the same farm, since some of the IDs are the same and the feature has the same name on both solutions. If you want to use it as is, test each solution separately, removing one before installing the other.

12.SharePoint 2007 Deployment: Feature Stapling

Feature Stapling

Feature stapling is the process of associating features to existing site definitions so that, when a new site is provisioned from that definition the associated features are automatically activated.
This means that you need, at least, two features to do this:

The feature (or features) you wish to associate (that is, to staple) to a site definition;
The feature that performs the association (the stapler).

The first one can be any feature with scope Site or Web. The second is the one I’m presenting in this post.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with feature site template association elements can be deployed to Site Collection, Web Application or Farm scopes.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
    xmlns="http://schemas.microsoft.com/sharepoint/"
    Id="{8213A053-46B0-43f9-B00C-B2A8CF7A3355}"
    Title="My Feature Stapling"
    Description="This feature staples other features to a
    site definition."
    Scope="Farm"
    Creator="Create IT"
    Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="Elements.xml"/>
  </ElementManifests>
</Feature>

Notes about this feature manifest:

The title of the feature is My Feature Stapling.
It will be deployed as a Farm feature, since it's Scope value is Farm. By default, SharePoint automatically activates features of this scope. You can, however, override this behaviour by setting the ActivateOnDefault attribute to false on the Feature element.
It references a single element manifest file: Elements.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called Elements.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <FeatureSiteTemplateAssociation> element which is used to associate features to existing site definitions.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!-- My Site Columns -->
  <FeatureSiteTemplateAssociation 
    Id="{CC3144A5-E055-4474-928E-5D21CDE53D38}" 
    TemplateName="STS#0" />
  <!-- My Content Types -->
  <FeatureSiteTemplateAssociation 
    Id="{E739683D-ACB8-4187-A764-1323BE76D12D}" 
    TemplateName="STS#0" />
</Elements>

This example associates two features with the Team Site definition. The <FeatureSiteTemplateAssociation> element has no child elements and only two attributes:

Id - (required) The GUID of the feature that is to be stapled to the site definition.
TemplateName - (required) The name of the site definition including the configuration Id. For SharePoint’s out-of-the-box site definitions, this attribute can be:
- STS#0 (Team Site)
- STS#1 (Blank Site)
- STS#2 (Document Workspace)
- MPS#0 (Basic Meeting Workspace)
- MPS#1 (Blank Meeting Workspace)
- MPS#2 (Decision Meeting Workspace)
- MPS#3 (Social Meeting Workspace)
- MPS#4 (Multipage Meeting Workspace)
- CENTRALADMIN#0 (Central Administration)
- WIKI#0 (Wiki Site)
- BLOG#0 (Blog Site)
- BDR#0 (Document Center)
- OFFILE#1 (Records Center)
- SPSMSITEHOST#0 (My Site Host)
- SPSMSITE#0 (Personalization Site)
- CMSPUBLISHING#0 (Publishing Site)
- BLANKINTERNET#2 (Publishing Site with Workflow)
- BLANKINTERNETCONTAINER#0 (Publishing Portal)
- SPSPORTAL#0 (Collaboration Portal)
- SPSNHOME#0 (News Site)
- SPSITES#0 (Site Directory)
- SPSREPORTCENTER#0 (Report Center)
- SRCHCEN#0 (Search Center with Tabs)
- SRCHCENTERLITE#0 (Search Center)

There can be other site definitions depending on which site templates you have installed on your farm. The best way to check which ones you can use is to go to the folder C:\…\12\TEMPLATE\[LCID]\XML where [LCID] represent the Language ID of the site definition you are looking for, and open each webtemp*.xml file.
Each of these files will have the following structure:

<?xml version="1.0" encoding="utf-8"?>
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<Templates xmlns:ows="Microsoft SharePoint">
  <Template Name="STS" ID="1">
    <Configuration ID="0" 
                   Title="Team Site" 
                   Hidden="FALSE" 
                   ImageUrl="/_layouts/images/stsprev.png" 
                   Description="A site for teams to quickly […] 
                   DisplayCategory="Collaboration" >          
    </Configuration>
    <Configuration ID="1" 
                   Title="Blank Site" 
                   Hidden="FALSE" 
                   ImageUrl="/_layouts/images/blankprev.png" 
                   Description="A blank site for you to […] 
                   DisplayCategory="Collaboration" 
                   AllowGlobalFeatureAssociations="False" >      
    </Configuration>
    <Configuration ID="2" 
                   Title="Document Workspace" 
                   Hidden="FALSE" 
                   ImageUrl="/_layouts/images/dwsprev.png" 
                   Description="A site for colleagues to work[…] 
                   DisplayCategory="Collaboration" >          
    </Configuration>
    [...]
  </Template>
</Templates>

In the sample above you can see the description of the three configurations of the STS site template. To build the TemplateName required for the feature site template association, you get the template name (attribute Name of the element Template), which in this case is STS, add a hash sign (#) and complete the string with the configuration ID (attribute ID of the element Configuration), which in this case can be 0, 1 or 2, depending on the chosen configuration.

Sample

You can download this sample here. This sample includes:

The solution manifest file (manifest.xml).
The solution cab structure file (solution.ddf).
The feature manifest file (Feature.xml).
The feature site template association element manifest file (Elements.xml).
A batch file (build.bat) that creates the solution package (MyFeatureStapling.wsp).

11.SharePoint 2007 Deployment: Content Type Binding Features

As mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

The feature manifest file (which must be named feature.xml)
One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the binding of content types.
You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Content Type Binding

When you provision a list through a feature, using the method explained in the post SharePoint 2007 Deployment: List Template Features, you can bind a content type to it only by editing the schema.xml file of the list template.
However, if the list was provisioned through a site definition (onet.xml file) and you had no access to its definition, you must do it using a Content Type Binding feature element. This can only be used to attach a content type to a list provisioned through a site definition.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with content type binding elements can only be deployed to a Site Collection scope.
Attempting to install a feature of another scope that contains content type binding elements, will result in an error.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
    xmlns="http://schemas.microsoft.com/sharepoint/"
    Id="{ACDECF85-BDF7-446c-AC1B-C5F133C83F15}"
    Title="Content Type Binding"
    Description="This feature binds a content type to the masterpagegallery."
    Scope="Site"
    Creator="Create IT"
    Version="1.0.0.0">
  
  <ElementManifests>
    <ElementManifest Location="ContentTypeBinding.xml"/>
  </ElementManifests>
</Feature>

Notes about this feature manifest:

The title of the feature is Content Type Binding.
It will be deployed as a Site Collection feature, since it's Scope value is Site.
It references a single element manifest file: ContentTypeBinding.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called ContentTypeBinding.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <ContentTypeBinding> element which is used to binding Content Types to list definitions.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentTypeBinding
    ContentTypeId="0x010101"
    ListUrl="_catalogs/masterpage" />
</Elements>

This example binds the content type Form (which has the ID 0x010101) to the master page gallery (which has the URL _catalogs/masterpage). There <ContentTypeBinding> element has no child elements, and only two attributes:

ContentTypeId - (required) The ID of the content type that will be bound to a list.
ListUrl – (required) The URL of the list to which the content type will be bound.

Additional Notes

The content type will be bound to the list definition as soon as the administrator activates this feature on a site collection. However, deactivating the feature will not remove the connection between the content type and the list. If you wish to remove it, you must do so manually.

Sample

You can download this sample here. This sample includes:

The solution manifest file (manifest.xml).
The solution cab structure file (solution.ddf).
The feature manifest file (feature.xml).
The content type binding element manifest file (ContentTypeBinding.xml).
A batch file (build.bat) that creates the solution package (ContentTypeBinding.wsp).

10.SharePoint 2007 Deployment: Event Registration Features

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

The feature manifest file (which must be named feature.xml)
One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the registration of event receivers.
Additionally, you must include the assembly that contains the event receiver class in the solution package, so that it gets deployed to the Global Assembly Cache. Follow the instructions in the post SharePoint 2007 Deployment: Creating Solutions on how to package these three files (both manifests plus the assembly file) on a SharePoint Solution file.

Events Receivers

SharePoint allows you to handle several events that are fired according to actions performed on items, lists and web sites. Event are handled through event receivers, which are classes that implement a method for each event that is handled.
Once an event receiver is developed, compiled into an assembly and deployed to the GAC, it must be registered to a content type, a list or a web site in order to handle its events. That can be done through the API (or third-party tool such as Event Handler Explorer) or, concerning item and list event receivers, through this type of feature.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with event registration elements can only be deployed to Web Site scopes.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
    xmlns="http://schemas.microsoft.com/sharepoint/"
    Id="{282902FB-0369-4f98-93C5-7FD7121CE164}"
    Title="My Event Receiver"
    Description="This feature registers My Event Receiver."
    Scope="Web"
    Creator="Create IT"
    Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="EventReceivers.xml"/>
  </ElementManifests>
</Feature>

Notes about this feature manifest:

The title of the feature is My Event Receiver.
It will be deployed as a Web Site feature, since it's Scope value is Web.
It references a single element manifest file: EventReceivers.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called EventReceivers.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <Receivers> element which is used to register event receivers that will handle list events.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Receivers 
    ListTemplateId="3500" 
    ListTemplateOwner="{11663D54-6152-4532-ABF5-FC08FAC216A7}">
    <Receiver>
      <Assembly>
        MyEventReceiver, 
        Version=1.0.0.0, 
        Culture=Neutral, 
        PublicKeyToken=6c0c7604915f786e
      </Assembly>
      <Class>MyEventReceiver.MyEventReceiver</Class>
      <Name>My Event Receiver</Name>
      <Type>ItemAdded</Type>
      <SequenceNumber>10000</SequenceNumber>
    </Receiver>
  </Receivers>
</Elements>

The example above registers an event receiver to all lists based on list template with ID 3500 that was deployed by a feature with the ID {11663D54-6152-4532-ABF5-FC08FAC216A7}. The receiver is the MyEventReceiver.MyEventReceiver class included in the assembly MyEventReceiver.dll that is installed in the GAC, and it handles the ItemAdded event on these lists.
The Receivers Element
The <Receivers> element is used to specify the list template to which the event receiver will be registered. There can be any number of <Receivers> elements in a single element manifest file. Here is a summary of the possible attributes of this element:

ListTemplateId - (required) Specifies the ID of the list template to which the event receiver will be registered. If you wish to register an event receiver to one of SharePoint’s list templates, you can use one of the following values:
- 100 – Generic List
- 101 – Document Library
- 102 – Survey
- 103 – Links List
- 104 – Announcements List
- 105 – Contacts List
- 106 – Events List
- 107 – Tasks List
- 108 – Discussion Board
- 109 – Picture Library
- 110 – Data Sources
- 111 – Site Template Gallery
- 112 – User Information List
- 113 – Web Part Gallery
- 114 – List Template Gallery
- 115 – XML Form Library
- 116 – Master Pages Gallery
- 117 – No-Code Workflows
- 118 – Custom Workflow Process
- 119 – Wiki Page Library
- 120 – Custom grid for a list
- 130 – Data Connection Library
- 140 – Workflow History
- 150 – Gantt Tasks List
- 200 – Meeting Workspace Series List
- 201 – Meeting Workspace Agenda List
- 202 – Meeting Workspace Attendees List
- 204 – Meeting Workspace Decisions List
- 207 – Meeting Workspace Objectives List
- 210 – Meeting Workspace text box
- 211 – Meeting Workspace Things To Bring List
- 212 – Meeting Workspace Pages List
- 301 – Blog Posts List
- 302 – Blog Comments List
- 303 – Blog Categories List
- 1100 – Issue Tracking
- 1200 – Administrator Tasks List
ListTemplateOwner - (optional) Specifies the GUID of the Feature where the list template is defined, or the name of the site definition that registered the list.

The Receiver Element
The <Receiver> element specifies which class implements the event receiver and which list event it handles. There can any number <Receiver> child elements inside a <Receivers> parent element. This element has no attributes, but has six child elements, which are listed below:

Assembly – The strong name of the assembly that contains the event receiver class. The strong name is composed of the name of the assembly (without the .dll extension), followed by a comma and the assembly version, followed by a comma and the assembly culture, followed by a comma and the assembly’s public key token.
Class – The name of the class (including the namespace) that contains the implementation of the event receiver.
Name – The name of the event receiver. This value is used to identify it if you wish to retrieve it through the API.
Type – The event that the event receiver handles. Possible values are:
- ContextEvent – The list received a context event.
- EmailReceived – The list received an e-mail message.
- FieldAdded – A field was added to the list.
- FieldAdding – A field is being added to the list.
- FieldDeleted – A field was removed from the list.
- FieldDeleting – A field is being removed from the list.
- FieldUpdated – A field was updated in the list.
- FieldUpdating – A field is being updated in the list.
- ItemAdding – An item is being added to the list.
- ItemAdded – An item was added to the list.
- ItemAttachmentAdded – An attachment was added to an item.
- ItemAttachmentAdding – An attachment is being added to an item.
- ItemAttachmentDeleted – An attachment was removed from an item.
- ItemAttachmentDeleting – An attachment is being removed from an item.
- ItemCheckedIn – An item was checked-in in the list.
- ItemCheckingIn – An item is being checked-in in the list.
- ItemCheckedOut – An item was checked-out in the list.
- ItemCheckingOut – An item is being checked-out in the list.
- ItemDeleted – An item was removed from the list.
- ItemDeleting – An item is being removed from the list.
- ItemFileConverted – A file was converted.
- ItemFileMoved – A file was moved.
- ItemFileMoving – A file is being moved.
- ItemUncheckedOut – An item was unchecked-out in the list.
- ItemUncheckingOut – An item is being unchecked-out in the list.
- ItemUpdated – An item was updated in the list.
- ItemUpdating – An item is being updated in the list.
SequenceNumber – Specifies the order of the event receiver when more than one handler is associated with the same event. A high sequence number (10000 or higher) should be used to prevent problems with SharePoint’s own event handlers.
Data – Specifies a string that will be passed as a parameter to the receiver method when handling the event.

Sample

You can download this sample here. This sample includes:

The solution manifest file (manifest.xml).
The solution cab structure file (solution.ddf).
The feature manifest file (feature.xml).
The event receiver element manifest file (EventReceivers.xml).
A fake assembly (MyEventReceiver.dll) that must be replaced by your own assembly. Important: this file is not a real assembly containing an event receiver class, hence it will not work if deployed as is to your Sharepoint environment.
A batch file (build.bat) that creates the solution package (MyEventReceiver.wsp).

9.SharePoint 2007 Deployment: Module Features

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

The feature manifest file (which must be named feature.xml)
One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the provisioning of files (modules) in a SharePoint site.
You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Modules

Modules are collections of files that must be provisioned in a SharePoint web site. This type of feature element can be used to:

Add pages to a web site
Add web parts to a web site's web part gallery
Add web parts to a web part page
Add documents to a document library
Add style sheets to the a web sites style library

According to the documentation, WSS 3.0 supports provisioning a maximum of 1000 files through module feature elements (whether using a single module element with 1000 files, or 1000 module elements each with a single file).

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with module elements can be deployed to Site Collection and Web Site scopes, since they represent files that are to be placed in web sites.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
  xmlns="http://schemas.microsoft.com/sharepoint/"
  Title="My Module Feature"
  Id="17E94729-EF3E-4f43-9385-88E1201F91E0"
  Description="This feature adds files to the web site."
  Version="1.0.0.0"
  Scope="Web"
  Hidden="FALSE"
  DefaultResourceFile="core">
    <ElementManifests>
        <ElementManifest Location="Modules.xml" />
        <ElementFile Location="default.aspx" />
        <ElementFile Location="MyMasterPage.master" />
        <ElementFile Location="MyDocument.docx" />
        <ElementFile Location="MyWebPart\MyWebPart.webpart" />
        <ElementFile Location="MyStyles.css" />
    </ElementManifests>
</Feature>

Notes about this feature manifest:

The title of the feature is My Module Feature.
It will be deployed as a Web Site feature, since it's Scope value is Web.
It references a single element manifest file: Modules.xml.
It references several element file files. You must reference separately, using these elements, each file you wish to include in the module.

Element Manifest

The element manifest file can have any name you wish (in this example it's called Module.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <Module> element which is used to deploy Files to SharePoint web sites.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    
    <!-- Page Module -->
    <Module Name="Pages" Url="" Path="">
        <File Url="default.aspx" 
              NavBarHome="True" 
              IgnoreIfAlreadyExists="TRUE" 
              Type="Ghostable">

            <!-- Places Web Part on Page -->
            <AllUsersWebPart WebPartZoneID="Left" WebPartOrder="1">
                <![CDATA[
                  <webParts>
                    <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
                      <metaData>
                        <type name="MyWebPart, 
                                    MyWebPart.MyWebPart, 
                                    Version=1.0.0.0, 
                                    Culture=neutral, 
                                    PublicKeyToken=1255988569cf0248" />
                        <importErrorMessage>
                            Cannot import My Web Part.
                        </importErrorMessage>
                      </metaData>
                      <data>
                        <properties>
                          <property name="Title" type="string">
                            My Web Part
                          </property>
                        </properties>
                      </data>
                    </webPart>
                  </webParts>
                ]]>
            </AllUsersWebPart>
            
            <!-- Places a List View for a Discussion Board -->
            <View List="Lists/Discussions" 
                  BaseViewID="4" 
                  Name="Discussions" 
                  WebPartZoneID="Left" 
                  WebPartOrder="2"/>

            <!-- Places a List View for a Document Library -->
            <View List="MyDocuments" 
                  BaseViewID="10" 
                  Name="My Documents" 
                  WebPartZoneID="Left" 
                  WebPartOrder="3"/>

            <!-- Customizes Navigation -->
            <NavBarPage Name="$Resources:core,nav_Home;" 
                        ID="1002" 
                        Position="Start" />
        </File>
    </Module>
    
    <!-- Master Page Module -->
    <Module Name="Master Pages" List="116" Url="_catalogs/masterpage">
        <File Url="MyMasterPage.master" Type="GhostableInLibrary" />
    </Module>

    <!-- Document Module -->
    <Module Name="Documents" List="101" Url="MyDocuments">
        <File Url="MyDocument.docx" Type="GhostableInLibrary" />
    </Module>

    <!-- Web Part Module -->
    <Module Name="WebParts" List="113" Url="_catalogs/wp">
        <File Path="MyWebPart\MyWebPart.webpart"
              Url="MyWebPart.webpart"
              Type="GhostableInLibrary" />
    </Module>

    <!-- Style Sheet Module -->
    <Module Name="Stylesheets" List="101" Url="Style Library">
        <File Url="MyStyles.css" Type="GhostableInLibrary" />
    </Module>
</Elements>

The example above provisions five different files in a SharePoint web site:

An ASPX web page (web part page) to the root of the web site. This web page contains:
- A MyWebPart Web Part (on web part zone Left)
- A List View Web Part that shows a view of a discussion board list
- A List View Web Part that shows a view of a document library
A Master Page to the Master Page Gallery of the web site
A document to a Document Library of the web site
A web part to the Web Part Gallery of the web site
A style sheet to the Style Library of the web site

The Module Element
The <Module> element is used to specify a Module. There can be any number of modules in a single element manifest. Here is a summary of the possible attributes of this element:

IncludeFolders - (optional) I could figure out what this attribute is for...
List - (optional) Type of list where the files included in this module should be provisioned (check the possible values on my post about List Template Features).
Name - (required) Name of the module (file set).
Path - (optional) Specifies the physical path of the files, inside the feature folder (C:\Program Files\...\12\TEMPLATE\FEATURES\[feature]). By default, SharePoint assumes the files are in the same folder as the element manifest file. You can also specify the path on each <File> element (see below).
RootWebOnly - (optional) Boolean value. If TRUE it specifies that the files in this module will only be provisioned on the root web site of a site collection.
SetupPath - (optional) Specifies the physical path to a folder, inside SharePoint's setup folder (C:\Program Files\...\12\TEMPLATE), that contains the files included in the module.
Url - (optional) Specifies the virtual path of the folder in which to place the files of the module. This attribute is also used to provision a folder inside a list. If the Path is not specified, the value of this attribute will be used for the physical path also.

The File Element
The <File> element is used to specify a file inside a module. There can be any number of <File> elements inside a <Module> element. See below a list of the possible attributes of this element:

IgnoreIfAlreadyExists - (optional) Boolean value. If TRUE it specifies that the file should be provisioned even if it already exists on the destination URL.
Name - (optional) Specifies the virtual path for the file.
NavBarHome - (optional) Boolean value. If TRUE it specifies that the file will be the destination of the Home link, used in the web site's navigation. This attribute is only used for web pages.
Path - (optional) Physical path to the file, inside the feature folder (C:\Program Files\...\12\TEMPLATE\FEATURES\[feature]). This attribute is used if you need to specify a different path for each file inside the module. Otherwise, you can use the Path attribute on the Module element.
Type - (optional) Specifies if the file is to be stored in a Document Library (in this case the value should be GhostableInLibrary) or outside of a list (in this case the value should be Ghostable).
Url - (required) Specifies the virtual path for the file. If Name is specified, then the value of this attribute is ignored. However, if Path is not specified, the value of this attribute will be used for the physical path.

The AllUsersWebPart Element
The <AllUsersWebPart> element is used when you want to add a generic web part (non-List View web part) to a web part page. It can only be used inside a <File> element that provisions a web part page file. It has only two attributes:

WebPartOrder - (required) Specifies the vertical position of the web part inside a web part zone.
WebPartZoneID - (required) Specifies the name of the web part zone.

Inside this element, you can place a CDATA element with the web part's XML description, either using the DWP file schema (also called V2) or the WEBPART file schema (also called V3).
The View Element
The <View> element is used when you want to add a List View Web Part to a web part page. It can only be used inside a <File> element that provisions a web part page file. It has a lot of possible attributes, but I will only list the most common:

List - (optional) Specifies either the template type of the list (an integer value) or the URL of a list provisioned in the web site (a string value). On most cases, you should use the URL, since there might be two lists of the same type on the web site.
BaseViewID - (optional) Specifies the ID of the list view to be used.
Name - (optional) Specifies the name of the view.
WebPartOrder - (required) Specifies the vertical position of the web part inside a web part zone.
WebPartZoneID - (required) Specifies the name of the web part zone.

The NavBarPage Element
The <NavBarPage> element is used to define how the navigation items should be created so that other pages link to this one. It can only be used inside a <File> element that provisions a web page file. It has three attributes:

ID - (required) Specifies the ID for the page. This ID will be used by other pages when defining the relative position of the navigation items.
Name - (required) Specifies the text that is displayed in the navigation area of other pages that link to this one.
Position - (optional) Specifies the position of the navigation item on the navigation area of other pages that link to this one. This attribute can have the following possible values:
- Start - Add the node to the start of the top navigation area.
- End - Add the node to the end of the top navigation area.
- Number between 1001 and 2000 - Add the node after another NavBarPage element whose ID matches the number.

The Property Element
The <Property> element is used only inside the <File> element, to define the value of one or more properties of that file, once it is provisioned. It's mostly used to set properties of web part files or document files. It has only two attributes:

Name - (required) Name of the property to be set.
Value - (required) Value to set the property with.

Additional Notes

The files included in a module feature element are provisioned in the web site where the feature is activated. However, when the feature is deactivated, the files that belong to the module element are not removed.
You can learn a lot about modules by looking inside the onet.xml files included in each site template (look in C:\Program Files\...\12\TEMPLATE\SiteTemplates). These files include a <Modules> element which shares the same schema as the Module Features.

8.SharePoint 2007 Deployment: Custom Action Features

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

The feature manifest file (which must be named feature.xml)
One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the creation of custom actions in a SharePoint site.
You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Custom Actions

Custom actions are links, toolbar buttons and menu items that you can add to or hide from the SharePoint's user interface. Each custom action exists in a specific location, and depending on that location, can be a part of a group of actions.
With a custom action feature, you can:

Add a new Custom Action Group which can be used to group custom actions in a specific options screen;
Add a new Custom Action which can be a new option in a settings screen, a new menu item, or a new toolbar button;
Hide an existing Custom Action whether that action is the result of custom action feature or it belongs to SharePoint's out-of-the-box features.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with custom action elements can be deployed to all the scopes, that is, Farm, Web Application, Site Collection and Web Site.
The correct scope must be chosen according to the group and location of the custom action being added or hidden. Note that you can't mix feature elements with different scopes on the same feature.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="My Custom Action Feature"
         Description="Adds Custom Actions to the Web Site."
         Scope="Web"
         Version="1.0.0.0">
    <ElementManifests>
        <ElementManifest Location="CustomActions.xml"/>
    </ElementManifests>
</Feature>

Notes about this feature manifest:

The title of the feature is My Custom Actions Feature.
It will be deployed as a Web Site feature, since it's Scope value is Web.
It references a single element manifest file: CustomActions.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called CustomActions.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of three feature elements:

<CustomActionGroup> used to create new custom action groups;
<CustomAction> used to create new custom actions;
<HideCustomAction> used to hide existing actions.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <!-- Custom Action Group -->
    <CustomActionGroup
        Id="MyActionGroup"
        Description="This group contains all my custom actions."
        Title="My Action Group"
        Location="Microsoft.SharePoint.SiteSettings"
        Sequence="30" />
    <!-- Custom Action in Custom Action Group -->
    <CustomAction
        Id="MyCustomAction"
        Description="This link is a custom action."
        Title="My Custom Action"
        GroupId="MyActionGroup"
        Location="Microsoft.SharePoint.SiteSettings"
        Rights="ManageWeb"
        RequireSiteAdministrator="FALSE"
        Sequence="20">
        <UrlAction Url="~sitecollection/_layouts/MyCustomPage1.aspx" />
    </CustomAction>
    <!-- Custom Action in Site Actions Menu -->
    <CustomAction
        Id="MyNewCustomAction"
        Description="This menu item is a new custom action."
        Title="My New Custom Action"
        GroupId="SiteActions"
        Location="Microsoft.SharePoint.StandardMenu"
        ImageUrl="/_layouts/MyActionIcon.jpg"
        Sequence="10">
        <UrlAction Url="~sitecollection/_layouts/MyCustomPage2.aspx" />
    </CustomAction>
    <!-- Hide Custom Action -->
    <HideCustomAction
        Id="HideDeleteWeb"
        GroupId="SiteAdministration"
        Location="Microsoft.SharePoint.SiteSettings"
        HideActionId="DeleteWeb" />
</Elements>

The <CustomActionGroup> Element

The <CustomActionsGroup> element is used to create custom action groups that can contain custom actions. In the sample above, a new custom action group, named My Action Group, is added to the Site Settings screen.
The following attributes can be used with this element:

Id - (optional) Specifies a unique identifier for this group. It can be a GUID or a unique term, for example "SiteManagement".
Description - (optional) Description for the custom action group.
Title - (required) Title of the custom action group, shown to the user in the UI.
Location - (required) Specifies the place where the custom action group will be placed
- Microsoft.SharePoint.SiteSettings - Site Settings screen
- Microsoft.SharePoint.ContentTypeSettings - Content Type Settings screen
- Microsoft.SharePoint.Administration.Operations - Operations screen in the Central Adminstration web site
- Microsoft.SharePoint.Administration.ApplicationManagement - Application Management screen in the Central Administration
Sequence - (optional) Order of the custom action group in the list of groups that exist in the specified location.

The <CustomAction> Element

The <CustomAction> element is used to create a new custom action in the UI. In the above samples, two custom actions are created:

A custom action (named My Custom Action) in a custom action group (named My Action Group) in the Site Settings screen.
A custom action (named My New Custom Action) in an existing action group (which is the Site Actions menu).

The following attributes can be used with this element:

Id - (optional) Unique identifier to the custom action. The ID can be GUID or unique term, for example, "MyCustomAction".
Description - (optional) Description for the custom action. It will be displayed as a tooltip or sub-description for the action, depending on its location.
Title - (required) Title for the custom action.
GroupId - (optional) Specifies an action group inside which to place the custom action. If this custom action is contained inside a custom action group, the value of this attribute must match the value of the Id attribute of the <CustomActionGroup> element.
Location - (required) Specifies the location for this custom action. If this custom action is contained inside a custom action group, the value of this attribute must match the value of the Location attribute of the <CustomActionGroup> element. Check the possible values below, in the Locations and Group IDs section.
ImageUrl - (optional) Address of the image to use as the icon for this custom action. Note that, in certain locations, the custom actions don't have an icon.
Rights - (optional) Specifies a set of permissions that the user must have in order for the link to be visible. If omitted, the action always appears. To specify multiple values, separate them using commas (which means the user must have all the permissions specified). Check the possible values below, in the Action Rights section.
RequireSiteAdministrator - (optional) TRUE to specifiy that the user must be a site administrator to see the custom action. The default value is FALSE. This attribute is not supported if the custom action is to be placed in the context menu for a list item.
Sequence - (optional) Specifies the order of the custom action inside its action group.
ContentTypeId - (optional) Specifies the ID of the content type to associate with the custom action.
ShowInReadOnlyContentTypes - (optional) TRUE to specify that the action should only appear in the Manage Content Type screen, for Read Only Content Types. The default value is FALSE.
ShowInSealedContentTypes - (optional) TRUE to specify that the action should only appear in the Manage Content Type screen, for Sealed Content Types. The default value is FALSE.
ControlAssembly - (optional) Specifies the fully qualified name of the assembly of the control that supports the custom action. This attribute is used in conjunction with the next one.
ControlClass - (optional) Specifies the name of the class of the control that supports the custom action. This attribute is used in conjunction with the previous one.
ControlSrc - (optional)
RegistrationType - (optional) Used to specify the type of attachment in per-item custom actions. The possible values are:
- ContentType
- FileType
- List
- ProgId
RegistrationId - (optional) Depending on the RegistrationType value, this attribute can hold a Content Type ID, a File Type identifier, a List ID or a Program identifier.

The <UrlAction> Element

The <UrlAction> element is used inside the <CustomAction> element to specify what happens when the user clicks the link (or toolbar button, or menu item). It has a single attribute, Url, which is the address of the page to redirect the user to.
In this URL address you can use a few tokens that SharePoint will replace by the correct values when the user clicks it:

~site - relative address of the current web site.
~sitecollection - relative address of the root web site of the current site collection.
{ItemId} - ID (Integer value) of the item being acted upon (if applicable).
{ItemUrl} - URL of the item being acted upon (only works in document libraries).
{ListId} - GUID of the list.
{SiteUrl} - absolute URL of the current web site.
{RecurrenceId} - Recurrence index (not supported in the context menu of list items).

The <HideCustomAction> Element

The <HideCustomAction> element is used to hide an existing custom action.
The following attributes can be used with this element:

Id - (optional) Specifies the ID of this hide custom action element.
GroupId - (optional) Identifies an action group that contains the action.
Location - (required) Specifies the location of the custom action to hide. Check the possible values in the table below.
HideActionId - (required) Specifies the ID of the action to hide.

Locations and Group IDs

The location and group ID values identify a specific place where the custom action must be created (or hidden). See below the possible combinations for both attributes.

Description	Location	Group ID
Display form toolbar	DisplayFormToolbar	N/A
Edit form toolbar	EditFormToolbar	N/A
New form toolbar	NewFormToolbar	N/A
List view toolbar	ViewToolbar	N/A
List item context menu	EditControlBlock	N/A
New menu for list and document library view toolbars	Microsoft.SharePoint.StandardMenu	NewMenu
Actions menu for list and document library view toolbars	Microsoft.SharePoint.StandardMenu	ActionsMenu
Settings menu for list and document library view toolbars	Microsoft.SharePoint.StandardMenu	SettingsMenu
Upload documents menu for document libraries	Microsoft.SharePoint.StandardMenu	UploadMenu
Site Actions menu	Microsoft.SharePoint.StandardMenu	SiteActions
Site Settings Site Collection Administration links	Microsoft.SharePoint.SiteSettings	SiteCollectionAdmin
Site Settings Site Administration links	Microsoft.SharePoint.SiteSettings	SiteAdministration
Site Settings Galleries Links	Microsoft.SharePoint.SiteSettings	Galleries
Site Settings Look and Feel links	Microsoft.SharePoint.SiteSettings	Customization
Site Settings Users and Permissions links	Microsoft.SharePoint.SiteSettings	UsersAndPermissions
Site Actions menu for surveys	Microsoft.SharePoint.StandardMenu	ActionsMenuForSurvey
Site Settings links for surveys	Microsoft.SharePoint.SiteSettings	SettingsMenuForSurvey
Content Type Settings links	Microsoft.SharePoint.ContentTypeSettings	N/A
Central Administration Operations page	Microsoft.SharePoint.Administration.Operations	N/A
Central Administration Application Management page	Microsoft.SharePoint.Administration.ApplicationManagement	N/A

Action Rights

Each custom action has its own set of permission requirements which are defined using the Rights attribute of the <CustomAction> element. The list below summarizes the possible values for this attribute.

AddAndCustomizePages - Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Windows SharePoint Services–compatible editor.
AddDelPrivateWebParts - Add or remove personal Web Parts on a Web Part Page.
AddListItems - Add items to lists, add documents to document libraries, and add Web discussion comments.
ApplyStyleSheets - Apply a style sheet (.css file) to the Web site.
ApplyThemeAndBorder - Apply a theme or borders to the entire Web site.
ApproveItems - Approve a minor version of a list item or document.
BrowseDirectories - Enumerate files and folders in a Web site using Microsoft Office SharePoint Designer 2007 and WebDAV interfaces.
BrowseUserInfo - View information about users of the Web site.
CancelCheckout - Discard or check in a document which is checked out to another user.
CreateAlerts - Create e-mail alerts.
CreateGroups - Create a group of users that can be used anywhere within the site collection.
CreateSSCSite - Create a Web site using Self-Service Site Creation.
DeleteListItems - Delete items from a list, documents from a document library, and Web discussion comments in documents.
DeleteVersions - Delete past versions of a list item or document.
EditListItems - Edit items in lists, edit documents in document libraries, edit Web discussion comments in documents, and customize Web Part Pages in document libraries.
EditMyUserInfo - Allows a user to change his or her user information, such as adding a picture.
EmptyMask - Has no permissions on the Web site. Not available through the user interface.
EnumeratePermissions - Enumerate permissions on the Web site, list, folder, document, or list item.
FullMask - Has all permissions on the Web site. Not available through the user interface.
ManageAlerts - Manage alerts for all users of the Web site.
ManageLists - Create and delete lists, add or remove columns in a list, and add or remove public views of a list.
ManagePermissions - Create and change permission levels on the Web site and assign permissions to users and groups.
ManagePersonalViews - Create, change, and delete personal views of lists.
ManageSubwebs - Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites.
ManageWeb - Grant the ability to perform all administration tasks for the Web site as well as manage content. Activate, deactivate, or edit properties of Web site scoped Features through the object model or through the user interface (UI). When granted on the root Web site of a site collection, activate, deactivate, or edit properties of site collection scoped Features through the object model. To browse to the Site Collection Features page and activate or deactivate site collection scoped Features through the UI, you must be a site collection administrator.
Open - Allow users to open a Web site, list, or folder to access items inside that container.
OpenItems - View the source of documents with server-side file handlers.
UpdatePersonalWebParts - Update Web Parts to display personalized information.
UseClientIntegration - Use features that launch client applications; otherwise, users must work on documents locally and upload changes.
UseRemoteAPIs - Use SOAP, WebDAV, or Microsoft Office SharePoint Designer 2007 interfaces to access the Web site.
ViewFormPages - View forms, views, and application pages, and enumerate lists.
ViewListItems - View items in lists, documents in document libraries, and view Web discussion comments.
ViewPages - View pages in a Web site.
ViewUsageData - View reports on Web site usage.
ViewVersions - View past versions of a list item or document.