Kedjemedlemmar och behörigheter

Behörighetsmodellen i kedjedrift bygger på kedjemedlemmar som tillhör behörighetsgrupper. Den viktigaste mekanismen är capability inheritance – en kedjeadmin får automatiskt admin på varje medlemsrestaurang utan separat konfiguration.

Grundmodell

Varje användare i en kedja är en kedjemedlem med:

• Kopplad Vendion-användare
• Vilken kedja personen tillhör
• Vilken behörighetsgrupp (styr rättigheter)
• Aktiv/inaktiv-status (så man kan pausa utan att radera)

En användare kan bara finnas som medlem en gång per kedja, men kan vara medlem i flera olika kedjor.

Behörighetsgrupper

Varje kedja får automatiskt en Admin-grupp vid skapandet:

• Full administrativ åtkomst
• System-skyddad – kan inte tas bort
• Har alla rättigheter (både vanliga admin-rättigheter och kedjespecifika)

Du kan skapa egna grupper. Vid sidan av Admin finns möjligheten att bygga grupper som "Regional chef" eller "Meny-redaktör" och ge dem exakt de behörigheter de behöver — varken mer eller mindre.

Gå till /chain/:slug/medlemmar, skapa en grupp, kryssa i behörigheterna och tilldela den till medlemmar.

Capability inheritance – nyckelmekanismen

När Alice är kedjeadmin för "Burgerbuffé Holding" (med 5 restauranger) händer följande:

1. Hon är medlem i Admin-gruppen i kedjan
2. Admin-gruppen har implicit admin.*-wildcard
3. När Alice försöker öppna /admin för någon av de 5 enheterna kollar systemet:
   • Är Alice direkt medlem av restaurangen? Nej.
   • Är hon kedjeadmin för den kedja som restaurangen tillhör? Ja.
   • → Ge åtkomst.

Resultat: Alice kan hantera meny, void ordrar, ge rabatter, hantera personal på alla 5 enheter utan att vara explicit restaurant_member någonstans.

Kedje-scopade rättigheter

Utöver de ärvda admin-rättigheterna finns särskilda rättigheter för kedje-funktioner:

Admin-gruppen har alla dessa. En egen grupp får precis de du kryssar i.

Två spärrar du inte kan råka gå runt

Behörighetssystemet är byggt så att en delegerad roll aldrig kan förhandla upp sig själv:

• Du kan inte dela ut en behörighet du själv saknar. Ger du någon rätten att hantera behörighetsgrupper kan hen bygga grupper — men bara med behörigheter hen redan har. Utan den spärren kunde en meny-redaktör gett sin egen grupp rätten att läsa personalens löner och personnummer i hela kedjan.
• Administratörsgruppen är låst. Ingen utom en befintlig kedjeadmin kan skapa en ny admin-grupp, flippa sin egen grupp till admin, radera admin-gruppen eller flytta sig själv in i den.

Båda kontrollerna sitter i databasen. De gäller även om någon pratar direkt med vårt API förbi gränssnittet.

⚠️ Spara-knappen ger bara det du ändrat. När du redigerar en grupps behörigheter skickas skillnaden — inte hela listan omskriven. Det är med flit: hade vi raderat allt och skrivit om, hade en delegerad roll låst ute sig själv i samma ögonblick som den tog bort sin egen rätt att hantera grupper.

Lägga till en medlem

1. Gå till /chain/:slug/medlemmar
2. Klicka "Lägg till medlem"
3. Sök efter användare (namn eller telefon)
4. Välj användaren
5. Tilldela behörighetsgrupp — Admin, eller en egen grupp du byggt
6. Klicka "Lägg till"

Användaren får omedelbart åtkomst till kedjekonsolen vid nästa inloggning.

Exempel: Lägga till en regional chef

Bob är regional chef för Stockholmsområdet i "Burgerbuffé Holding AB". Alice (kedjeägaren) vill att han ska kunna:

• Se konsoliderad analytics
• Hantera meny-mallar och publicera
• Inte ändra delningsflaggor

Skapa en grupp "Regional chef" med Se analytics och Hantera meny-mallar ikryssade, men inte Hantera inställningar. Lägg Bob i den gruppen. Han får precis det han behöver — och kan inte ändra kedjans delningsflaggor.

Kom ihåg spärren: du kan bara kryssa i behörigheter du själv har.

Inaktivera vs ta bort

Inaktivera (mjuk borttagning):

• Medlemmen markeras som inaktiv
• Användaren tappar åtkomst till kedjan
• Data bevaras (kan återaktiveras senare)

Ta bort (hård radering):

• Medlemskapet raderas helt
• Permanent – kan inte ångras från gränssnittet

Använd "inaktivera" för tillfälliga pauser (t.ex. föräldraledighet) och "ta bort" när någon slutat helt.

Kedjeadmin vs restaurangadmin – när ska man använda vad?

Åtkomst till lokal data vs kedjedata

• Kedjeadmin → ser all kedjedata + all data i alla medlemsrestauranger
• Restaurangadmin (lokal) → ser bara sin restaurang, ingen kedjedata
• Restaurangadmin i restaurang som tillhör kedja → ser sin restaurang + kedjemenymall (read-only) + låsningsikoner

Säkerhet och åtkomstkontroll

All åtkomst valideras direkt i databasen, inte bara i gränssnittet. Det betyder att även om någon försöker prata direkt med vårt API kommer de inte se data de inte har rätt till. Läs mer i Kedja – säkerhet och åtkomstkontroll.

Framtida utveckling

• Anpassade behörighetsgrupper (role builder)
• Grupp-specifika rättigheter (välj exakt vilka som ingår)
• Rollbaserade templates (t.ex. "Restaurangchef", "Meny-ansvarig", "Ekonomichef")
• Per-restaurang permission i en kedjemedlem

Nästa steg: Läs om gemensam meny-mall – en av de mest använda funktionerna.