Mitglieder und Teams

Rollen

Jedes Mitglied einer Organisation hat genau eine Rolle auf Organisationsebene.

Eine Organisation muss jederzeit mindestens einen Owner haben. Den letzten Owner kannst du weder entfernen noch herabstufen.

Wann du ein zahlender Nutzer bist

Eine Regel deckt alle oben genannten Rollen ab:

Du belegst einen zahlenden Nutzer, wenn du irgendwo schreiben kannst. Ist alles, was du hast, schreibgeschützt – oder hast du gar nichts –, bist du kostenlos. Die einzige Ausnahme ist das Team Auditors: Seine ersten 5 Mitglieder mit Lesezugriff sind kostenlos, jedes weitere ist ein zahlender Nutzer.

Abgesehen von Auditors entscheidet darüber die Berechtigung, die deine Teams vergeben, nicht ihr Name. Ein schreibgeschütztes Team, das du selbst anlegst, ist also in jedem Umfang kostenlos, und das Umbenennen eines Teams ändert nie, was du zahlst. Owner, Mitglieder und Collaborators können schreiben und sind daher zahlende Nutzer; Leser und Gäste können es nicht und sind es daher nicht.

Mitglieder einladen

Die Mitgliederverwaltung findest du in der Verwaltungsoberfläche von fremforge unter /<org>/_admin/members – die Seite Mitglieder listet jedes aktuelle Mitglied mit einem eigenen Verwalten-Bereich und oben einem Dialog zum Einladen. Die Forgejo-eigene Seite frem.sh/org/<org>/teams bleibt als Ausweichweg verfügbar, wenn du Teamberechtigungen feiner zusammenstellen musst; die Seite im Produkt deckt den täglichen Ablauf aus Einladen, Rolle ändern und Entfernen ab.

1. Öffne Organisationsverwaltung → Mitglieder (/<org>/_admin/members).
2. Klicke auf Per E-Mail einladen.
3. Gib den Benutzernamen oder die E-Mail-Adresse der eingeladenen Person ein und wähle eine Rolle.
4. Klicke auf Einladung senden.

Die eingeladene Person erhält eine E-Mail von noreply@frem.sh mit einem Link zum Annehmen. Der Link ist 7 Tage gültig. Läuft er ab, sende ihn im Bereich Offene Einladungen auf derselben Seite erneut.

Im Bereich Offene Einladungen erscheint die eingeladene Person als Ausstehend, bis sie annimmt. Ausstehende Mitglieder:

• Können auf keine Ressource der Organisation zugreifen.
• Zählen nicht als zahlender Nutzer, bis sie die Einladung annehmen.
• Können jederzeit storniert werden, indem du sie, solange sie ausstehen, aus dem Team entfernst.

Sobald die Person annimmt, wechselt ihr Status auf Aktiv, und sie wird ab dem nächsten Abrechnungszyklus zur Zahl der zahlenden Nutzer hinzugerechnet. Aktivität ist nicht nötig; was zählt, ist die Annahme.

Kostenlose Leser (nur Lesezugriff, kein zahlender Nutzer)

Ein Leser hat Lesezugriff auf die Repositorys, für die er freigeschaltet ist – klonen, Code durchsuchen, Issues und Pull Requests lesen –, kann aber nicht pushen, keine Repositorys anlegen und die Verwaltungseinstellungen der Organisation nicht erreichen. Leser sind kostenlos: Sie zählen nicht gegen dein Nutzerlimit und werden nie abgerechnet. Füge so viele hinzu, wie du willst – Stakeholder, externe Kräfte, die nur hineinschauen müssen, schreibgeschützte Dashboards und so weiter. Wer zusätzlich die Einstellungen deiner Organisation lesen muss, etwa ein Compliance-Prüfer, gehört stattdessen zu den Auditoren.

Technisch ist ein Leser Mitglied im kanonischen Team Viewers der Organisation und in keinem Team, das Schreibzugriff gewährt. Die Nutzerzählung folgt der Berechtigung, die ein Team gewährt, nicht seinem Namen: Hast du nur schreibgeschützte Teams, bist du kostenlos; hast du irgendwo Schreibzugriff, wirst du abgerechnet. (Fügst du jemanden zu Viewers und Members hinzu, wird er abgerechnet – Schreiben gewinnt.)

