Een gegevensbeleid schrijven

Doel

Een regel toevoegen die het platform niet meelevert — "niet boven je goedkeuringslimiet", "niet meer zodra er is gefactureerd" — en de machtiging van een rol erop filteren.

Vereisten

• Je bent aangemeld bij het Beheercentrum, er is een omgeving geselecteerd, en je hebt de oplossing geopend waarbij het beleid hoort — daar staat het scherm, omdat het beleid meereist in het pakket van die oplossing.
• Je kent de logische namen van de velden die je regel leest. Ze staan op het scherm Velden van de tabel.

Drie soorten, en de juiste kiezen

De ingebouwde beleidsregels beantwoorden welke records — die van mij, die van mijn eenheid, die van iedereen. Ze dekken het meeste van wat een rol nodig heeft. Schrijf er zelf een als ze dat niet doen, en het eerste wat je beslist, is welk soort:

	Welke records	Regel per record
Wat het is	een voorwaarde die wordt omgezet in een databasefilter	een regel die wordt gecontroleerd als een record wordt opgeslagen
Gebruik het als	het antwoord afhangt van wie het vraagt — zijn regio, zijn team	het antwoord afhangt van wat er in het record staat — een goedkeuringslimiet, een status
Wat een gebruiker ziet	de records zijn er gewoon niet	een melding die zegt waarom het opslaan werd geweigerd
Voorbeeld	Record.par_region == CurrentUser.par_region	"Dat totaal ligt boven je goedkeuringslimiet."

Een beleid Welke records is het betere gereedschap wanneer het past: records die het uitsluit, verlaten de server nooit, dus afdwingen kost niets en er is voor niemand een melding om te lezen. Het kan echter niet alles — het wordt een query, dus het kan alleen velden met waarden vergelijken.

Een beleid Regel per record is het beleid dat Total is under my approval limit kan zeggen, omdat dat geen vraag is over welke records er bestaan. Het draait op elk record dat wordt opgeslagen, en het kan zichzelf uitleggen.

Het derde soort, Wiens records (portal), is helemaal niet voor aangemelde mensen — het beantwoordt dezelfde vraag "welke records" voor een bezoeker van een portal, en het wordt op een tabel gedeclareerd in plaats van aan een rol toegekend. Als je dat zoekt, is dit niet de pagina die je wilt: zie Bepalen wiens records een bezoeker ziet.

Is je regel eigenlijk "iedereen moet dit invullen", dan wil je in plaats daarvan een bedrijfsregel of een plug-instap op de tabel — die gelden voor iedereen, en dat is wat een regel voor gegevenskwaliteit betekent. Een beleid geldt voor iedereen die er een machtiging onder heeft, en dat is wat een machtiging betekent.

Stappen

1. Open Oplossingen, open de oplossing waarin je applicatie staat, en selecteer Gegevensbeleid in de navigatie ervan. Het scherm toont de beleidsregels die deze oplossing bevat; de standaardoplossing ("Main") toont elk beleid in de omgeving.

2. Selecteer Nieuw.

3. Geef het een weergavenaam — hoe het zal heten in de lijst met beleidsregels op het rollenscherm. De logische naam vult zichzelf in onder je uitgeversvoorvoegsel; je kunt hem nu wijzigen maar later niet meer, omdat het de naam is waarnaar elke toekenning verwijst.

4. Kies het type. Dat bepaalt wat de rest van het formulier vraagt, en het kan achteraf niet worden gewijzigd. De stappen hieronder zijn voor Regel per record; ga voor Welke records verder bij Een beleid Welke records schrijven.

5. Kies Welke records. Voor een regelbeleid is dit het ingebouwde beleid dat lijsten filtert, en het is niet optioneel — zie Waarom een regelbeleid ook een bereik nodig heeft. Elk record betekent "alles, onder voorbehoud van mijn regel".

6. Vink de bewerkingen aan waarbij de regel moet worden gecontroleerd. De standaard is aanmaken, bijwerken en verwijderen. Laat Lezen uit, tenzij je het meent: een regel die lezen weigert, laat records uit lijsten verdwijnen om een reden die niemand kan zien.

7. Schrijf de regel. Het is BS Lang, dezelfde taal als een bedrijfsregel, en hij draait op één record:

   if (getValue("par_total") > currentUser("par_approvallimit")) {
     deny("That total is over your approval limit.");
   }

   Roep deny("…") aan om te weigeren. Een regel die niets weigert, staat de bewerking toe. De melding die je schrijft, is wat de gebruiker ziet — zeg dus wat het record acceptabel zou maken, niet dat er iets mis was.

