SharePoint

SharePoint Content Organizer versus SPD Workflow

1 februari 2012

Tijdens een van onze projecten (een oplossing voor het opslaan van digitale personeelsdossiers ) liepen we tegen een beperking van SharePoint aan bij het gebruik van SharePoint Designer Workflow i.c.m. de Content Organizer functionaliteit. Mocht je deze combinatie ook tegen komen in projecten waarin je nu of in de toekomst bij betrokken bent, lees dan verder!

De oplossing omvat dus personeelsdossiers. Voor ieder personeelsdossier wordt een “Document Set” aangemaakt op basis van een aangepast inhoudstype “Personeelsdossier”. Aan dit inhoudstype is een SharePoint Designer workflow gekoppeld die automatisch zou moeten starten op het moment dat een item o.b.v. dit inhoudstype wordt toegevoegd aan een biblitotheek. In de meeste gevallen is dit geen probleem. Nu bleek echter dat de Workflow niet werd gestart op het moment dat het document vanuit de Content Organizer verplaatst (ergens anders toegevoegd) werd. Om het probleem duidelijk te maken eerst wat achtergrond informatie:

[listdot]

  • SharePoint Designer Workflow kan worden gedefinieerd door “Power Users”.
  • Workflow wordt uitgevoerd met de rechten van de gebruiker die ervoor gezorgd heeft dat de workflow is gestart (bijvoorbeeld, de gebruiker die een item heeft toegevoegd aan een bibliotheek).
  • De Content Organizer functionaliteit wordt uitgevoerd door een speciale gebruiker: “Systeemaccount”. Dit is een gebruiker met erg veel rechten, veel meer dan dat een normale SharePoint gebruiker heeft.
  • Op basis van punt 2 zal bij het verplaatsen van een item (in dit geval een personeelsdossier) vanuit de Content Organizer de Workflow uitgevoerd worden met de rechten van het “Systeemaccount”. Uit beveiligingsoogpunt zorgt SharePoint ervoor dat SharePoint Designer Workflows nooit automatisch gestart worden als de huidige gebruiker het “Systeemaccount” is. Als dit wel zou zijn toegestaan, zouden “Power Users” via een omweg acties kunnen uitvoeren waarvoor zij zelf geen rechten hebben.

[/listdot]

Vervelend, maar op zich verklaarbaar dus waarom we hier tegenaan liepen. Omdat we toch willen dat de Workflow vanuit SharePoint Designer beheerd kan worden moesten we op zoek naar een oplossing. Even zoeken op internet wees uit dat meer mensen hier tegenaan waren gelopen. Een oplossing hier is om een “Event Receiver” te maken van waaruit de Workflow alsnog zou worden gestart. Een “Event Receiver” is een stukje code die op bepaalde momenten kan worden afgevuurd, bijvoorbeeld bij het toevoegen van een Item aan een lijst (beetje vergelijkbaar met Workflow dus). De “Event Receiver” wordt in dit geval ook uitgevoerd onder het “Systeemaccount”, maar in dit geval starten we de Workflow niet automatisch. In feite bootsen we in de code na wat een normale gebruiker in de browser zou kunnen doen om de Workflow handmatig te starten. Hiermee wordt het (functionele) probleem dus omzeilt, maar wordt tegelijkertijd wel het beveiligingslek gecreĆ«erd dat SharePoint voor ons juist wil afschermen.

Als alternatief had de Workflow in Visual Studio gebouwd kunnen worden. Dan waren we niet tegen dit probleem aangelopen, maar dan was de oplossing een stuk minder beheerbaar geweest doordat er bij iedere wijziging een Developer aan te pas had moeten komen…

Mocht je dus ooit tegen ditzelfde aanlopen, weet wat de impact van de mogelijke “oplossingen” is (en zorg ook dat de klant dit weet….)

You Might Also Like

Geen reacties

Plaats een reactie