Weil die Regel auf der Berechtigung beruht statt auf dem Namen, ist auch ein schreibgeschütztes Team, das du selbst anlegst – Stakeholders, Reviewers, wie auch immer du es nennst –, kostenlos, und daran ändert sich nichts, wenn du es auf eine Handvoll Repositorys beschränkst. Nimm Guests, wenn du genau das willst: kostenlosen Lesezugriff auf ausgewählte Repositorys. Das kanonische Team Auditors gehört nicht dazu: fremforge legt es an, es erreicht neben dem Code auch die Einstellungen der Organisation, und nur seine ersten 5 Mitglieder sind kostenlos (siehe Auditoren).

Einen Leser hinzufügen

Jeder dieser Wege funktioniert; der Weg im Produkt ist der einfachste:

1. Über die Seite Mitglieder (empfohlen). Öffne Organisationsverwaltung → Mitglieder (/<org>/_admin/members) → Per E-Mail einladen → gib die E-Mail-Adresse ein → wähle unter Team(s) das Team Viewers (und sonst nichts) → Einladung senden. Nimmt die Person an, tritt sie als kostenloser Leser bei.
2. Ein bestehendes Mitglied umstellen. Öffne den Verwalten-Bereich des Mitglieds und verschiebe es nach Viewers (entferne es aus Members/Owners). Ab dem nächsten Abrechnungszyklus fällt es aus der Zahl der zahlenden Nutzer heraus.
3. Automatisch per SSO. Ordne eine Gruppe deines Identitätsanbieters dem Team Viewers zu (siehe SSO und SCIM). Alle in dieser Gruppe werden als kostenlose Leser bereitgestellt – ohne Einladung pro Person.
4. Ausweichweg über Forgejo. frem.sh/org/<org>/teams → Viewers → Add team member. Nutze das nur, wenn du Teams feiner zusammenstellen musst; die Seite Mitglieder deckt den Normalfall ab.

Kostenlose Leser werden in deiner Abrechnungsübersicht (Organisationsverwaltung → Abrechnung) und in der Nutzer-API getrennt von den bezahlten Nutzern gezählt, sodass du jederzeit siehst, wie viele kostenlose Leser du hast und wie viele zahlende Nutzer du belegst.

Nicht dasselbe wie ein reiner Doku-Leser. Soll jemand deine veröffentlichte Doku lesen können, aber keinen Repository-Zugriff und gar kein Forgejo-Konto haben, füge ihn nicht zu Viewers hinzu – gib seiner SSO-Gruppe stattdessen eine leere Zuordnung von Gruppe zu Team. Siehe Wiki und öffentliche Doku. Ein Leser (Team Viewers) bekommt ein Forgejo-Konto und Lesezugriff auf freigegebene Repositorys; ein reiner Doku-Leser nicht.

Gäste (kostenloser Lesezugriff, bestimmte Repositorys)

Ein Leser kann jedes Repository der Organisation lesen. Ein Gast liest nur die Repositorys, die du auswählst. Beide sind kostenlos – Code zu lesen kostet nie einen Nutzer, egal in welchem Umfang.

Setze Gäste ein für eine externe Kraft, die einen einzelnen Dienst reviewt, einen Prüfer, der zwei Repositorys statt vierzig braucht, oder ein Partnerteam, das du aus allem anderen heraushalten willst. Es ist die Version eines Lesers mit den geringsten Rechten und kostet dasselbe: nichts.

Gäste sind das kanonische Team Guests, das in jeder Organisation angelegt wird und auf bestimmte Repositorys statt auf alle beschränkt ist.

Einen Gast hinzufügen

1. Öffne Organisationsverwaltung → Mitglieder → Per E-Mail einladen → gib die E-Mail-Adresse ein → wähle unter Team(s) das Team Guests (und sonst nichts).
2. Lege fest, welche Repositorys das Team Guests lesen darf: frem.sh/org/<org>/teams/guests → Repositories → füge die gewünschten Repositorys hinzu.
3. Sende die Einladung. Nimmt die Person an, kann sie genau diese Repositorys lesen.

Um einen bestehenden kostenlosen Leser auf bestimmte Repositorys zu beschränken, öffne seinen Verwalten-Bereich und verschiebe ihn von Viewers nach Guests. Er bleibt in beiden Fällen kostenlos.

