Manual for In-App Admins

What the admin role is — and is not

As an in-app admin you manage user accounts and roles within a tracker instance. That is an application role, not server access.

If you use the portal, your instance runs on someone else's server as a free favour — with no SLA and no guarantees. Being an admin in the tool therefore does not mean you technically control the data yourself. Anyone who wants real data sovereignty runs the container on their own infrastructure (see Self-Hosting).

User management

In user management you create, edit, and delete accounts, assign roles, and reset passwords when needed. For testing you can create demo users.

User management is deliberately kept separate from the keyholder overview: control directives and account administration are two distinct tasks and live in separate areas.

Taking on a keyholder

There is no e-mail invitation — you create the account by hand, in the portal under Dashboard → your instance → Tracker users or inside the instance under Users → New user. You pass the credentials on to her, and she changes the password herself afterwards.

If she is to administer the instance, set her role to "admin" (Users → the person → Settings → Role) and then demote yourself to "user"; the last remaining admin cannot do this. She can direct you without your demotion as well — but for a wearer with the admin role the keyholder inbox rows are omitted, while mail and push continue unchanged.

Keyholder without user management

If she is to direct you but not administer accounts, give her the role "user" and assign her as keyholder under Users → your account → Settings → Keyholder. That gives her all keyholder powers over your account but no access to instance administration.

Only an admin can make the assignment, which means you, as long as you still are one. The assignment hangs on no role and therefore holds even if you stay an admin.

Global and scoped admins

By default a global admin sees all users of the instance. If the instance is restricted to assigned relationships (the `USE_ADMIN_RELATIONSHIPS` configuration flag), an admin sees only their assigned users; admins always remain in the list, even without an assignment.

This lets an instance with several admins be cleanly partitioned instead of giving every admin insight into all accounts.

Admins in the keyholder list

When you open the keyholder management for a sub, every admin is already listed there as an implicit, read-only entry — an admin sees that sub's data through their role anyway, not through an assignment.

An admin therefore cannot additionally be assigned as a keyholder. To give someone an explicit keyholder assignment, create their account with the role "user". The list is part of user management and is visible to admins only. The sub learns nothing of this: the tracker never tells them who can see their data — if they should know, tell them.

Role-aware portal

The portal title adapts to your role: acting as a keyholder you see the "Keyholder Portal"; in the administration view the "Admin Portal".

This makes it clear at any moment which context you are working in, and the two areas of responsibility do not blur together in the interface.

Per-user notifications

As an admin you manage the notification settings of individual users. This lets you, for a specific account, enable or disable particular event types.

This complements the sub's own self-service and is useful when central notification defaults are desired.

Enforce a mandatory device

Through the admin role a mandatory device is not only set as a directive but enforced: if a wrong device is worn and detected, the system marks it automatically.

This goes beyond the plain keyholder directive, where the device is only named as a requirement but not enforced system-side.

Setting up the photo check

The automatic photo check reads the inspection code in the photo, checks the seal number and identifies the device. It is off by default. You switch it on under “Settings” → “Photo checking”; only an admin sees this section, because the setting applies to the whole instance.

The simplest route is Anthropic, which the check is tuned for. At platform.claude.com you create an account, top up credit and create a key under “API Keys”; it is shown only once. In the app you choose “Anthropic (Claude)”, paste the key into the “API key” field and leave both model fields empty, so the defaults apply.

Before saving, tap “Test setting”. The app checks the setting against a sample photo: it has to recognise the correct code and reject a wrong number. If it reports that the provider rejected the key, the key was copied incorrectly or the account has no credit. Then save.

The costs run through your own account with the provider. The photos go there for the check, and subs see this from the ⓘ next to the photo field. Instead of Anthropic you can choose OpenAI, Google Gemini, Mistral, another OpenAI-compatible service or your own server with Ollama. Other models may read handwriting less reliably, so testing first matters all the more there.

Portal instances that existed before tracker 6.2.5 ran the check on the portal operator's key. That transition lasts 30 days after the instance's update; while it runs, the end date is shown in the “Photo checking” section. After that the check is off until a key of your own is stored. Without the check, inspections keep working and the keyholder assesses the photo by eye.

Operations and configuration

Topics such as feature flags and global language settings touch the operation of the instance. They are only touched on briefly here because they go beyond pure application administration.

For installation, configuration, and actual server operation, the existing Self-Hosting page is the authoritative source. Please consult that documentation for all operational topics.