I denna artikel presenteras Access-delen av admin-gränssnittet. Artikeln består av följande delar: 3.1 Hantering av accesser, 3.2 App attest flow, 3.3 Accessgrupper, 3.4 Replace user och 3.5 Accesser och data.
3.1 Hantering av accesser
Det är inte nödvändigtvis alla användare som har accesser knutna till sig i en plan. För att en användare ska kunna se data i appar i en plan behöver användaren ha accesser i planen. Vanligtvis har en användare flera accesser i en app för olika dimvärden.
Under access-delen av admin-gränssnittet får admin välja en app i menyn till vänster (Figur 3.1). Alla appar i aktuell plan visas. När app är vald visas accesser och det användarflöde som är uppsatt för just denna app. De olika delarna i access-delen av admin-gränssnittet är:
- App attest flow (attestflöde), för att sätta upp användarstrukturen i appen.
- Access groups (accessgrupper), för att avgöra vem som har tillgång till vilken data i appen.
- Replace user, ger möjlighet att byta accesser mellan användare.
Dessa delar förklaras i kommande avsnitt.
Figur 3.1: Lista appar
3.2 App attest flow
Appen Personal är vald ur menyn i Figur 3.2 och direkt till höger syns då det som kallas attestflöde i appen, alltså vem som rapporterar till vem. Attestflöde går att ändra antingen genom att klicka på en användare i flödet och dra till dit denne ska finnas. Då kommer även underliggande användare följa med om det finns.
Figur 3.2: App atestflöde Coffeshope OPEX/CAPEX
Det går även att högerklicka på en användare i flödet (Figur 8 användare Farida Nyman) då finns det följande val:
- Add superior user, möjlighet att lägga in en användare som inte redan har tillgång till appen som superioruser för vald användare. I Figur 8 skulle Farida Nyman (SB) rapportera till vald användare istället för Camilla Sköldberg (SB). Efter att en ny superioruser väljs för Farida Nyman (SB) kommer denna användare i sin tur rapportera in till Camilla Sköldberg (SB).
- Add subordinate user, möjlighet att lägga in användare som inte redan har tillgång till appen som rapporterar in till vald användare, i detta fall Farida Nyman (SB).
- Remove app from user, möjlighet att ta bort appen från användaren, accesser (Avsnitt 5.3) kopplade till användaren och appen försvinner, dock försvinner ingen data i Konstrukt. Detta val finns inte för användare med underliggande användare.
- Lock write access for user and subordinates, möjlighet att göra all data som finns för användaren och eventuella underliggande användare ej editerbart i appen, och användaren får en lås-symbol på appen för att symbolisera detta (Figur 3.3). Data kommer fortfarande vara läsbart. För att låsa upp appen igen gör admin på samma sätt fast nu finns valet Unlock write access for user and subordinates istället.
Figur 3.3: Låst app
- Deadlines, möjlighet för admin att bestämma när arbetet i appen behöver vara färdigt. Om en deadline finns kommer det dyka upp en symbol på användarens app för att markera detta, och aktuell deadline går att se genom att användaren för muspekaren över symbolen.
Efter ändringar har gjorts i attestflödet är det viktigt att trycka på Save nere till höger för att ändringar ska sparas. Ändras något i attestflödet påverkar inte detta accesser (Avsnitt 3.3) förutom om en användare tas bort ur flödet (användarens accesser tas bort).
3.2.1 Import/Export Attestflöde
Vill admin hantera attestflödet med en excel-fil går det exportera och importera flödet genom att klicka på knappar Export samt Import (Figur 3.4) uppe till vänster. Filen som exporteras får två kolumner UserId samt SuperiodUserId och i Figur 10 har strukturen för Personal-appen exporterats. Denna fil går redigera och sedan importera genom att klicka på Import-knappen (Figur 3.4). Ändringar kommer att slå igenom och flödet uppdateras, i detta fall behöver admin inte trycka på Save-knappen.
Figur 3.4: Export attestflöde personal
I filen exporteras userid för användare och inte användarnamn. I detta fall är UserId de tre första bokstäverna i förnamn och efternamn. I Figur 3.4 går exempelvis se att användare kennor och eriomr rapporterar till rebhol alltså Kenneth Norstedt (SOC) och Erik Omrani (SOC) rapporterar till Rebecca Holmqvist (SOC) vilket kan ses i Figur 3.2. Längst upp i flödet i varje app finns admin (Systemadministratören) som inte rapporterar till någon, därför är SuperiorUserId tomt.
3.3 Accessgrupper
Under app attestflöde i access-delen av admin-gränssnittet finns accesser för appen som är vald. Accesser är grupperade i grupper eller så kallade access groups (accessgrupper) som avgör på vilka dimvärden som användare kan budgetera i appen. Nere i högra hörnet syns att det finns totalt 16 accessgrupper i vald app (Figur 3.5).
Figur 3.5: Accessgrupper personalapp
Group id är unikt per accessgrupp, Initial user är den användare som från början hade tillgång till det data accessen avser och Current user är den användare som för närvarande har accessen och kan därmed redigera data.
Från början är Initial User och Current User samma, men om en användare skickar in sin app till sin godkännare kommer Current user bli denna användaren som nu kan redigera det data som underliggande skickade in. Om godkännaren underkänner appen kommer current user gå tillbaka igen. I Figur 3.5 syns exempelvis att Farida inte skickat in sin app eftersom Initial user och Current user är samma, eller att Farida skickat in sin app men att godkännaren underkänt appen så Current user är tillbaka till Farida.
Alla värden i dessa kolumner är redigerbara förutom Group id och för att redigera dubbelklickar admin på en cell. Vill admin exempelvis byta en accessgrupp från en användare till en annan går det byta Initial user och Current user och sen trycka Save selected rows (spara-ikonen) i menyraden, eller byta vad en accessgrupp visar för data genom att byta värdet i cellen under Ansvar-kolumnen.
3.3.1 Exempel accessgrupper
I Figur 3.5 syns att användare Farida Nyman (SB) har accessgrupper 67 och 68 vilket ger access till all data på Ansvar 251310 och 251320 i appen. En accessgrupp kan sättas på flera dimensioner för att göra accessen mer detaljeradEW.
Exempelvis kan accessgrupp 67 i Figur 3.5 också sättas på Konto 5020, och då skulle Farida bara ha access på data med Ansvar 251310 och Konto 5020. Om det finns data i appen på Ansvar 251310 och Konto 3011 skulle Farida i detta fall alltså inte ha tillgång till detta data.
3.3.2 Menyval
I menyvalet uppe till höger under access groups (Figur 3.6) finns olika val.
Figur 3.6: Menyval accessgrupper
Dessa förklaras från vänster till höger nedan:
- New row skapar en ny rad, så admin manuellt kan lägga in accessgrupper. Då behövs Group id inte anges utan detta sätts automatiskt när raden sparas (genom att klicka på Save selected rows knappen).
- Import data ger möjlighet att importera accessgrupper från excel-fil eller csv. Excel-filen behöver ha kolumnrubriker som stämmer överens med Konstrukt, vilket alltid kommer vara Initial user och Current user. Stor och liten bokstav spelar roll.
- Select all väljer alla rader. För att välja enskilda rader manuellt klicka bredvid raden på bocken.
- Deselect all tar bort aktuellt val av rader.
- Save selected rows sparar de rader som är valda. Om ändringar gjorts behöver admin trycka på denna knapp för att spara.
- Remove selected rows tar bort valda rader, detta sparas automatiskt utan att admin behöver spara. Om en accessgrupp tas bort kommer data för denna accessgrupp inte längre vara synlig i appen för användaren, men ingen faktisk data tas bort som resultat av detta.
- Clear filter tar bort filter om det finns något applicerat (Avsnitt 3.3.5).
- Export exporterar alla accessgrupper från appen till Excel-fil oavsett om filter är applicerat, Excel-fil får samma rubriker som i Konstrukt.
- Show/hide column ger val över vilka kolumner som ska visas. Exempelvis går det välja att inte visa Current User kolumnen. Om sedan Export väljs kommer inte denna kolumnen med.
3.3.3 Filter
Det går att filtrera i accessgrupper genom att klicka på symbolen med tre streck bredvid kolumnnamnet (Figur 3.7) och söka. Dessa filter tar hänsyn till stor och liten bokstav. När filter är aktivt visas det genom att filterknappen får orange färg (Figur 3.7).
Figur 3.7: Filter accessgrupper
När filter väljs finns olika val på hur filtret ska appliceras. Dessa val gäller generellt för filter i admin:
- Equals, filter appliceras på exakt det som skrivs in.
- Does not equal, filter appliceras på värden som inte är exakt det som skrivs in.
- Begins with, filter appliceras på värden som börjar med det som skrivs in.
- Does not begin with, filter appliceras på värden som inte börjar med det som skrivs in.
- Ends with, filter appliceras på värden som slutar med det som skrivs in.
- Does not end with, filter appliceras på värden som inte slutar med det som skrivs in.
- Contains, filter appliceras på värden som innehåller det som skrivs in.
- Does not contain, filter appliceras på värden som inte innehåller det som skrivs in.
- Regular expression, filter appliceras på värden som matchar ett angivet reguljärt uttryck.
3.4 Replace user
Längst ned på sidan finns Replace user (Figur 3.8) och detta är sista delen av accessdelen av admin-gränssnittet. Replace User innebär att en admin kan byta ut en användare och alla dennes accessgrupper i aktuell app till en ny användare. User to replace är den användare vars accessgrupper ska flyttas till Target user. Target user kommer hamna på samma plats i attestflödet som User to replace var på om Target user inte redan har tillgång till appen, då kommer Target user och User to replace finnas kvar på samma plats som tidigare. Den användaren som tar över accessgrupper blir current user och initial user för dessa.
Figur 3.8: Replace user
För att en användare ska dyka upp under User to replace måste denna användare ha accessgrupper i appen. User to replace kommer inte längre ha tillgång till appen, och den som tar över accessgrupper ser det data den ersatta användaren arbetade med.
Det finns också valet att kryssa i Target all apps och då kommer detta ske i alla appar User to replace har accessgrupper, med samma logik som ovan.
3.5 Accesser och data
För att en användare ska kunna se data i en app i Konstrukt måste följande tre punkter gälla:
- Användaren har tillgång till appen vilket kan ses i app attestflödet
- Användaren har accessgrupper i appen med önskade accesser på önskade dimvärden
- Dimvärden existerar (Kolla i dimeditor på aktuell dimension att dimvärdet finns)
Det är viktigt att kontrollera att samma användare inte har två eller fler accessgrupper som täcker samma data i en app. I detta fall sker flera uppdateringar mot databasen när värden sparas vilket resulterar i att fel värden sparas. Exempel på detta är:
- Användare larsson har accessgrupp på Ansvar 144 i en app med Ansvar, Period och Konto som dimensioner. En annan accessgrupp för samma användare är bara på Konto 3011.
- Användare martinsson har accessgrupp Objekt 100 inlagt två gånger i samma app
- Användare gustafson har accessgrupp på Verksamhet 4* i en app med dimensioner Ansvar, Verksamhet, Konto och Period. En annan accessgrupp för samma användare är på Ansvar 100 och Verksamhet 45.
I fall 1) ovan innebär dessa två accessgrupper att det finns två accessgrupper som gör att Martin kan editera konto 3011 i appen. Detta eftersom den första accessgruppen ger möjlighet att editera alla konton och perioder på Ansvar 144, vilket inkluderar konto 3011.
I fall 2) är accessgrupperna identiska och därmed täcker de samma data.
I fall 3) har Mia genom första accessgruppen access på Verksamhet 40-49 och alla kombinationer av de andra dimensionerna inklusive Ansvar 100, vilket tillsammans med den andra accessgruppen gör att samma data täcks.
Det är alltså viktigt att kontrollera att accesstrukturen i en app är uppsatt korrekt och logiskt.