Guests und Collaborators werden von fremforge verwaltet und können nicht gelöscht werden. Sie bestimmen, was du zahlst – Guests hält repository-beschränkte Leser kostenlos, Collaborators macht einen repository-beschränkten Schreiber zu einem bezahlten Nutzer. Würde eines davon entfernt, änderte sich der Preis deiner Organisation stillschweigend, deshalb sind beide gesperrt, wie Members und Viewers. Du kannst frei ändern, welche Repositorys jedes davon abdeckt und wer darin ist.

Auditoren

Ein Auditor kann alles in deiner Organisation ansehen und nichts ändern. Setze die Rolle für einen Compliance- oder Sicherheitsprüfer ein, für eine interne Kontrollfunktion oder für alle, die prüfen müssen, wie die Organisation konfiguriert ist, statt nur ihren Code zu lesen.

Jede Organisation hat ein kanonisches Team Auditors, das fremforge anlegt und verwaltet. Es hat Lesezugriff auf alle Repositorys, und seine Mitglieder können außerdem die Verwaltungseinstellungen der Organisation öffnen. Wie die anderen kanonischen Teams ist es gesperrt: Du kannst es nicht löschen, nicht umbenennen und ihm nicht mehr als Lesezugriff geben. Ein Owner entscheidet, wer darin ist.

Was ein Auditor sehen kann

• Jedes Repository, schreibgeschützt, wie ein Leser: klonen, Code durchsuchen, Issues und Pull Requests lesen.
• Die Verwaltungseinstellungen der Organisation unter /<org>/_admin/ und die entsprechenden Lesezugriffe über die REST-API: Richtlinien, Sicherheitseinstellungen, SSO, Mitglieder, Abrechnung und das Audit-Log. Dazu gehört, was ein Owner über Personen sieht: auf der Seite Mitglieder die E-Mail-Adressen, vollständigen Namen, letzte Anmeldung und den MFA-Status der Mitglieder, in den Abrechnungseinstellungen den Abrechnungskontakt und die IDs der Zahlungsmandate.
• Organisations- und Repository-Einstellungen in Forgejo (frem.sh/org/<org>/settings, die Einstellungen eines Repositorys), schreibgeschützt.
• Compliance-Nachweise und Attestierungen. Ein Auditor kann sie abrufen; jeder Abruf wird im Audit-Log erfasst.

Ein Banner auf jeder Verwaltungsseite zeigt an, dass du als schreibgeschützter Auditor schaust. Schaltflächen und Formulare, die etwas ändern würden, sind deaktiviert.

Was ein Auditor nicht kann

• Etwas ändern. Jede Anfrage außer einem Lesezugriff wird abgewiesen, in den Verwaltungsseiten, in der API und in Forgejo, bevor sie den Endpunkt erreicht. In der fremforge-API ist die Ablehnung ein 403 mit dem Fehler auditor-read-only. Ein Auditor kann keine Mitglieder hinzufügen oder entfernen, auch keine anderen Auditoren.
• Daten in großen Mengen herausholen oder Zugangsdaten sehen. Diese Zugriffe werden auch als Lesezugriff abgewiesen: der Datenexport, SBOM-Downloads, der Abrechnungsexport und die Rechnungs-PDFs, rohe CI-Logs, die Webhook-Seiten und die Webhook-API, die Seiten der Forgejo-Actions-Runner und die API für Runner-Registrierungstokens sowie die Seite zum Löschen der Organisation.

Braucht ein Auditor eine dieser Dateien oder eine Änderung, fragt er einen Owner. Ein API-Token, das ein Auditor verwendet, trägt immer nur Lesezugriff.

Einen Auditor hinzufügen

1. Neue Person. Öffne Organisationsverwaltung → Mitglieder (/<org>/_admin/members) → Per E-Mail einladen → gib die E-Mail-Adresse ein → wähle unter Team(s) das Team Auditors → Einladung senden.
2. Bestehendes Mitglied. frem.sh/org/<org>/teams → Auditors → Add team member.

Um einen Auditor zu entfernen, nimm ihn aus dem Team Auditors heraus. Sein Zugriff auf die Verwaltungseinstellungen endet innerhalb von 5 Minuten.

