Manage logins for your organization

A login belongs to the organization, not to one application page. The engine supplies the page that manages logins, so no application declares one.

The page is at /matterdata and its interface is English. This guide names each control and says what it does.

Read Who administers an organization for what the tenant administrator flag is and what it does not grant.

Open the administration page

Open /matterdata on your organization’s own address:

https://my-club.matterdata.example/verwaltung

Only a login that carries the tenant administrator flag can open the page. Any other signed-in person gets a 403. No menu links to the page, so type the address.

The page has three tabs.

Tab	What it holds
Overview	six counts: logins, administrators, disabled logins, live sessions, due jobs, and failing jobs
Logins	every login of the organization, and the acts on it
Jobs	the job log, and the nightly reset of a demonstration organization

Overview also carries one sentence about whether this organization resets itself every night. Read Read the job log and Reset a demonstration organization every night for the Jobs tab.

Invite someone with a link

1. Open Logins and find Invite account.
2. Enter the recipient’s email address. This is their username when signing in.
3. Select a role for each application, or No role for no role in that application.
4. Press Invite account, then Copy link.
5. Share the link with the recipient yourself. The engine does not send email.

The recipient opens the link, chooses and confirms a password, then signs in with their email address. Passwords must contain 8 to 1024 characters. Setup also works without JavaScript. If copying is unavailable, select the link in its field and copy it manually.

An invitation expires after 7 days and can set a password once. Opening it does not consume it. The account shows Invitation pending and cannot sign in until a password is set. You can change its application roles before the recipient accepts. A pending account does not count toward the safeguard that prevents removing the last usable tenant administrator.

The link is shown only when generated. To replace a lost or expired link, press Generate new invitation link on the pending account. This invalidates the previous link. A disabled account cannot accept an invitation. Setting its password through the administrator’s password control also makes its invitation unusable.

Invitation creation and replacement appear in the audit log as admin.authority events. Successful setup appears as auth.invitation_accepted, attributed to the recipient and kept for 365 days. Neither event contains the link or password.

Create a login

1. Open Logins.
2. Find Zugang anlegen and type the address in E-Mail.
3. Select a role in Rolle. The list holds one application’s roles and No role.
4. Read the password in Passwort and write it down.
5. Press Zugang anlegen.

The password is shown once, and there is no invitation e-mail

The engine sends no email. You can copy an invitation link using the flow above. The generated password is on the screen before you save, and the page does not show it again. Write it down and hand it over yourself.

The password field is editable. Type your own password to use one you agreed by telephone. A password needs at least 8 characters. The generated one is 18 random bytes, so it is about 144 bits.

Four submissions are refused with a sentence, and none of them creates a login:

• a value that is not an e-mail address, or one longer than 254 characters.
• an address that another login already has.
• a role that your application does not declare.
• a password shorter than 8 characters.

A refused form keeps what you typed, the password included. Correct the field and press the button again.

An address is stored in lower case, so Chef@Example.org and chef@example.org are one login.

After creating the login, use its application role controls to grant or change access.

Which application the role applies to

A role belongs to one application. An organization can hold several, so the Rolle list is one application’s:

• An organization with one application offers that application’s roles.
• An organization whose applications include one at mount: / offers that application’s roles.
• Any other organization with several applications offers No role only, and a login created there holds a role in no application.

Change a role in an application

1. Find the login under Logins.
2. Find the role selector labeled with the application’s name.
3. Select a role, or No role to revoke access through that role.
4. Press Rolle speichern beside that selector.

Each save changes only that application. Existing sessions use the new role on their next request. Other applications’ roles and tenant administrator authority stay unchanged. Applications that failed to load have no role selector; repair the application before changing its roles.

You can grant yourself a role through the same controls. Every successful save records the administrator, target login, application, and selected role in the audit log, including self-grants.

Give a login no role at all

No role creates a login that can sign in and can open no page of the application. Use it for a person who administers the organization and needs none of its data.

