Strokovni članek, avtor Robi Vončina, SharePoint MVP

Microsoft se je končno odločil, kar je sicer napovedoval dalj časa, da ukine podporo klasičnim delovnim tokovom in prisili uporabnike, da migrirajo svoje delovne tokove na MS Power Automate.

Večina uporabniških delovnih tokov, ki so se uporabljali tako na on-prem kot tudi v oblaku, je nastavljala pravice na elementih, glede na določene parametre. Ker za migracijo starih, SharePoint 2010, delovnih tokov orodja ni, sem se tudi sam srečal s kar precejšnjim izzivom, da smo pri strankah pretvorili delovne tokove na PowerAutomate in zato sem se odločil tudi za prikaz, na kakšen način lahko pretvorite lastne delovne tokove.

MS PowerAutomate

Priprave

Na seznamu, kjer bi si radi uredili funkcionalnost nastavljanja pravic, moramo najprej definirati, da bi radi ob ustvarjanju novega elementa in spreminjanju obstoječega, zagnali delovni tok.
Naj še povem, da ima seznam v mojem primeru, samo en dodaten stolpec tipa »Person or group«, ki se imenuje »Approver« in na podlagi katerega bomo nastavili pravice na elementu.

Na desni strani se vam v stranski vrstici pokažejo predloge novih delovnih tokov. Če ne najdete želene predloge, lahko kliknete na dnu »See your flows«, kar vas nato preusmeri na stran »Power Automate«. Če želimo ustvariti nov prazen delovni tok, lahko na tej strani izberemo opcijo »New« in nato »Automated-from blank«. 

 

V naslednjem koraku si moramo izbrati opcijo »When an item is created or modified - SharePoint«. Po kliku na gumb create, se nam pojavi delovna površina za ustvarjanje novega delovnega toka. Na tem mestu moramo najprej nastaviti, na katero mesto in na kateri seznam se povezujemo, se pravi nastavimo »Site address« in tudi »List name«. 

Logika

Prva akcija in tudi najbolj enostavna je, da v delovni tok dodamo korak »Stop sharing an item or a file«. V tej akciji nas zopet vpraša po URL-ju mesta, imenu seznama in dodati moramo še ID elementa, na katerem bi radi ustavili dedovanje pravic.
  

  S to akcijo smo dosegli, da smo prekinili dedovanje pravic in odvzeli pravice vsem uporabnikom, ki niso »Ownerji«, se pravi niso v skupini »Site Owners«.

Sedaj pa moramo pravice dodati uporabniku, ki je nastavljen kot approver, v stolpcu v seznamu. Za ta namen imamo med akcijami na voljo tudi »Grant access to an item or a folder«, ki od nas zahteva, da vpišemo uporabniške email naslove. Kar me je zmotilo v določenih primerih je bilo, da nimajo vedno vsi uporabniki mailboxa ali celo nimajo vpisanega email naslova. Iz tega razloga, je potrebno akcijo izpeljati na malo drugačen način, in sicer prek koraka, ki se imenuje »Send HTTP request to SharePoint«. V tem primeru se uporablja SharePoint REST API, kjer lahko prek HTTP klica nastavimo pravice na elementu. Glavna težava, ki pa se ob tem pojavi je, da ta klic od nas zahteve principalId user ID, ki pa ga v našem primeru ne dobimo kot podatek na viru. Zaradi tega moramo najprej narediti nov HTTP klic, ki nam bo priskrbel dotičen podatek, prebrati JSON, ki ga dobimo kot odgovor in nato dobljeni podatek uporabiti v naslednjem HTTP klicu.

 

 

 

Initialize variable

To akcijo uporabljamo, da lahko iz podatka v polju »Approver«, ustvarimo URI encoded zapis claims identitete. Formula za konverzijo je v mojem primeru: encodeUriComponent(triggerOutputs()?['body/Approver/Claims']).
 

Get user principal id

S pomočjo tega zapisa, lahko v koraku »Get user principal id« naredimo klic na REST endpoint: _api/web/siteusers(@v)?@v='[EncodedClaimsIdentity]'. Odgovor, ki ga dobimo s tem klicem, je v JSON obliki, zato moramo nujno odgovor prebrati z akcijo »Parse JSON«.

Parse JSON

V tem koraku moramo definirati 2 spremenljivki, in sicer body (pride iz prejšnjega koraka) in pa »Schema«. JSON shemo najlažje dobimo tako, da testno zaženemo delovni tok, z gumbom Test (skrajno desno zgoraj) in v akciji »Get user principal id«, skopiramo kar se nahaja v »body« polju:

 

To skopiramo v polje, ki se prikaže ob kliku na gumb »Generate from sample«. Ta operacija naredi shemo JSON odgovora in zaradi te akcije se lahko v naslednjem koraku sklicujemo na specifičen podatek.
V zadnjem koraku zopet dodamo akcijo »Send HTTP request to SharePoint«. V tej akciji pa bomo dejansko nastavili pravice za uporabnike na dotičnem elementu. Da bi se pravice nastavile pa moramo nastaviti naslednje:

1.  Site address à mesto kjer se nahaja seznam za nastavitev pravic
2.  Method: POST
3.  URI à Moramo določiti

a. Ime seznama
b. ID elementa
c. Principalid à dobimo iz »Parse JSON« akcije
d. roleDefId à ID nivoja pravic, ki ga želimo dodeliti. 

 

Seznam vseh ID-jev za roleDefinitions najlažje dobimo tako, da pokličemo REST endpoint, in sicer na način:
https://[tenant].sharepoint.com/[zbirka mest]/_api/web/roledefinitions.
V brskalniku nam URL vrne seznam vseh nivojev pravic in njihove ID-je, v spodnji tabeli pa nekaj najbolj pogostih:
 

Ime	ID
Full Control	1073741829
Edit	1073741830
Contribute	1073741827
Read	1073741826

S tem smo naredili delovni tok, ki nam omogoča, da ob ustvarjanju novega in spreminjanje obstoječega elementa nastavimo pravice uporabniku, ki je naveden v enem izmed polj na elementu.

V primeru dodatnih vprašanj ali komentarjev toplo vabljeni, da mi pišete na naslov: robi.voncina@kompas-xnet.si

Robi Vončina
SharePoint MVP