Wer in Auditors und in Owners ist, ist Owner. Wer in Auditors und in einem Team mit Schreibzugriff ist (etwa Members), behält seinen Schreibzugriff auf den Code und ist bei den Einstellungen ein schreibgeschützter Auditor.

Zahlende Nutzer

• Die ersten 5 Auditoren einer Organisation sind kostenlos.
• Ein sechster oder weiterer Auditor ist ein zahlender Nutzer und zählt wie jeder andere gegen dein Nutzerlimit. Sind alle Nutzer belegt, gelten die üblichen Regeln bei vollem Nutzerlimit.
• Ein Auditor, der zusätzlich in einem Team mit Schreibzugriff ist, belegt dafür bereits einen Nutzer, kostet also nichts extra und zählt nicht zu den 5 kostenlosen Auditoren.
• Die Kostenfreiheit ist nicht an bestimmte Personen gebunden: Geht einer der ersten fünf, ist der nächste Auditor an seiner Stelle kostenlos.

Jeder Lesezugriff eines Auditors wird protokolliert

Lesezugriffe von Ownern auf die Verwaltungseinstellungen werden nicht protokolliert, die von Auditoren schon. Jede Seite und jeder API-Endpunkt, den ein Auditor liest, wird im Audit-Log als Ereignis tenant.auditor.read erfasst, höchstens einmal pro Auditor und Endpunkt alle 10 Minuten. Abgewiesene Versuche werden jedes Mal protokolliert.

Ein Team, das du bereits „Auditors“ genannt hast

Hatte deine Organisation schon ein eigenes Team namens Auditors, bevor fremforge die Rolle eingeführt hat, hat fremforge es unangetastet gelassen. Es bleibt ein gewöhnliches Team: Seine Mitglieder bekommen keinen Zugriff auf die Verwaltungseinstellungen, und es wird abgerechnet wie jedes andere Team, das du angelegt hast.

Wenn alle Nutzer belegt sind

Hat deine Organisation ihr Nutzerlimit erreicht, sieht ein Mitglied, das auf die Organisation zugreifen will, statt der angeforderten Ressource eine Seite „Nutzerlimit erreicht“ unter /<org>/seats-full. Von dieser Seite aus kann es mit einem Klick bei den Ownern der Organisation einen weiteren Nutzer anfragen.

Owner erhalten diese Anfrage (per E-Mail und über die Glocke für Benachrichtigungen in der Verwaltung) und können unter Organisationsverwaltung → Abrechnung einen Nutzer hinzufügen, wodurch die Sperre für das wartende Mitglied aufgehoben wird. Erhöhe das Nutzerlimit, bevor das Mitglied weitermachen kann; bis dahin bleibt sein Zugriff auf der Seite „Nutzerlimit erreicht“ angehalten.

Das Limit gilt auch für Mitglieder, die dein Identitätsanbieter über die SSO-Gruppensynchronisation hinzufügt: Bei der Anmeldung setzt die Gruppensynchronisation niemanden in ein Team mit Schreibzugriff, sobald die bezahlten Nutzer der Organisation aufgebraucht sind (schreibgeschützte Teams sind kostenlos und immer erlaubt). Eine Änderung des Limits oder der Nutzer-Überschreitung auf der Seite Abrechnung gilt für die Gruppensynchronisation, sobald du sie speicherst. Dasselbe gilt für das Speichern einer SSO-Quelle oder ihrer Zuordnung von Gruppen zu Teams; so ist sichergestellt, dass das aktuelle Limit vor der nächsten Anmeldung über diese Quelle greift.

Rollen ändern

Die Rolle eines Mitglieds (Owner, Mitglied oder Leser) änderst du im Produkt über den Verwalten-Bereich auf der Seite Mitglieder. Technisch entspricht die Rolle der Mitgliedschaft in Forgejo-Teams: Owners = volle Verwaltung der Organisation, Members = eingeschränkter Lese-/Schreibzugriff gemäß den Repository-Freigaben des Teams, Viewers = nur Lesezugriff (und kostenlos). Wird ein Mitglied nur noch in Viewers geführt, fällt es ab dem nächsten Abrechnungszyklus aus der Zahl der zahlenden Nutzer heraus.

