TribeManager Admin Manual

Every organization starts with the vCard-aligned default fields. In basic mode a contact carries just its name (FN) - enough to tell contacts apart and link them to events, tasks, and the rest.

Every organization starts with four participation roles, named after the calendar standard’s own: chair, required, optional, and observer. They are ordinary data - rename them to whatever your organization actually says, and the export keeps working, because each role carries the standard role it maps to.

Set up one account per real place money sits - a bank account, a cash box - and one per currency: an account holds a single currency, so its balance is a number rather than a table.

Build the category tree under the two fixed roots, income and expense. They are fixed because the income statement is income minus expenses, and a third root would be a figure the report has no line for. Below them the tree is entirely yours, as coarse or as detailed as you want.

Membership-fee rules, dunning, and SEPA mandates are not part of the basic surface and are not built yet.

File content is kept in the database by default, so a single pg_dump backs up your contacts, your books, and your files together. That is a deliberate choice for self-hosting: the most common way to lose documents is to back up the database and forget the file directory.

tribemanager.documents.max-size-bytes sets the largest file the instance accepts - 25 MiB by default. It is the one limit in TribeManager that refuses rather than warns, because it protects the instance itself. Raise it if your organization genuinely needs to, and raise quarkus.http.limits.max-body-size with it, or uploads will be rejected before the application can explain why.

Invitations, updates, cancellations, and reminders are sent through an SMTP relay you point the instance at - your own mail server, your provider’s, anything that speaks SMTP. No mail service is required and none is contacted unless you configure one.

If a message cannot be delivered, the failure is logged and the work that caused it stands: an invitation that bounced is a mail problem, and it never undoes the participation it belonged to.

The development stack (compose.dev.yaml) includes Mailpit at http://localhost:8025. It accepts everything the application sends, shows it in a web page, and delivers nothing onwards - so you can see exactly what an invitation looks like without a real mailbox, or a real recipient, being involved.

In advanced mode the Contact fields screen pre-configures the everyday default fields - structured name, email, phone, address, birthday - on top of the mandatory name. You can:

No field change loses data: deactivating or deleting only hides a field; its history remains.

Every organization ships with a default relationship-type vocabulary (member, customer, supplier, partner, donor, venue). Only the member type carries a status; you can extend the vocabulary with your own types via the API (PUT /api/v1/relationship-types/{name}).

The participation roles your organization uses are yours to name. The four that ship - chair, required, optional, observer - carry the mapping the calendar standard expects, and so does any role you add, which is why a locally invented vocabulary still exports and imports losslessly.

Advanced finance administration is in place: fee rules attached to relationship types and statuses, matching payments against expectations, and bank-statement import in camt.053. Dunning is designed but not built. The basic surface (accounts, categories, entries, the income statement) is complete and is what an organization needs to keep books today.

The German donation receipt and the access-request document live in a compliance module you can replace. What it needs from you is the handful of facts a statutory form names and the contact model does not carry:

Leaving one empty is allowed. It appears on the document as a visible gap, which somebody can see and fill in; a receipt that quietly omitted the tax office would be worse.

Expert mode exposes the full contact field configuration:

Shipped default fields can be deactivated but not deleted (they would only be recreated); fields you add can be deleted outright.

Expert mode hands over the relationship vocabulary itself. Under Relationship types you decide which kinds of connection between your organization and its contacts exist - member, supplier, sponsor, whatever your organization actually has - which contact kinds each applies to, and whether it carries the member status lifecycle (applicant, active, passive, honorary, resigned).

The name is the key: writing a name that already exists redefines that type, a new name adds one. There is no delete - a type contacts were connected with is part of the record, and advanced mode simply uses the shipped vocabulary as it is.

A complexity mode changes what is shown, never what is stored. Raising a module to expert exposes more configuration; lowering it again hides that configuration and the fields it created, and deletes nothing. So there is no risk in trying a higher mode, and no migration when you leave it.