Ein oder mehrere Mandanten

Eine fepli-Installation kann eine Organisation bedienen oder viele. Jede Organisation ist ein Mandant mit eigenen Domains, Admins, Einstellungen und Daten. Diese Seite erklärt beide Varianten und zeigt, wie Sie den ersten Mandanten und den ersten Admin anlegen. Das geht nur auf der Kommandozeile.

Mandanten

Ein Mandant ist eine Organisation, die fepli nutzt, etwa eine Kommune mit ihrem Ferienpass, ein Verein oder eine Bibliothek. Er hat:

• einen Slug, seinen maschinenlesbaren Namen, z. B. elmsbrueck,
• einen Namen, z. B. „Ferienpass Elmsbrück“, der auch als Absender seiner E-Mails erscheint,
• seine Domains,
• eigene Admins, Veranstalter:innen, Familien, Angebote, Einstellungen und CMS-Seiten.

Alle Mandanten einer Installation teilen sich eine Datenbank, und fepli hält ihre Daten getrennt. Eine Familie, die bei Elmsbrück registriert ist, existiert für Beispielhausen nicht, und ein Admin des einen Mandanten sieht den anderen nicht. Im CMS, das alle Mandanten gemeinsam nutzen, bearbeiten die Super-Admins eines Mandanten nur ihre eigene Website: siehe Dem Mandanten eine Website geben.

Eine eigene Version für einen einzelnen Mandanten gibt es nicht: Jedes Image ist gleich. Ob eine Installation einen oder mehrere Mandanten hat, hängt nur davon ab, wie viele Mandanten Sie anlegen und ob Sie die Plattform-Konsole einschalten.

Beginnen Sie mit einem einzelnen Mandanten, wenn Sie unsicher sind. Eine Plattform-Konsole und weitere Mandanten können Sie jederzeit ergänzen, ohne Daten zu verschieben.

Domains

Jeder Mandant beansprucht die Domains, unter denen er erreichbar ist. Eine Domain liefert eines von zwei Dingen aus:

• Ein öffentlicher Host liefert die Website des Mandanten und unter /admin sein Admin-Panel aus. Das ist der Normalfall: https://example.fepli.eu und https://example.fepli.eu/admin.
• Ein Admin-Host liefert nur das Admin-Panel aus, an der Wurzel der Domain und ohne /admin. Sobald ein Mandant einen Admin-Host hat, liefern seine öffentlichen Hosts das Admin-Panel nicht mehr aus.

Zwei weitere Domains beantworten keine Anfrage und gehören deshalb nicht in TRUSTED_HOSTS: die Domain, von der die E-Mails eines Mandanten verschickt werden (der Zweck E-Mail-Versand), und die Domain, an der Antworten auf seine Nachrichten ankommen. Ein Mandant trägt sie als Einstellung der App Antworten per E-Mail ein und nicht als Domain mit Zweck: siehe E-Mail-Antworten.

Eine Domain ist je Zweck eindeutig: Der Schlüssel besteht aus der Domain und ihrem Zweck. Eine Domain gehört einem Mandanten, für jeden Zweck, und ein Mandant trägt sie je Zweck einmal ein. Sie beantwortet Anfragen für genau einen Zweck. Einzige Ausnahme ist E-Mail-Versand: Dieser Zweck darf auf derselben Domain liegen wie ein anderer, damit ein Mandant von der Domain seiner Website senden kann. Eine solche Domain hat zwei Zeilen. Eine Anfrage an sie erreicht die Zeile, die über HTTP ausgeliefert wird, nie die für den E-Mail-Versand.

Eine Anfrage an eine Domain, die kein Mandant beansprucht, beantwortet fepli mit 404, bevor irgendetwas anderes geschieht. Einen Standardmandanten gibt es nie. Wenn Sie eine Domain hinzufügen, tragen Sie sie deshalb an zwei Stellen ein: beim Mandanten und in TRUSTED_HOSTS.