1. Öffne Organisationsverwaltung → Mitglieder (/<org>/_admin/members).
2. Öffne den Verwalten-Bereich des Mitglieds.
3. Wähle die neue Rolle und bestätige. Die passende Änderung am Forgejo-Team wird sofort angewendet.

Für eine feinere Zusammenstellung von Teams (eigene Teams, auf Repositorys beschränkte Freigaben) nutze die Forgejo-eigene Teamseite unter frem.sh/org/<org>/teams. Rollenänderungen wirken sofort. Es gibt keine Übergangsfrist, und das Mitglied erhält keine Bestätigungs-E-Mail.

Ein Mitglied entfernen

1. Öffne Organisationsverwaltung → Mitglieder (/<org>/_admin/members).
2. Öffne den Verwalten-Bereich des Mitglieds und wähle Entfernen.
3. Bestätige das Entfernen.

Was sofort passiert:

• Der Zugriff auf alle Repositorys der Organisation wird entzogen.
• Alle aktiven Sitzungen (Browser oder API) dieses Benutzers werden ungültig.
• Das Mitglied wird aus allen Teamzuordnungen innerhalb der Organisation entfernt.

Was sich nicht ändert:

• Repositorys werden nicht gelöscht. Repositorys gehören der Organisation, nicht einzelnen Mitgliedern. Ein Mitglied, dem Repositorys in der Organisation gehörten, nimmt diese beim Gehen nicht mit.
• Issues, PRs und Commits bleiben seinem Benutzernamen zugeordnet. Die Historie der Beiträge bleibt erhalten.
• Offene PRs und Issues, die es verfasst hat, bleiben offen und unverändert.

Das entfernte Mitglied wird ab dem nächsten Abrechnungszyklus aus der Zahl der zahlenden Nutzer genommen. Für den laufenden Zeitraum gibt es keine Gutschrift.

Checkliste für das Offboarding

Verlässt ein Mitglied die Organisation, geh diese Checkliste durch, bevor du das Entfernen abschließt.

• Übertrage die Repository-Inhaberschaft, falls dem ausscheidenden Mitglied Repositorys direkt gehören (prüfe unter Organisationsverwaltung → Repositorys, welche Repositorys seinen Benutzernamen als Owner haben). Übertrage sie an die Organisation oder an ein anderes Mitglied, bevor du es entfernst.
• Rotiere Secrets, die es kennen konnte. Prüfe, welche Secrets angelegt oder zuletzt geändert wurden, während es Zugriff hatte. Rotiere alle, die durch sein Ausscheiden nun offenliegen.
• Widerrufe API-Tokens, die es angelegt hat. Unter Organisationsverwaltung → API-Token (/<org>/_admin/api-tokens) siehst du alle API-Tokens der Organisation. Widerrufe jedes Token, das das ausscheidende Mitglied angelegt hat.
• Prüfe persönliche Zugriffstokens (PATs). PATs hängen am Konto des Benutzers, nicht an der Organisation. Nach dem Entfernen aus der Organisation können seine PATs nicht mehr auf Ressourcen der Organisation zugreifen. War das ausscheidende Mitglied aber Owner, vergewissere dich, dass keine Tokens mit erweiterten Scopes unter seinem Namen an externe Systeme weitergegeben wurden.
• Prüfe aktive Integrationen und Webhooks. Authentifiziert sich ein Webhook oder eine externe Integration als dieser Benutzer, stelle sie auf ein API-Token der Organisation oder ein anderes Konto um.

Deprovisionierung per SCIM

Ist SCIM-Provisionierung für die Organisation eingerichtet, verwaltet der verbundene IdP (Okta, Entra ID usw.) den Lebenszyklus der Benutzer. Deaktivierst oder entfernst du einen Benutzer im IdP, wird er innerhalb des SCIM-Synchronisationsintervalls automatisch in fremforge deaktiviert, in der Regel in weniger als fünf Minuten.

Wird ein Benutzer per SCIM deaktiviert:

• Seine fremforge-Sitzung wird sofort ungültig.
• Er kann sich weder per SSO noch mit lokalem Passwort anmelden.
• Jede fremforge-Zugangsberechtigung, die er hat, hört innerhalb etwa einer Minute, spätestens nach 10 Minuten auf zu funktionieren: Konsolensitzungen, die CLI-Anmeldung, die API-Tokens, die er angelegt hat, und seine KI-Konnektoren (MCP). Sitzungen und API-Tokens werden abgewiesen, nicht gelöscht, und funktionieren wieder, wenn die Person reaktiviert wird. Die Autorisierungen seiner KI-Konnektoren werden widerrufen. Eine laufende Dev-Bench von ihm wird angehalten. Sitzungen und API-Tokens werden auf dieselbe Weise abgewiesen, wenn ein Admin die Anmeldung einer Person sperrt.
• Sein Nutzer wird ab dem nächsten Abrechnungszyklus aus der Zahl der zahlenden Nutzer genommen.

Ist SCIM aktiv, ist kein manuelles Entfernen über Organisationsverwaltung → Mitglieder nötig. Der IdP ist die maßgebliche Quelle für die Mitgliedschaft. Entfernst du einen Benutzer in fremforge, ohne ihn im IdP zu deaktivieren, stellt SCIM ihn bei der nächsten Synchronisation wieder bereit.

Die Einrichtung ist unter SCIM-Provisionierung beschrieben.

Reine SSO-Mitglieder

Ein Mitglied, das sich immer nur per SSO angemeldet hat, hat kein lokales fremforge-Passwort. Seine Identität wird vollständig vom IdP gesteuert.

So sperrst du den Zugriff eines reinen SSO-Mitglieds:

1. Entziehe ihm den Zugriff im IdP (deaktiviere das Konto, entferne es aus der App-Zuweisung oder schalte SSO für sein Konto ab).
2. Entferne es optional in fremforge aus der Organisation, um die Nutzerzahl zu bereinigen.

Den Zugriff im IdP zu entziehen genügt, um die Anmeldung zu verhindern. Die fremforge-Sitzung scheitert bei der nächsten SSO-Prüfung. Ist SCIM eingeschaltet, löst die Deaktivierung im IdP außerdem die automatische Deprovisionierung aus, ohne dass du das Mitglied manuell aus der Organisation entfernen musst.

Ein ehemaliges Mitglied erneut einladen

Um jemanden erneut einzuladen, der zuvor entfernt wurde, sende ihm wie gewohnt eine neue Einladung über Organisationsverwaltung → Mitglieder → Per E-Mail einladen.

Wenn die Person wieder beitritt:

• Frühere Commits, Issues und PRs bleiben ihrem Benutzernamen zugeordnet.
• Der Repository-Zugriff ergibt sich neu aus der Rolle in der Organisation und etwaigen Collaborator-Zuordnungen auf Repository-Ebene. Frühere Zugriffseinstellungen werden nicht automatisch wiederhergestellt.

Hat das ehemalige Mitglied sein fremforge-Konto nach dem Ausscheiden gelöscht, kann sein Benutzername bei früheren Beiträgen als gelöschtes Konto angezeigt werden. Hat inzwischen eine andere Person diesen Benutzernamen übernommen, verweist die historische Zuordnung über die zugrunde liegende Benutzer-ID auf das ursprüngliche Konto, nicht nur über den Benutzernamen.

Berechtigungen pro Repository

Die Rollen auf Organisationsebene legen den Grundzugriff fest. Für eine feinere Steuerung kannst du einzelne Benutzer als Collaborators zu bestimmten Repositorys hinzufügen.

Einen Collaborator hinzufügen:

1. Öffne Repository → Einstellungen → Mitarbeiter.
2. Suche den Benutzer nach Benutzername oder E-Mail-Adresse.
3. Wähle eine Berechtigungsstufe:

Collaborator-Berechtigungen kommen zusätzlich zur Rolle des Benutzers in der Organisation hinzu und ersetzen sie nicht – es gilt die höhere von beiden. Ein Leser mit Collaborator-Berechtigung Write auf einem Repository kann in dieses Repository pushen. Ein Owner als Collaborator gewinnt nichts über das hinaus, was die Rolle Owner bereits gewährt.

Collaborators müssen Mitglieder deiner Organisation sein

Ein Collaborator muss Mitglied der Organisation sein, der das Repository gehört. Du kannst niemanden aus einer anderen Organisation hinzufügen und kein externes Konto direkt zu einem Repository hinzufügen – lade die Person zuerst in die Organisation ein (als Gast, wenn sie nur Lesezugriff braucht), und gewähre dann den Repository-Zugriff.

