User Groups and Access Control

🔒 Admin only. This page documents administrator features. Configuration lives in config.yaml and the in-app Config editor (/admin/config), which are only available to administrators.

Lumen uses a group-based system to assign coin budgets. config.yaml carries a single user-management section: admins:. Everything about groups — coin pools, memberships (users and projects), and login auto-join rules — lives in the database and is managed on the Groups pages.

Admins

Admins have full access to the Lumen interface, including the ability to create projects, view all usage data, and manage all users. Add admin emails under admins:

admins:
  - admin@example.com
  - another@example.com

The dev_user setting in app provides a login bypass for development — the specified email logs in directly without OAuth:

app:
  dev_user:
    email: dev@example.com
    groups:
      - staff

app.dev_user.groups still works: the listed groups are assigned to the dev user at login; names that don't match an existing group are ignored. To make the dev user an admin, add their email to the top-level admins: list. Group membership does not grant admin status.

dev_user is for development only and should be removed in production.

Auto-join Rules

Login auto-assignment is configured per group on the group detail page's Rules tab (admin-only) — see Group Management. A user matching all of a group's rules (AND logic) is added to the group at sign-in and removed again when they stop matching.

Rules match against fields in the user's OAuth identity-provider profile:

Field	Available Values	Example
`affiliation`	Email-style affiliations from the identity provider	`staff@illinois.edu`, `student@edu.org`
`idp`	Identity provider URN	`urn:mace:incommon:uiuc.edu`
`member_of`	Group membership reported by the identity provider	`icc-grp-aifarms`
`ou`	Organizational unit	`research@university.edu`

A login that matches no auto-join group is logged at WARNING level with the user's email, affiliation and IdP; find these with grep "No auto-join group matched" in the application logs.

Rules can use two matcher types:

Matcher	Behavior	Example
`contains`	Case-sensitive substring match	`contains: staff@illinois.edu`
`equals`	Exact match	`equals: urn:mace:incommon:uiuc.edu`

There is no group_rules: section in config.yaml — rules exist only in the database. A leftover section from an older config is ignored with a startup warning; remove it and recreate the rules on each group's Rules tab.

Everything Else Lives in the Database

Config version 3 removed the groups: and users: sections. What they used to configure is now DB-managed:

Group coin pools (max/refresh/starting) — an admin sets a group's Max Coins and Refill Rate from the group's Edit dialog. Entities without their own pool fall back to their best group pool and then the top-level defaults.tokens block (see Admin Configuration).
Group memberships — owners and admins manage members on the group detail page; auto-join rules add members at login. Admins can also edit a user's groups from the Edit User dialog (see below).
Per-user coin pools — an admin sets a user's Max Coins and Refill Rate (and can enable/disable the account) from the Edit User dialog, opened from the pencil button on the Users page or the Edit button on the user's profile page (/admin/users/<id>/profile, or the admin's own /profile in admin mode).

The Edit User dialog's Groups field shows the user's groups as pills. Type part of a group name to get suggestions, then add one with a click or with the arrow keys and Enter. Remove a group with its ✕, or press Backspace in the empty field to remove the last one. Changes take effect only when you click Save. A pill with a lock icon can't be removed here: auto-join groups are managed by their rules, and a group's owner has to transfer ownership first. Auto-join groups are never offered as suggestions.

Groups and Model Access

Model access follows ownership: a model with no owner is available to everyone; an owned model is available only to its owner. Ownership is managed by admins on the model detail page (see Configuring Models) — never in config.yaml.

Acknowledgement is also not a group setting — it lives on the model via needs_ack; if an accessible model has needs_ack: true, members still acknowledge it once before use.