8. Selecteer Opslaan. Kan de regel niet worden geparsed, dan mislukt het opslaan en wordt gezegd waar. Dat is bewust: het alternatief is erachter komen wanneer iemand wordt geweigerd door een regel die niet kan draaien.

9. Open het scherm Rollen van de oplossing en zet de cel voor de machtiging die je gefilterd wilt hebben op je nieuwe beleid. Het verschijnt in dezelfde lijst als de ingebouwde.

Een beleid Welke records schrijven

Een beleid Welke records wordt een databasequery, dus het wordt anders geschreven en vraagt om andere dingen.

1. Kies de tabel. Anders dan een regel wordt dit soort beleid geschreven op de velden van één tabel, dus het moet er een noemen — en door die te noemen kan het platform bij het opslaan controleren of die velden bestaan. Het wordt alleen aangeboden op de rij van die tabel op het scherm Rollen van de oplossing.

2. Schrijf de voorwaarde — één voorwaarde, geen script:

   Record.par_region == CurrentUser.par_region && Record.par_status != "Closed"

   Record.<field> is een veld van de gekozen tabel. CurrentUser.<name> is iets over de aangemelde persoon — dezelfde namen als onder Wat een regel kan lezen, plus elk veld van de gebruikerstabel. Verbind voorwaarden met && en ||, en groepeer ze met haakjes.

3. Vergelijken met een verzameling betekent "is een van": Record.owning_unit == CurrentUser.UnitsAndBelow selecteert records die eigendom zijn van ergens in je eenheid of daaronder. Je kunt ook vergelijken met een uitgeschreven lijst: Record.par_status == ["Draft", "Submitted"].

4. Selecteer Opslaan. Alles wat het platform niet in een query kan omzetten, wordt nu geweigerd, met de reden — zie hieronder.

Wat een voorwaarde niet kan zeggen

Dit is bewust beperkt, omdat alles erin een databasequery moet worden:

Niet toegestaan	Omdat	In plaats daarvan
>=, <=	er geen queryoperator voor is	> of <
!(…)	een query niet kan worden genegeerd	zeg wat je wilt houden, met !=
length(x), elke functie	die zou moeten worden uitgevoerd, en een filter wordt niet uitgevoerd	vergelijk het veld rechtstreeks
Record.total * 2 > 100	rekenkunde verhindert dat een query een index gebruikt	vergelijk met het getal dat je bedoelt
Record.account.owner	een zoekveld volgen is een join, en een verborgen join is bij elke query traag	een veld van deze tabel
meerdere voorwaarden op meerdere regels	een beleid is één voorwaarde	verbind ze met &&

Al deze gevallen worden bij het opslaan geweigerd, met vermelding van de regel. Dat is de hele reden dat de voorwaardentaal klein is: een voorwaarde die het platform stilletjes niet kon afdwingen, zou records tonen waarvan iemand dacht dat ze verborgen waren.

Wat een regel kan lezen

Aanroep	Geeft je
getValue("par_total")	Het record zoals het na de wijziging zal zijn.
getPreValue("par_total")	Het record zoals het nu is opgeslagen. Leeg bij aanmaken.
currentUser("par_approvallimit")	Een veld van het eigen gebruikersrecord van de aangemelde persoon.
isOwner()	Of deze persoon het record bezit.
hasRole("Manager")	Of hij een rol heeft.
operation()	Create, Read, Update of Delete.
entityName()	De logische naam van de tabel.
deny("…")	Weigeren, met de reden die de gebruiker zal lezen.

currentUser leest de gebruikerstabel in deze omgeving, dus om met een goedkeuringslimiet te vergelijken voeg je dat veld er eerst aan toe, precies zoals je dat bij elke andere tabel zou doen.

Waarom een regelbeleid ook een bereik nodig heeft

Een regel heeft een record nodig dat al is geladen. Een lijst is precies wat je hebt voordat je er een hebt geladen, dus een regel kan er geen filteren — het platform zou elke rij moeten ophalen om te beslissen welke rijen het moet ophalen. Een beleid Welke records heeft de omgekeerde eigenschap, en precies daarom is het een apart soort in plaats van een slimmere regel.

Een regelbeleid heeft dus beide: Welke records is een ingebouwd beleid dat het platform naar de database doorgeeft, en de regel wordt daarna gecontroleerd op elk record dat iemand werkelijk opent, opslaat of verwijdert. Zet Welke records op het smalste ingebouwde beleid dat klopt, en laat de regel de rest afhandelen.

Er een uitzetten

