Email Notifications and Alerts - Sharepoint Tasks List

A few days ago I had a problem with sending emails when a new task is added to a Sharepoint tasks list. I want to make a brief introduction for you to understand the context before going on with explaining the issue:  we have a workflow that creates tasks in the default task list of a team collaboration site.  The security requirement is to give read permissions to the user assigned to the task and also to a specific sharepoint group.

 I decided to implement the security requirement as part of an event handler:

 public override void ItemAdded(SPItemEventProperties properties)

{

base.ItemAdded(properties);

this.DisableEventFiring();

 

SPWeb web = properties.OpenWeb();

SPUser user = web.SiteUsers.GetByID(Convert.ToInt32(properties.AfterProperties["AssignedTo"]));

 

if (!properties.ListItem.HasUniqueRoleAssignments)

{

        properties.ListItem.BreakRoleInheritance(false);

}

             

SPGroup group = properties.ListItem.Web.SiteGroups["My Group"];

SPRoleAssignment assignment1 = new SPRoleAssignment(group);

 

SPRoleDefinition roleDefinition = properties.ListItem.Web.RoleDefinitions["My Custom Permission Level"];

 assignment.RoleDefinitionBindings.Add(roleDefinition);

properties.ListItem.RoleAssignments.Add(assignment1);

 properties.ListItem.Update();

 SPRoleAssignment assignment2 = new SPRoleAssignment(user.LoginName, user.Email, user.Name, string.Empty);

roleAssignment.RoleDefinitionBindings.Add(roleDefinition);

 properties.ListItem.RoleAssignments.Add(assignment2);

 properties.ListItem.Update();

 this.EnableEventFiring();

}

 When testing I noticed that no email is sent after the workflow creates a new task and after our handler is called. What was very weird was that only the notification for the task creation hadn’t been sent. If you change the task the assigned person will receive the notification email.

 I had to understand the mechanism that handles email notifications: the alerts Sharepoint collaboration feature. I found a few interesting things during my tests and “google research” and I want to share this information with you before going back to our issue.

 The alerts are scoped to the site level and can be associated with lists, items or custom object. If you construct a site using a Team Collaboration site definition an alert will be created automatically and associated with the Tasks list. This happens because the E-Mail Notification option of the Tasks list is turned on (Tasks > Settings > Advanced Settings). If you select “No” the alert will be deleted.

Email Notifications and Alerts - Sharepoint Tasks List 2

 In order to see the existing alerts (including their properties) of a Sharepoint site I use Sharepoint Manager 2007. This tool uses only the Sharepoint Object Model (OM) to display the Sharepoint information and offers a good opportunity to learn a lot of things about the OM capabilities.

 The following snapshot presents the properties of the default Tasks list alert:

  Email Notifications and Alerts - Sharepoint Tasks List 1

Worth to notice that our alert is the “System” alert, it is an immediate alert, it uses a dynamic recipient to get the email addresses, it has the List type and it is associated to the Tasks list.

Dynamic recipient means that the alert binds to the AssignedTo column of the Tasks list in order to retrieve the email addresses. So only the persons assigned to the task will be able to receive email notifications.

 The immediate alerts can also be seen in the ImmedSubscriptions table of your content database.

 The alert itself doesn’t send any emails. It just writes some entries in the content database (EventCache table) and, based on that records, someone else is there to send emails. The emails are effectively sent by the Immediate Alerts timer job (Central Administration > Operations > Timer Job Definitions). There is a job for each web application and by default it is set to execute every 5 minutes. Much information about troubleshooting abnormal behavior of the timer job can be found in this post.

 The consequence observable from the end-user point of view is that there is some delay between the moment when the task is added/modified (alert logic writes in DB) and the moment when the email is received (timer job reads from DB and sends emails). In the worst case scenario you have to wait 5 minutes (by default) to see your new tasks or any changes of your existing tasks. If you want to modify the job timer scheduler you can do that with the following command:

 stsadm.exe -o setproperty -pn job-immediate-alerts -pv “every 3 minutes between 0 and 59″ –url <WebAppUrl>

 After I had understood all the mechanics of the notification process I looked for something wrong in my environment. Everything was fine so I started my research around Tasks list security. Here are the scenarios I tested and also my remarks:

 1. I left the permissions inheritance unbroken. The list didn’t have any permission for the AssignedTo user. It was clear that trimming mechanism came into play and immediate alerts job doesn’t send any email. So ensure you assign the needed level of permissions to the AssignedTo user of the task item because it is the one that will receive the email notifications.

 2. I broke the inheritance and added permissions only to the AssignedTo user. Surprise: that time was working! The task creation email notification was sent.

 3. I moved the code that creates the permissions for the user above the one that creates permissions for the group. Surprise again! It was working.

 4. I thought it might have something to do with the Update method call so I just commented out the first properties.ListItem.Update() statement in the original code of the event handler. This implementation worked as expected and it was our final solution.

 It is obvious now where the problem was but it wasn’t at the implementation time of the event handler: In the original code the first Update creates the task item that is watched by the register alert. At this moment only the Sharepoint group has assigned permissions for the task item but not the AssignedTo user. Even if you add permissions to the AssignedTo user in the next Update it is too late because the alert considers the security at the moment when the task is created. This explains why the AssignedTo user starts to receive change notification even if he didn’t receive the task creation notification.