The list of roles never offers the tenant administrator flag. Granting that authority is its own act on the login, so it can never be a side effect of a form.

Act on one login

Each login is one card under Logins. The card carries the role, the last sign-in, the number of live sessions, and a tag for each state: Verwaltung, Deaktiviert, Gesperrt bis …, and Ihr eigener Zugang.

The acts are buttons on that card. A destructive act sits in a closed disclosure, so it takes two deliberate presses. It needs no JavaScript.

Button	What it does
Zugang deaktivieren	the login cannot sign in. Its live sessions are rejected and deleted on their next request
Zugang aktivieren	the login can sign in again. The lockout counter is cleared with it
Neues Passwort setzen	replaces the password and clears the lockout. Sessions stay open
Alle Sitzungen beenden	every device must sign in again. The password does not change
Verwaltungsrechte geben	the login becomes a tenant administrator
Verwaltungsrechte entziehen	the login stops being a tenant administrator

A button that cannot apply is absent rather than disabled. A disabled login has no Zugang deaktivieren, an administrator has no Verwaltungsrechte geben, and a login with no live session has no Alle Sitzungen beenden.

New passwords and ended sessions are two acts on purpose. “They forgot their password” leaves their laptop signed in. “Their laptop was stolen” does not. Press both buttons when you mean both.

Keep one administrator

The last administrator cannot be removed. Verwaltungsrechte entziehen and Zugang deaktivieren are both refused for the last one, with this sentence:

Dies ist der letzte Zugang mit Verwaltungsrechten. Geben Sie zuerst einem anderen Zugang Verwaltungsrechte.

An organization with no administrator cannot administer itself. There is no higher authority inside its database, so the only way back is a command on the server.

Two properties of the rule are worth knowing:

• The count is of administrators that are not disabled. A disabled administrator does not hold the organization open. Demoting or disabling one is therefore refused while exactly one enabled administrator remains, although it takes nothing away.
• The count is inside the statement that changes the row. Two administrators who demote each other at the same moment cannot both succeed. The second one changes nothing and reads the sentence above.

You may take the flag away from your own login while another administrator remains. After that act the page redirects to the application’s home page, because you can no longer open /matterdata.

Grant the first administrator from the command line

matterdata install makes its first login a tenant administrator. install -demo flags exactly one login: the demonstration application’s own most privileged account.

A tenant installed with neither -email nor -demo has no login, so it has no administrator. Two commands set the flag on a tenant file directly:

matterdata grant-admin  -dir data -tenant my-club -email second@example.org
matterdata revoke-admin -dir data -tenant my-club -email former@example.org

Both take -tenant and -email, and both print how many administrators are left. -dir is the directory that holds one <subdomain>.db per tenant, and it defaults to data.

The authority here is the filesystem: whoever can read my-club.db can already read every password hash in it.

revoke-admin enforces the same last-administrator rule as the page, and it names the repair:

"chef@example.org" is the last administrator of my-club and cannot be removed: a tenant with
none cannot administer itself, and there is no higher authority inside its file. Grant one
first:
  matterdata grant-admin -dir data -tenant my-club -email <other address>

Use grant-admin for a tenant that was installed before the flag existed, and for one that reached zero administrators anyway.

What the audit log records

Every act on a login that succeeds writes one admin.authority event, and that class is kept forever. The acts on the Jobs tab write admin.command instead, which is kept for 365 days. The actor on the event is the administrator who performed the act. The subject is the login it was performed on.

Three cases record nothing, and each is deliberate:

• A refused act. The event is queued after the act succeeded, so the log cannot report something that did not happen.
• Reading the list of logins. Every act writes an event, so the list is reconstructable from the trail. An event per page view would put a row in a table that is never swept.
• grant-admin and revoke-admin. There is no session at the command line and therefore no actor to record. The effect is visible on the page; who caused it belongs to the server’s own record.

Read Security model for the other classes and their retentions.