Chain Members and Permissions

The permissions model in chain operations is built on chain members belonging to permission groups. The key mechanism is capability inheritance – a chain admin automatically gets admin on every member restaurant with no separate configuration.

Base model

Every user in a chain is a chain member with:

• Linked Vendion user
• Which chain the person belongs to
• Which permission group (controls rights)
• Active/inactive status (so you can pause without deleting)

A user can only exist as a member once per chain, but can be a member of multiple different chains.

Permission groups

Every chain gets an automatic Admin group at creation:

• Full administrative access
• System-protected – cannot be removed
• Has all rights (both regular admin rights and chain-specific)

You can create your own groups. Alongside Admin you can build groups such as "Regional manager" or "Menu editor" and give them exactly the permissions they need — no more, no less.

Go to /chain/:slug/medlemmar, create a group, tick the permissions and assign it to members.

Capability inheritance – the key mechanism

When Alice is a chain admin for "Burger Buffet Holding" (with 5 restaurants), the following happens:

1. She's a member of the Admin group in the chain
2. The Admin group has implicit admin.* wildcard
3. When Alice tries to open /admin for any of the 5 units, the system checks:
   • Is Alice a direct member of the restaurant? No.
   • Is she a chain admin for the chain the restaurant belongs to? Yes.
   • → Grant access.

Result: Alice can manage menu, void orders, give discounts, manage staff across all 5 units without being explicit restaurant_member anywhere.

Chain-scoped rights

Beyond inherited admin rights, there are specific rights for chain functions:

The Admin group has all of these. A custom group gets precisely the ones you tick.

Two guards you cannot accidentally get around

The permission system is built so a delegated role can never negotiate itself upwards:

• You cannot grant a permission you lack yourself. Give someone the right to manage permission groups and they can build groups — but only with permissions they already hold. Without that guard, a menu editor could have given their own group the right to read staff salaries and personal identity numbers across the whole chain.
• The administrator group is locked. Nobody except an existing chain admin can create a new admin group, flip their own group to admin, delete the admin group, or move themselves into it.

Both checks live in the database. They apply even if someone talks straight to our API, bypassing the interface.

⚠️ The save button only applies what you changed. When you edit a group's permissions, the difference is sent — not the whole list rewritten. That is deliberate: had we deleted everything and rewritten it, a delegated role would have locked itself out the moment it removed its own right to manage groups.

Add a member

1. Go to /chain/:slug/medlemmar
2. Click "Add member"
3. Search for user (name or phone)
4. Select the user
5. Assign permission group — Admin, or a custom group you built
6. Click "Add"

The user gets immediate access to the chain console at next login.

Example: Add a regional manager

Bob is regional manager for the Stockholm area at "Burger Buffet Holding AB". Alice (the chain owner) wants him to be able to:

• See consolidated analytics
• Manage menu templates and publish
• Not change sharing flags

Create a "Regional manager" group with View analytics and Manage menu templates ticked, but not Manage settings. Put Bob in that group. He gets exactly what he needs — and cannot change the chain's sharing flags.

Remember the guard: you can only tick permissions you hold yourself.

Deactivate vs remove

Deactivate (soft removal):

• Member is marked inactive
• User loses access to the chain
• Data preserved (can be reactivated later)

Remove (permanent removal):

• Membership is fully deleted
• Permanent – cannot be undone from the UI

Use "deactivate" for temporary pauses (e.g. parental leave) and "remove" when someone leaves entirely.

Chain admin vs restaurant admin – when to use what?

Access to local data vs chain data

• Chain admin → sees all chain data + all data in all member restaurants
• Restaurant admin (local) → only sees their restaurant, no chain data
• Restaurant admin in restaurant belonging to chain → sees their restaurant + chain menu template (read-only) + lock icons

Security and access control

All access is validated directly in the database, not just in the UI. That means even if someone tries to talk directly to our API, they won't see data they don't have rights to. Read more in Chain – Security and Access Control.

Future development

• Custom permission groups (role builder)
• Group-specific rights (choose exactly which are included)
• Role-based templates (e.g. "Restaurant manager", "Menu manager", "Finance director")
• Per-restaurant permission in a chain member

Next step: Read about shared menu template – one of the most used features.