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.

 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:

  

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.