In urma cu cateva zile, am intampinat probleme la trimiterea de emailuri cand un nou task este adaugat intr-o lista de task-uri Sharepoint. O sa fac o mica introducere pentru a intelege contextul, inainte de a explica problema in sine.

Avem un workflow care creaza task-uri in lista predefinita de task-uri a unui site de colaborare in echipa. Cerinta de securitate este sa dai permisiune de citire userului asignat task-ului respectiv si de asemenea unui anumit grup sharepoint.

Am decis sa implementez cerinta de securitate ca si parte componenta a unui 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();
}

Cand am testat, am observat ca nu este trimis nici un email dupa ce workflow-ul creaza un task nou si dupa ce handler-ul nostru este apelat. Ce a fost foarte ciudat era faptul ca doar notificarea crearii task-ului nu fusese trimisa. Daca schimbam task-ul, persoana asignata primea notificarea pe email.

A trebuit sa inteleg mecanismul care produce notificarile prin email: facilitate de alerte Sharepoint collaboration. Am descoperit cateva lucruri interesante in timpul testelor mele si “cercetarea google” si vreau sa impartasesc aceste informatii si cu voi, inainte de a ne reintoarce la problema noastra.

Alertele sunt create/exista la nivelul unui site si pot fi asociate cu liste, item-uri sau obiecte custom. Daca construiesti un site folosind o definitie de site de tip Team Collaboration o alerta va fi creata automat si asociata listei de task-uri. Aceasta se intampla pentru ca optiunea de Notificare prin Email este activate (Tasks > Settings > Advanced Settings). Daca selectati “No” alerta va fi stearsa.

Pentru a vizualiza alertele existente (inclusive proprietatile acestora) intr-un site Sharepoint eu folosesc Sharepoint Manager 2007. Acest tool foloseste numai Sharepoint Object Model (OM) pentru a afisa informatia Sharepoint si ofera o ocazie buna de a invata foarte multe lucruri despre posibilitatile OM.
Urmatoarea imagine prezinta proprietatile alertei pentru lista predefinita de task-uri:

Merita observat faptul ca alerta noastra este alerta “System”, este o alerta imediata, folosind un destinatar dynamic pentru a primi adresele de email, are tipul de lista si este asociata la lista de task-uri.

Destinatar dinamic se refera la faptul ca alerta se leaga de coloana AssignedTo din lista de task-uri pentru a primi adresa de email. Deci doar persoanele asignate task-ului respectiv vor primi notificari pe email.

Alertele immediate pot fi de asemenea vizualizate in tabelul ImmedSubscriptions al bazei de date de continut.

Alerta in sine nu trimite nici un email. Doar introduce inregistrari in baza de date de continut (tabelul EventCache) si, bazat pe aceste inregistrari, altcineva este la datorie si trimite emailuri.

Emailurile sunt trimise de catre timer job-ul de Immediate Alerts (Central Administration > Operations > Timer Job Definitions). Exista un job pentru fiecare aplicatie web si este setat predefinit sa fie executat la interval de 5 minute. Puteti gasi informatii detaliate despre comportamentul anormal si rezolvarea acestuia, in acest articol.

Consecinta observabila din punctul de vedere al utilizatorului final este intarzierea care exista din momentul in care task-ul este adaugat/modificat (alert logic scrie in DB) si momentul la care este primit emailul (job-ul de timer citeste din DB si trimite emailul). In cel mai rau caz trebuie sa astepti 5 minute (predefinit) pentru a-ti putea vedea noile task-uri sau modificarile pe task-urile existente. Daca vrei sa modifici programatorul temporal de job timer, poti utilize urmatoarea comanda:

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

Dupa ce am inteles toate mecanismele procesului de notificare, am cautat greseala in mediul meu de lucru. Totul parea in regula, asa ca am pornit cercetarea mea in jurul securitatii listei de task-uri. Mai jos va prezint scenariile testate de mine si comentariile aferente:

1. Am lasat mostenirea permisiilor nemodificata. Lista nu avea nici o permisiune pentru utilizatorul AssignedTo. Era clar ca mecanismul de modificare isi intrase in rol si ca job-ul de alerte imediate nu trimite nici un email. Asigurati-va deci ca acordati nivelul necesar de permisii utilizatorului AssignedTo al item-ului din task pentru ca acesta va primi notificarile prin email.

2. Am inlaturat mostenirea si am adaugat permisii numai utilizatorului AssignedTo. Surpriza: a functionat! Notificarea despre crearea task-ului a fost trimisa prin email.

3. Am mutat codul care creaza permisiile pentru utilizator deasupra celui care creaza permisiile pentru grup. Alta surpriza: functiona si acum.

4. Am crezut apoi ca s-ar putea sa aiba legatura cu modul de apelare Update asa ca am comentat prima declaratie properties.ListItem.Update() in codul original al event handler-ului. Aceasta implementare a functionat conform asteptarilor si a devenit si Solutia noastra finala in aces caz.

Este evident acum unde era problema, dar nu a fost la momentul implementarii event handler-ului: in codul original primul Update creaza obiectul task-ului care este monitorizat de catre alerta register. In acest moment numai grupul Sharepoint are asignate permisii pentru obiectul task-ului dar nu si utilizatorul AssignedTo. Chiar daca adaugi permisii utilizatorului AssignedTo in urmatorul Update, este prea tarziu pentru ca alerta tine cont de securitatea de la momentul crearii task-ului. Asta explica de ce utilizatorul AssignedTo incepe sa primeasca notificari despre modificari chiar daca nu a primit notificarea despre crearea task-ului.

Urmatoarele citate XML va prezinta un exemplu despre modul de constructie al unei facilitati care va incarca un fisier de data connection (.udcx) intr-o librarie de documente existenta in Sharepoint (Mostra de mai jos foloseste doar un singur fisier de data connection dar puteti sa introduceti cate doriti):

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>

Singurul truc este sa setezi proprietatea ContentType al fisierului incarcat pe valoarea “Universal Data Connection File” pentru ca libraria Data Connection nu are acest tip de continut ca predefinit.