Selvbetjening til nye websteder, og grupperne webstedet ikke kendte
En kæde af flows opretter et websted og dets sikkerhedsgrupper i Entra. Grupperne findes, men webstedet kender dem ikke, før ensureUser har lagt dem på det. Om at bygge selvbetjening til nye websteder i efteråret 2023.
I efteråret 2023 byggede jeg selvbetjening til nye SharePoint-websteder hos en kunde. Bestillingerne ligger i en SharePoint-liste, en Power App viser dem, og en række flows opretter webstedet, dets sikkerhedsgrupper i Entra og rettighederne. Løsningen findes i tre udgaver, til udvikling, test og produktion, hver med sit eget websted til listerne. Hvilken skabelon et nyt websted skal bygges fra, hvilket præfiks adressen skal have, og hvilke grupper der skal have hvilke rettigheder, står i en konfigurationsliste pr. webstedstype.
Seks flows efter hinanden#
Den 19. oktober skrev jeg oprettelsen ned som seks flows, der kører efter hinanden. Hvert flow starter på en bestemt værdi i bestillingens statuskolonne og sætter den næste værdi, når det er færdigt:
| Trin | Starter ved | Sætter |
|---|---|---|
| 1. Giv bestillingen et websteds-id | Ny bestilling | Approved |
| 2. Opret webstedet | Approved | Site created |
| 3. Opret sikkerhedsgrupperne | Site created | Securitygroups created |
| 4. Kopiér data | Securitygroups created | Data copied |
| 5. Tildel rettigheder | Data copied | Permissions assigned |
| 6. Sæt webstedet i drift | Permissions assigned | Site Live |
Hvert flow har en triggerbetingelse på statussen, fx for trin 3:
@equals(triggerBody()?['Status'], 'Site created')
Med en status pr. trin kan det ses i listen, hvor en bestilling er gået i stå, og et trin kan køres igen ved at sætte statussen tilbage.
Grupperne#
Trin 3 opretter webstedets sikkerhedsgrupper i Entra med Microsoft Graph. Trin 5 skal give dem rettigheder på webstedet, og det var der, der skulle prøves flere ting.
En rettighedstildeling i SharePoint vil have gruppens id på webstedet. Det er et tal fra webstedets skjulte brugerliste, ikke gruppens objekt-id i Entra. Mine noter fra den 12. oktober viser to forsøg. Det ene var getuserbyid med objekt-id’et, men getuserbyid tager webstedets tal, ikke et objekt-id. Det andet var et opslag på gruppens login, som for en sikkerhedsgruppe er et claim med objekt-id’et:
_api/web/siteusers(@v)?@v='c:0t.c|tenant|<gruppens objekt-id>'
Det opslag finder kun gruppen, hvis den allerede står på webstedets brugerliste. En gruppe, som flowet lige har oprettet i Entra, har aldrig været på webstedet og står der ikke.
Den 26. oktober skrev jeg konklusionen ned: før en brugers id slås op, skal brugeren være på webstedet. Det sørger ensureUser for. Kaldet lægger gruppen på brugerlisten, hvis den ikke er der, og giver id’et tilbage, uanset om den var der i forvejen:
POST _api/web/ensureuser
Body: { "logonName": "c:0t.c|tenant|<gruppens objekt-id>" }
Id’et fra svaret går direkte i tildelingen, her på et bibliotek, og rettighedsniveauet kommer fra konfigurationslisten:
POST _api/web/lists/getbytitle('<bibliotek>')/roleassignments/addroleassignment(principalid=<id fra ensureUser>,roledefid=<niveau>)
Webstedsadressen ligger i en miljøvariabel, så det samme flow kan køre i alle tre udgaver.
En måned senere, den 22. november, fik oprettelsen et fast trin mere: faste administratorer lægges på hvert nyt websted.
Kaldet, claims for hver slags bruger og gruppe og tallene for rettighedsniveauerne står i noten Brugere og grupper på et websted med ensureUser. De andre veje fra en e-mail eller et login til id’et på webstedet, og hvornår hver af dem fejler, står i Find en brugers id på et SharePoint-websted ud fra e-mailen.
Sidst opdateret