Links in E-Mails führen zu den Domains des Mandanten, zu dem das Konto oder der Datensatz gehört, um den es geht. Das gilt für Anmeldelinks, Einladungen, den Link zum Setzen eines neuen Passworts, den ein Admin verschickt, den Link zur Bestätigung einer neuen Anmeldeadresse und jeden Link in einer E-Mail, die der Worker schreibt. Es spielt keine Rolle, von wo die E-Mail verschickt wurde, auch nicht, wenn es die Plattform-Konsole, eine API-Domain oder die Domain eines anderen Mandanten war. Ein Link ins Admin-Panel führt zum Admin-Host des Mandanten, wenn er einen hat, sonst zu /admin auf seinem öffentlichen Host. Ein Link zur Website, etwa der Anmeldelink einer Familie, führt zum öffentlichen Host. APP_BASE_URL ist nur der Ausweichwert für einen Link ohne Mandanten oder für einen Mandanten ohne passende Domain.

In Benachrichtigungstexten ist {{ baseUrl }} die Adresse des Hosts, von dem die E-Mail verschickt wurde, sofern das ein öffentlicher Host oder ein Admin-Host des Mandanten ist. Wurde die E-Mail von einem anderen Host verschickt, ist es der öffentliche Host des Mandanten, und wenn er keinen hat, sein Admin-Host.

Wenn Sie einem Mandanten seinen ersten Admin-Host geben, zieht sein Admin-Panel um: Von da an antwortet /admin auf seinen öffentlichen Hosts mit 404. Einladungen und Anmeldelinks, die vorher verschickt wurden, zeigen dorthin und funktionieren nicht mehr. Verschicken Sie offene Einladungen und Anmeldelinks erneut, sobald der Admin-Host eingerichtet ist.

Mandanten, die ihre Angebote einbetten

Ein Mandant kann seine Angebote mit den Bausteinen auf der Website eines anderen zeigen und im CMS keine eigene Website haben. Familien kommen trotzdem zu fepli, um sich anzumelden: Die Schaltfläche zum Anmelden in den Bausteinen führt zur Seite des Angebots, von dort zur Anmeldung, zu den Anmeldungen der Familie und zur Zahlung. Diese Seiten liegen auf einem öffentlichen Host, ein einbettender Mandant braucht also einen. Zwei Aufteilungen funktionieren:

• Eine Domain. Der öffentliche Host liefert die Seiten aus, auf denen sich Familien anmelden, und unter /admin das Admin-Panel. Ohne Website im CMS gibt es keine Startseite, deshalb leitet / zur Anmeldung im Admin-Panel weiter.
• Zwei Domains. Ein öffentlicher Host für Familien und ein Admin-Host mit dem Admin-Panel an der Wurzel.

Ein Admin-Host allein kann Familien nicht bedienen: Alles darauf ist das Admin-Panel. Die Bausteine würden die Angebote auflisten, aber ihre Schaltfläche zum Anmelden führte ins Leere. Die Vorschau der Domains auf der Seite des Mandanten weist darauf hin.

Die Bausteine sind ausgeschaltet, bis der Mandant sie einschaltet, mit der App Website einbinden unter Einstellungen → App-Store. Ausgeschaltet beantwortet /embed.js auf jedem Host des Mandanten die Anfrage mit 404. Auch im Wartungsmodus antworten sie nicht, und auf der Plattform-Konsole nie.

Die Plattform-Konsole

In einer Installation mit mehreren Mandanten verwalten Sie in der Plattform-Konsole die Installation selbst. Sie hat eine eigene Domain, z. B. platform.example.fepli.eu, die FEPLI_PLATFORM_HOST festlegt. Sie gehört zu keinem Mandanten und liefert nur das Admin-Panel aus, an der Wurzel der Domain.

Nur globale Admins können sich dort anmelden. Sie sehen:

• Installation → Mandanten: die Liste der Mandanten, mit Mandant anlegen, um einen anzulegen, und dem Schalter, der einen Mandanten offline nimmt. Siehe Einen Mandanten anlegen.
• Wechseln: in einen Mandanten wechseln, um in dessen Admin-Panel zu arbeiten.
• CMS in der oberen Leiste: das CMS des Mandanten, in den sie gewechselt haben, auf seinem öffentlichen Host, ohne erneute Anmeldung. Dort verwalten sie das ganze CMS. Das Protokoll des Mandanten unter Betroffenenrechte hält CMS dieses Mandanten geöffnet fest, und Admin-Panel im CMS führt zurück zur Konsole.
• Installation → Systemwerte: die Werte, die alle Mandanten teilen, etwa die Absenderadresse der Installation (Absenderadresse der Installation) und der Wartungsmodus, der die Website jedes Mandanten hinter eine Wartungsseite stellt. Das Admin-Panel bleibt erreichbar, ebenso die Dateien, die es zum Download anbietet.

Auf einer neuen Installation ohne Mandanten zeigt die Konsole nur die Liste der Mandanten, bis der erste Mandant existiert.

Befehle im Container ausführen

Den ersten Admin legen Sie mit einem Konsolenbefehl im Web-Container an. Mit Docker Compose stellen Sie jedem Befehl auf dieser Seite docker compose exec web voran:

docker compose exec web php bin/console ferienpass:tenant:list

Andere Plattformen haben ihren eigenen Weg, eine Shell in einem laufenden Container zu öffnen (kubectl exec, das Terminal von Dokploy oder Coolify, …). Führen Sie die Befehle in /app aus, dem Verzeichnis, in dem der Container startet.

In einer Installation mit mehreren Mandanten wirkt ein Befehl auf alle Mandanten, sofern Sie keinen nennen: mit --tenant=<slug>, das jeder Befehl annimmt, oder mit der Umgebungsvariable FEPLI_TENANT für eine ganze Shell-Sitzung.

Einen einzelnen Mandanten einrichten

Legen Sie den Mandanten mit seinen öffentlichen Hosts an und danach seinen ersten Admin:

php bin/console ferienpass:tenant:create elmsbrueck "Ferienpass Elmsbrück" \
  --host=example.fepli.eu \
  --host=www.example.fepli.eu

php bin/console ferienpass:user:create anna.schmidt@example.fepli.eu \
  --tenant=elmsbrueck --firstname=Anna --lastname=Schmidt

Der zweite Befehl fragt zweimal nach dem Passwort. Der Admin ist Super-Admin von Elmsbrück: Er darf im Admin-Panel alles, auch Zahlungen, Teilnehmer:innen und das CMS, und lädt von dort alle anderen ein. Er meldet sich unter https://example.fepli.eu/admin an.

Danach geben Sie dem Mandanten eine Website.

Mehrere Mandanten einrichten

1. Setzen Sie FEPLI_PLATFORM_HOST auf die Domain der Konsole, tragen Sie diese Domain in TRUSTED_HOSTS ein und starten Sie die Container neu.

2. Legen Sie einen globalen Admin an. Er gehört zu keinem Mandanten und braucht daher kein --tenant:

   Globalen Admin anlegen

   php bin/console ferienpass:user:create you@example.org --global-admin
   

   Kopieren

3. Melden Sie sich unter https://platform.example.fepli.eu an und legen Sie die Mandanten mit ihren Domains unter Installation → Mandanten → Mandant anlegen an. Oder legen Sie sie wie bei einem einzelnen Mandanten auf der Kommandozeile mit ferienpass:tenant:create an.

4. Geben Sie jedem Mandanten seinen ersten Admin: Wechseln Sie in den Mandanten und legen Sie seine Admins dort an, oder verwenden Sie ferienpass:user:create mit --tenant.

5. Geben Sie jedem Mandanten eine Website.

Einen Mandanten anlegen

Mandant anlegen fragt nach dem Namen, nach dem Kürzel, das sich später nicht mehr ändern lässt, und danach, wofür die Hauptadresse des Mandanten dient:

Bausteine aktivieren schaltet die Bausteine des Mandanten von Anfang an ein. Die Option ist für einen Mandanten ohne Website vorgeschlagen, der seine Angebote anderswo zeigt, und bleibt so, wie Sie sie eingestellt haben, sobald Sie sie selbst umschalten. Die Bausteine lesen aus der API, deshalb ist API aktivieren eingeschaltet, solange sie es sind.

Vorschau Domains unter der Adresse zeigt, womit jede Adresse antwortet, auch mit dem Skript der Bausteine. Bei einem Mandanten ohne Website, der einbettet, steht an der Hauptadresse Anmeldung für Familien (kein Direktzugang): Familien erreichen sie über den Link eines Angebots, und / führt zur Anmeldung im Admin-Panel. Weitere Adressen, etwa ein Admin-Host oder eine Domain für E-Mails, fügen Sie im selben Formular hinzu. Offline anlegen hält den Mandanten unerreichbar, bis Sie ihn freigeben.

Globale Admins haben in jedem Mandanten, in den sie wechseln, die Rechte eines Super-Admins. Die personenbezogenen Daten der Familien des Mandanten bleiben für sie standardmäßig maskiert. Halten Sie ihre Zahl klein.

Die Befehle

• Name

  ferienpass:tenant:create

  Typ

  slug name

  Beschreibung

  Legt einen Mandanten an. Der Slug steht in Kebab-Case (elmsbrueck, bad-musterbach) und lässt sich später nicht ändern. --host fügt einen öffentlichen Host hinzu, --admin-host einen Admin-Host. Beide Optionen lassen sich wiederholen.

• Name

  ferienpass:tenant:list

  Beschreibung

  Listet die Mandanten auf: Slug, Name, öffentliche Hosts und Admin-Hosts und ob sie online sind.

• Name

  ferienpass:user:create

  Typ

  email

  Beschreibung

  Legt einen Super-Admin an. --tenant=<slug> nennt den Mandanten, zu dem er gehört, --global-admin macht ihn stattdessen zum Admin der Installation. --firstname und --lastname sind optional.

Passwörter:

• Interaktiv ausgeführt, fragt ferienpass:user:create nach dem Passwort.
• Ohne Terminal ausgeführt, etwa aus einem Skript oder mit docker compose exec -T, erzeugt der Befehl ein Passwort und gibt es einmal aus. Ändern Sie es nach der Anmeldung.
• --password=… funktioniert auch, hinterlässt das Passwort aber in Ihrem Shell-Verlauf und in der Prozessliste. Verwenden Sie lieber die Eingabeaufforderung.

Eine E-Mail-Adresse ist pro Mandant eindeutig, nicht pro Installation. Dieselbe Person kann also mit zwei Konten Admin von zwei Mandanten sein.

Dem Mandanten eine Website geben

Die öffentliche Website eines Mandanten ist ein Seitenbaum im CMS, den das Admin-Panel in der oberen Leiste unter CMS öffnet. Der Baum jedes Mandanten beginnt bei genau einer Wurzelseite, und die Wurzelseite legt fest, zu welchem Mandanten sie gehört. Solange der Mandant keine veröffentlichte Wurzelseite hat, hat seine Domain keine Website, obwohl sein Admin-Panel funktioniert: / leitet zur Anmeldung im Admin-Panel weiter, und die Seiten, auf denen sich Familien anmelden, erscheinen in einem schlichten Layout, das fepli mitbringt. So läuft auch ein Mandant, der seine Angebote einbettet, dauerhaft. Ein Mandant mit nur einem Admin-Host hat keine Website und braucht keine Wurzelseite.

Das CMS hat kein Template Studio: Die Templates von fepli kommen mit dem Image.

Ein Mandant

In einer Installation mit einem Mandanten verwalten seine Super-Admins das gesamte CMS. Sie legen die Wurzelseite selbst an:

1. Melden Sie sich im Admin-Panel des Mandanten an und öffnen Sie CMS in der oberen Leiste.
2. Wechseln Sie zu Seiten und legen Sie eine Seite vom Typ Startpunkt einer Webseite an.
3. Geben Sie als Domainname den öffentlichen Host des Mandanten ein, z. B. example.fepli.eu, als Sprache de, und wählen Sie den Mandanten unter Mandant aus.
4. Veröffentlichen Sie die Seite und bauen Sie die Seiten darunter auf.

Mehrere Mandanten

Sobald eine Installation einen zweiten Mandanten hat, auch einen deaktivierten, hält das CMS die Mandanten auseinander. Die Super-Admins eines Mandanten bearbeiten dann:

• die Seiten und Artikel ihrer eigenen Website, die Wurzelseite eingeschlossen, aber nicht den Mandanten, zu dem sie gehört,
• die Dateien im eigenen Ordner des Mandanten, files/<slug>, z. B. files/elmsbrueck,
• die Formulare und FAQ-Kategorien des Mandanten mit ihren Feldern und Fragen. Sie können beides anlegen und löschen, aber nicht festlegen, dass ein Formular seine Eingaben in einer Datenbanktabelle speichert.

Ein Formular oder eine FAQ-Kategorie gehört zu einem Mandanten oder zur Installation. Ein neues gehört zu dem Mandanten, für den es angelegt wird: dem Mandanten des Super-Admins, der es anlegt, oder, wenn ein globaler Admin es anlegt, dem Mandanten, auf dessen öffentlichem Host das CMS läuft. Globale Admins übergeben es unter Mandant an einen anderen Mandanten oder an die Installation. Dieses Feld sehen nur sie.

Themes, Layouts und Frontend-Module gehören zur ganzen Installation, und nur globale Admins ändern sie. Die Super-Admins eines Mandanten können die Inhaltselemente Ungefiltertes HTML, Inhaltselement, Artikel und Artikelteaser nicht verwenden. Elemente dieser Typen, die schon auf ihren Seiten stehen, bleiben erhalten, aber sie können sie nicht ändern.

Die Super-Admins eines Mandanten können auch keine Wurzelseiten hinzufügen. Wenn einer von ihnen zum ersten Mal CMS im Admin-Panel des Mandanten öffnet, bereitet fepli deshalb die Website vor:

• Eine vorhandene Wurzelseite, die keinen Mandanten nennt und einen öffentlichen Host des Mandanten trägt, wird die Wurzelseite des Mandanten.
• Andernfalls legt fepli eine Wurzelseite für den Mandanten an: nach ihm benannt, auf seinem ersten öffentlichen Host, mit der Sprache de und dem ersten Layout der Installation, und nicht veröffentlicht.
• fepli legt den Ordner files/<slug> an.

Danach veröffentlicht der Super-Admin die Wurzelseite und baut die Seiten darunter auf.

Jedes Mal, wenn einer von ihnen CMS im Admin-Panel des Mandanten öffnet, werden Formulare und FAQ-Kategorien der Installation zu denen des Mandanten, wenn sie eindeutig zu seiner Website gehören: eine FAQ-Kategorie, deren Leseseite Teil davon ist, und ein Formular, das nur Artikel seiner Website zeigen. Was weniger eindeutig ist, bleibt bei der Installation, etwa ein Formular, das eine andere Website oder ein Frontend-Modul zeigt: Ein globaler Admin weist es zu oder kopiert ein gemeinsames Formular für jeden Mandanten. Formulare und FAQ-Kategorien aus Versionen, die noch keinen Mandanten kannten, gehören zunächst zur Installation und finden ihren Mandanten auf demselben Weg.

Die Super-Admins eines Mandanten erhalten diese Rechte bei ihrer nächsten Anfrage im CMS, nachdem der zweite Mandant angelegt wurde. Dateien, die vorher hochgeladen wurden, bleiben auf ihren Seiten in Gebrauch, aber der Dateimanager zeigt ihnen nur, was in files/<slug> liegt.