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)

In the future, you'll be able to create custom groups (e.g. "Regional manager", "Menu editor"). In the MVP, only the Admin group exists.

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:

In the MVP, the Admin group has all these. In the future, custom groups can have subsets.

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 in MVP)
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

In MVP: Bob is added to the Admin group (gets everything). Future solution: create a "Regional manager" group with a subset of rights.

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.