En sak som man kan bli förvirrad av är varför fält visas, eller inte visas, vid olika tillfällen. Likaså att fält låses. Det finns olika sätt att dölja, visa, låsa och göra fält tvingande och där någonstans börjar spagettin. Att ha ett sätt att jobba med detta underlättar för förvaltning och felletning.
Sätta värde för attribut
De olika komponenter som går att använda för detta listas här:
UI Policy
Beroende på förutsättningar/värden i ett formulär så kan man bestämma följande för ett fält:
Mandatory
Visible
Read only
Client Script
Baserat på vissa event för själva objektet (ex. Incident) eller ändringar i formuläret kan man styra värden på attributen som man vill. Du kan bestämma värden av följande för fält (i praktiken kan du göra allt man kan göra från ett script på klientsidan här då det är vanlig scriptning man använder Client Script till):
Mandatory
Visible
Read only
ACL tillsammans med roller
ACL:er styr rättigheter på objekt- och fältnivå. ACL:er är kopplade till roller som är kopplade till grupper vars gruppmedlemmar får rollerna och rättigheterna som är kopplade till rollerna. Det man kan styra via ACL är:
Visible
Read only
Dictionary
Den inställning du gör här påverkar all användning av relaterat fält. Inställningar du gör här kan du inte åsidosätta någon annanstans. Följande kan du bestämma här:
Mandatory
Read only
UI Action
Rent krasst skulle man kunna använda UI Action för att göra ändringar i formuläret på samma sätt som ett Client Script gör. Dock är det att föredra att använda, exempelvis, UI Policy för att påverka fälten då UI Action agerar på en händelse. Framför allt är det bra om vi kan se till att vi använder så få sätt som möjligt och då kanske denna inte behövs. Med det sagt kan man påverka fält på samma sätt som för Client Script:
Mandatory
Visible
Read only
Standardisera
Ok, hur gör vi nu då. Ett förslag är att använda de olika funktionerna ovan på detta sätt, i prioritetsordning uppifrån:
UI Policy Använd UI Policy som först alternativ för att bestämma om ett fält ska vara Mandatory, Read only eller Visible. Det går att göra samma saker med Client Script men enligt ServiceNows dokumentation sparar man prestanda på att använda UI Policy. Det är möjligt att den prestandaskillnaden inte är märkbar men det är lättare att konfigurera dessa attribut i UI Policy än att programmera dessa i Client Script. M.a.o., går det att ställa in dessa attribut i UI Policy, gör det, utan undantag. Eller, ok, ett undantag, det är när vi använder ACL:er och roller istället. Läs där nere (det skulle kunna gå att lösa detta med scriptdelen i UI Policy men vi försöker undvika script om det går). Ska policyn användas i alla ärvande tabeller så kan man definiera policyn i tabellen som ärvs och markera Inherit (Advanced view) så ärvs policyn till alla ärvande tabeller.
ACL och roller För att styra vilka rättigheter olika roller har använder vi ACL:er tillsammans med roller. Du kan läsa här om hur man sätter upp en sådan struktur för tabeller/objekt som kommer med ServiceNow. Har du skapat en egen tabell så behöver du sätta upp reglerna som ACL:er.
Sätt förs upp rättigheterna för tabellen (<tabell>.
Sätt sedan upp en generell regel för alla fält (<tabell>.*). Båda dessa ska ge relaterade roller rätt att se objekt och fält.
För att dölja fält, sätt upp regler för specifika fält och definiera roll som har rätt att se det fältet (<tabell>.<fält>). På ovan länk har jag ett exempel på detta.
Notera att när man skapar en ny tabell så läggs följande regler automatisk till, allt annat (som exempelvis <tabell>.*) måste läggas till. ServiceNow har även skapat en ny roll och kopplat den till reglerna:
<tabell> | delete
<tabell> | write
<tabell> | create
<tabell> | read
Dictionary Enda anledningen till att sätta attribut härifrån är om man vet att fältet alltid ska vara antingen Mandatory eller Read only oavsett var det används. Fast du kan troligtvis använda UI Policy till detta, tillsammans med arv (om det finns tabeller som ärver varandra) enligt ovan.
Client script Använd helst inte detta för att styra nämnda attribut, använd UI Policy istället. Det kanske finns tillfällen när UI Policy inte går att använda utan man måste använda Client Script istället. Kommer ni på något sådant, skriv gärna i kommentaren nedan.
UI Action Liksom för Client script, undvik att använda UI Action om det absolut inte går m.h.a. något ovan. Jag kan inte komma på något tillfälle när man måste använda UI Action istället för UI Policy.
Applicera standarden
Det finns speciellt två scenarior när man ska använda denna standard. Ena är när man behöver sätta värdet på något attribut/fält och det andra är när man måste hitta var attribut/fält sätts.
Om man har som princip att alla alltid börjar uppifrån i listan under “Standard” ovan och använder det sätt som först är en gångbar lösning, då bör det vara mycket lättare att även hitta vad det är som sätter attributet. Börja alltid högst upp även när du letar efter hur värdet sätts.
Och om du fortfarande inte hittar var saker styrs kanske du kan titta om det finns någon Business rule som gör något (finns exempel när Business rule tar bort incidenter för visning. En sådan regel kan, och gör ibland, titta på vad användaren har för roll och ser till att inte visa några, exempelvis, incidenter för användaren).