Das ist eine Änderung gegenüber dem früheren Verhalten, bei dem ein Repository-Admin jedes bestehende Konto der Instanz hinzufügen konnte. Weil die Mitgliedschaft Pflicht ist, erscheint jeder mit Zugriff auf deinen Code unter Organisationsverwaltung → Mitglieder, und genau das macht Zugriffsüberprüfungen und Offboarding vollständig.

Was ein Collaborator kostet

Nur Schreibzugriff kostet einen Nutzer:

Gewährst du jemandem, der derzeit kostenlos ist (ein Leser oder Gast), Schreibzugriff, wird er automatisch zum kanonischen Team Collaborators hinzugefügt, wodurch er ein bezahlter Nutzer wird. Du musst ihn nicht von Hand verschieben. Wer bereits zahlender Nutzer ist – ein Mitglied, ein Owner oder ein bestehender Collaborator –, wird nicht doppelt berechnet.

Würde dieser Nutzer dein Nutzerlimit überschreiten:

• Ist Nutzer-Überschreitung eingeschaltet, gelingt die Freigabe, und der zusätzliche Nutzer erscheint auf deiner nächsten Rechnung.
• Ist die Nutzer-Überschreitung ausgeschaltet, wird die Freigabe abgewiesen, und du wirst zu Organisationsverwaltung → Abrechnung → Nutzer geleitet. Die Nutzer-Überschreitung unter Organisationsverwaltung → Abrechnung auszuschalten ist der Weg, mit dem du verhinderst, dass fremforge automatisch bezahlte Nutzer hinzufügt – derselbe Schalter, der für Einladungen und per SSO bereitgestellte Mitglieder gilt.

Entfernst du jemandes Nutzer, verliert er seinen Zugriff nicht vollständig. Schreibfreigaben, die nicht mehr durch einen Nutzer gedeckt sind, werden nach einer Übergangsfrist von 7 Tagen auf Lesezugriff herabgestuft; der Verlust eines Nutzers macht aus einem Collaborator also das Gegenstück eines Gasts, statt ihn auszusperren. Stellst du den Nutzer innerhalb dieser Frist wieder her, ändert sich nichts.

Über die REST-API

Der tägliche Ablauf im Lebenszyklus von Mitgliedern (einladen / auflisten / widerrufen / entfernen) steht über die öffentliche API zur Verfügung. Nutze sie, wenn du das Onboarding aus einem HRIS skriptest, das Offboarding automatisierst oder Vorgänge von einem KI-Agenten aus steuerst.

• Einladungen auflisten GET /_app/api/v1/orgs/:slug/members/invitations?status=pending (Scope seats:read)
• Ein Mitglied einladen POST /_app/api/v1/orgs/:slug/members/invitations Body: { "email": "...", "full_name": "...", "team_names": [...] } (Scope seats:write)
• Eine offene Einladung widerrufen DELETE /_app/api/v1/orgs/:slug/members/invitations/:id (Scope seats:write)
• Ein Mitglied entfernen DELETE /_app/api/v1/orgs/:slug/members/:login (Scope seats:write)
• Einen zurückgehaltenen Nutzer gewähren / verwerfen POST /_app/api/v1/orgs/:slug/members/seat-holds/:id/grant oder .../dismiss (Scope seats:write)

Erfordert ein persönliches Zugriffstoken (PAT) mit dem Scope seats:write:

curl -X POST \
  -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  -H "Content-Type: application/json" \
  -d '{"email":"new.hire@example.com","full_name":"New Hire","team_names":["engineering"]}' \
  https://frem.sh/_app/api/v1/orgs/acme/members/invitations

Die vollständige OpenAPI-Spezifikation findest du in der Referenz der öffentlichen REST-API.

Querverweise

• SCIM-Provisionierung, automatisierter Benutzer-Lebenszyklus über Okta, Entra ID oder jeden IdP, der SCIM 2.0 unterstützt
• OIDC-SSO, SSO so konfigurieren, dass sich Mitglieder mit ihrer Unternehmensidentität anmelden
• Abrechnung, wie Nutzer gezählt werden und wann entfernte Mitglieder aus der Abrechnung fallen
• Organisationsverwaltung, vollständige Referenz der Verwaltungsoberfläche der Organisation
• API, Mitglieder programmatisch über die REST-API verwalten