Sharepoint 2007 SP1 - Security Exposure of Form Library

Recently we have launched a SharePoint application based on InfoPath forms. The functionality is very simple: the user creates browser-enabled InfoPath forms and an event receiver of the form library sets specific permissions. The security trimming works as expected so the forms’ owner is able to see only his forms. In production we found out that the form security behaves differently when accessing it by typing the URL in browser. It looks like the security permissions are ignored when the form item is open by typing the URL in browser.

The problem is fixed in SP2 so if you have a similar scenario as the one described above in one of your SharePoint application it will be a good idea to plan and install SP2 ;)

Deploy Data Connection Files (.udcx) to Sharepoint Data Connection Library

The following xml snippets gives you an example about how to construct a feature that will deploy a data connection file (.udcx) into a pre-created data connection document library in Sharepoint (The current sample is using only one data connection file but feel free to include as many as you need):

Feature.xml:

 <Feature
    Title=”Data Connections Feature”
    Description=” Data Connections Feature”
    Version=”1.0.0.0″
    Scope=”Site”
    Hidden=”FALSE”>
  <ElementManifests>
    <ElementManifest Location=”Elements.xml” />
    <ElementFile Location=”GetUserProfileByName.udcx” />
  </ElementManifests>
</Feature>

Elements.xml:

 <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>
  <Module Url=”MyDataConnectionsDocLibrary” RootWebOnly=”TRUE”>
    <File Url=”MyDataConnection.udcx”>
      <Property Value=”Universal Data Connection File” />
    </File>
  </Module>
</Elements>

 The only trick is to set the ContentType property of the deployed file to the “Universal Data Connection File” value because Data Connection library doesn’t have this content type set as default.

Deploy Browser-Enabled InfoPath Forms based on Content Types

I want to…

…deploy a few InfoPath forms based on content types. Some of the site columns are used across many content types. I need some level of control on the content type generation and deployment.

How…

The deployment of browser-enabled InfoPath forms using features is described in http://blah.winsmarts.com/2008-8-Deploying_InfoPath_2007_Forms_to_Forms_Server_-and-ndash_Properly.aspx post. However this post is not specific to content type based forms and it doesn’t describe how to deploy the associated content types.

Steps:

  • Create site columns and content types. (You can create this in your Sharepoint site as a manual operation). You can reuse site columns across content types.
  • Publish form with “Publishing Wizard”.
    • Select “To a SharePoint server with or without InfoPath Forms Services” and click next.
    • Select the Sharepoint site and click next.
    • Select “Site Content Type (advanced)” and click next. Note: If this option is not available you have to remove the code behind during this process.
    • Select “Update an existing site content type”, choose one of the content types created at step 1 and click next.
    • Map form fields to content type site columns.
    • Publish.
  • Export the updated content types using the stsadm extension available here http://stsadm.blogspot.com/2008/02/export-content-types.html. The exported fields will look similar to:
  • Create a feature that installs the exported content types. Note: Remove the unrecognized Field properties (a few of them are used behind the scene and are not validated by the schema).

Conclusion

The publishing process should be automatic and reproducible. Publishing relying on “Publishing Wizard” is an administration operation more than a deployment one. The described solution provides a mechanism for controlling the creation and deployment of InfoPath content types.

Content Query Webpart - Deploy Custom Style

Problem:

 I want to deploy my custom style for the Content Query Web Part (CQWP).

 The CQWP is using the following files to style its presentation: ContentQueryMain.xsl, Header.xsl and ItemStyle.xsl. The files are located under /Style Library/XSL Style Sheets in the root site.

 The first solution that comes into my mind is to replace the OOTB xslt files with our customized files. It will work if you do it as a manual operation from the Sharepoint UI but it will not work from the site definition (onet.xml) or from a feature. Also this solution doesn’t provide you an independent solution that doesn’t interfere with Microsoft possible updates.

 Solution:

 ContentByQueryWebPart is the CQWP class (a public class). It has a constructor with 3 parameters that provides a hook to specify the relative URLs to the files used for styling. You have to create a light class that inherits from ContentByQueryWebPart and which has the following implementation for the default constructor:

 public class MyCustomContentQueryWebPart : ContentByQueryWebPart

{

public MyCustomContentQueryWebPart()

            : base(”/Style Library/XSL Style Sheets/MyCustomContentQueryMain.xsl”, “/Style Library/XSL Style Sheets/MyCustomHeader.xsl”, “/Style Library/XSL Style Sheets/MyCustomItemStyle.xsl”)

        {

        }

}

 MyCustomContentQueryMain.xsl, MyCustomHeader.xsl and MyCustomItem.xsl can be created copying the OOTB files and amending them. The xslt files can be deployed to the /Style Library/XSL Style Sheets directly from the onet.xm file if you have your custom site definition or using a feature.