Vink Van kracht uit en sla op. Het beleid bestaat nog, en elke toekenning eronder blijft werken — alleen onder het antwoord van Welke records, zonder dat de regel wordt gecontroleerd. Dat is het veilige om te doen terwijl je uitzoekt waarom een regel iets weigert; het beleid verwijderen is dat niet, en het platform laat je geen beleid verwijderen dat een rol nog gebruikt.

Een beleid Welke records heeft zo'n schakelaar niet, en dat is geen vergissing: het is het antwoord op welke records, dus uitzetten zou alleen kunnen betekenen dat alles of niets wordt getoond, en geen van beide is wat iemand met pauzeren zou bedoelen. Wijzig de voorwaarde, of wijzig de toekenning.

Beleidsregels reizen mee met de oplossing

Een beleid hoort bij een oplossing, net als een tabel of een formulier, en het gaat mee met die oplossing als je haar exporteert en komt aan als je haar ergens anders importeert.

Dat is juist het punt van er een schrijven. "Een factuur boven mijn goedkeuringslimiet is niet aan mij om goed te keuren" hoort bij hoe de applicatie werkt, niet bij een instelling die iemand per omgeving configureert — dus de app zonder dat beleid leveren zou Test en Productie stilletjes laten toestaan wat Ontwikkeling weigerde, en dat is de slechtst denkbare richting waarin een beveiligingsregel kan falen.

Daaruit volgen drie dingen:

• De regel wordt bij het importeren opnieuw gecontroleerd, precies zoals toen je hem schreef. Een pakket met een beleid dat niet meer compileert, wordt bij het importeren geweigerd in plaats van ontdekt door de eerste persoon die het ten onrechte weigert.
• Een beleid dat uitgeschakeld wordt geleverd, komt uitgeschakeld aan. Vink Van kracht uit bij een regel die klaarstaat voor een livegang, en de doelomgeving krijgt hem in die toestand; de import zet geen regel aan waar nog niemand om heeft gevraagd.
• Het verwijderen van de oplossing verwijdert het beleid — en de toekenningen die eronder zijn gedaan; dat is de enige keer dat die verdwijnen zonder dat erom wordt gevraagd. Een toekenning waarvan het beleid weg is, zou anders alles gaan weigeren wat ze ooit toestond, zonder dat iets op het scherm zegt waarom.

Wie er iets onder het beleid toegekend krijgt, reist niet mee: dat noemt je mensen, en het blijft in de omgeving waar je het hebt besloten.

Problemen oplossen

• "De regel van het beleid kan niet worden geparsed." — een typefout in de regel. De melding noemt de plek.
• "… is een van de eigen beleidsregels van het platform." — je hebt een ingebouwde naam gebruikt. Je eigen beleidsregels dragen je uitgeversvoorvoegsel.
• "… filtert nog machtigingen van N rol(len)." — wijzig die toekenningen eerst op het scherm Rollen van de oplossing. Het beleid nu verwijderen zou ze allemaal weigeren.
• Niemand kan iets opslaan in de tabel. — controleer de vergelijking in de regel. Een regel die een veld leest dat niet bestaat, krijgt een lege waarde, en "" > 100 is niet de vergelijking die je bedoelde. Vink Van kracht uit terwijl je het uitzoekt.
• De regel lijkt nooit te draaien. — controleer de bewerkingen die je hebt aangevinkt, en of de toekenning van de rol echt naar je beleid wijst en niet naar een ingebouwd beleid.
• Een gebruiker wordt geweigerd met een melding over een beleid dat niet kon worden geëvalueerd. — de regel kon niet draaien. De bewerking wordt geweigerd in plaats van toegestaan, omdat een regel die niet kon draaien niet heeft gezegd dat het record acceptabel is. Herstel de regel, of vink Van kracht uit.
• "Deze voorwaarde kan niet in een query worden omgezet." — een voorwaarde voor Welke records gebruikt iets wat een query niet kan uitdrukken. De melding noemt de regel en wat je in plaats daarvan kunt gebruiken; de tabel hierboven somt ze allemaal op.
• Mijn beleid Welke records wordt niet aangeboden op de rij die ik wil. — het is geschreven op één tabel, dus het wordt alleen aangeboden op de rij van die tabel, en nooit op Alle tabellen. Schrijf een apart beleid voor de andere tabel.
• Een beleid Welke records toont niemand iets. — een voorwaarde die op niets uitkomt, selecteert niets; dat is de veilige richting die het platform altijd kiest. Controleer de veldnamen en, als je met een verzameling als CurrentUser.Teams hebt vergeleken, of de persoon echt in een team zit.

Gerelateerde scenario's

• Bepalen wiens records een bezoeker ziet
• Een rol toegang geven tot records.
• Wijzigen wie een record bezit.