Zugriffssteuerung¶
Weblate verfügt über ein fein abgestuftes Berechtigungssystem, mit dem Sie Benutzern Berechtigungen für die gesamte Instanz mit vordefinierten Rollen zuweisen können oder eine oder mehrere Berechtigungsgruppen für alles oder einzelne Projekte, Komponenten, Glossare usw. zuweisen können.
Projektzugriffssteuerung¶
Bemerkung
Projekte, die das kostenlose Freies Hosting-Paket auf Hosted Weblate ausführen, sind immer Öffentlich. Sie können zum kostenpflichtigen Paket wechseln, wenn Sie den Zugriff auf Ihr Projekt einschränken möchten.
Beschränken Sie den Zugriff der Benutzer auf einzelne Projekte, indem Sie eine andere Einstellung der Zugriffssteuerung auswählen. Die verfügbaren Optionen sind:
- Öffentlich
Für alle sichtbar.
Jeder authentifizierte Benutzer kann übersetzen.
Das VCS-Repository ist möglicherweise für alle zugänglich.
Wählen Sie dies für Open-Source-Projekte oder wenn Ihre Weblate-Instanz privat oder gesperrt ist.
- Geschützt
Für alle sichtbar.
Nur ausgewählte Benutzer können übersetzen.
Nur ausgewählte Benutzer können auf das VCS-Repository zugreifen.
Wählen Sie dies, um Sichtbarkeit zu erlangen, aber dennoch die Kontrolle darüber zu haben, wer etwas beitragen kann.
- Privat
Nur für ausgewählte Benutzer sichtbar.
Nur ausgewählte Benutzer können übersetzen.
Nur ausgewählte Benutzer können auf das VCS-Repository zugreifen.
Wählen Sie dies für Projekte, die überhaupt nicht öffentlich zugänglich sein sollen.
- Benutzerdefiniert
Nur für ausgewählte Benutzer sichtbar.
Nur ausgewählte Benutzer können übersetzen.
Nur ausgewählte Benutzer können auf das VCS-Repository zugreifen.
Nicht verfügbar auf Hosted Weblate.
Sie müssen alle Berechtigungen über die Plattformweite Zugriffssteuerung einrichten.
Wählen Sie dies für Ihre Weblate-Instanz, wenn Sie den Zugriff auf eine bestimmte, genau anpassbare Weise definieren möchten.
Die Zugriffssteuerung kann im Reiter Zugriff der Konfiguration (Operationen ↓ Einstellungen) des jeweiligen Projekts geändert werden.
Der Standard kann auch durch die Einstellung DEFAULT_ACCESS_CONTROL geändert werden.
Bei privaten und benutzerdefinierten Projekten können die Beteiligungsseiten unter Öffentliche Freigabe sowie Status-Widgets anonym zugänglich gemacht werden, ohne dass der Rest des Projekts öffentlich zugänglich ist. Die öffentliche Freigabe ist bei diesen Projekten standardmäßig deaktiviert.
Bemerkung
Die aggregierten Statistiken umfassen Privat-Projekte und eingeschränkte Komponenten, einschließlich der Zusammenfassungen für die gesamte Website, für Sprachen und für Arbeitsbereiche. Objektlisten, Namen und Aktionen in der Weboberfläche und API unterliegen weiterhin einer Berechtigungsfilterung, sodass diese aggregierten Daten keinen Zugriff auf die zugrunde liegenden Projekte oder Komponenten gewähren.
Bemerkung
Generische eingehende Benachrichtigungs-Hooks stellen eine ausdrückliche Kompatibilitätsausnahme hinsichtlich der Vertraulichkeit von Kennungen dar. Wenn eine übereinstimmende Repository-URL angegeben wird, enthält ihre diagnostische Antwort die Anzahl der Übereinstimmungen sowie – sofern eine Aktualisierung geplant ist – den Slug des Projekts bzw. der Komponente und die API-URL. Dies gilt auch für Privat-Projekte und eingeschränkte Komponenten, mit Ausnahme von Komponenten, die über eine authentifizierte Integration verwaltet werden. Die API-URL umgeht keine Zugriffssteuerung, und es werden weder Projektinhalte noch Zugangsdaten übermittelt. Siehe Webhook-Ziele abgleichen.
Bemerkung
Instanzadministratoren können die Standardberechtigungen, die Benutzern in Öffentlich-, Geschützt- und Privat-Projekten zur Verfügung stehen, mithilfe von benutzerdefinierten Einstellungen ändern.
Siehe auch
Arbeitsbereich-Zugriffssteuerung¶
Teams auf Arbeitsbereichsebene sind unter Arbeitsbereich-Zugriffssteuerung dokumentiert.
Projektspezifische Zugriffssteuerung verwalten¶
Für Öffentlich-, Geschützt- und Privat-Projekte:
Wenn Sie Benutzern Projektzugriff verwalten (siehe Liste der Berechtigungen) gewähren, können diese anderen Benutzern Zuweisungen zu Öffentlich, Geschützt und Privat (aber nicht Benutzerdefiniert)-Projekten geben, indem Sie sie zu Teams hinzufügen.
Wenn für das Aktivieren einer Projektfunktion ein integrierter Teamname erforderlich ist, der bereits von einem benutzerdefinierten Team verwendet wird, erhält das benutzerdefinierte Team einen numerischen Zusatz. Seine Zugehörigkeiten und Berechtigungen bleiben erhalten, und auf der Einstellungsseite wird die Umbenennung angezeigt.
Bestehende Teams mit doppelten Namen können weiterhin bearbeitet werden, ohne dass ihre Namen geändert werden. Durch das Speichern der Projekteinstellungen werden doppelte Namen korrigiert: Ein integriertes Team behält seinen Namen, und zusätzliche Teams erhalten numerische Suffixe. Zusätzliche integrierte Teams werden zu bearbeitbaren benutzerdefinierten Teams. Zugehörigkeiten und Berechtigungen bleiben erhalten, und auf der Einstellungsseite wird die Umbenennung angezeigt.
Dies sind die Standardteams, die mit Weblate bereitgestellt werden; Teams können von Benutzern mit entsprechenden Rechten hinzugefügt oder geändert werden:
- Verwaltung
Alle verfügbaren Berechtigungen für das Projekt.
- Überprüfen
Übersetzungen in einer Überprüfung genehmigen.
Nur verfügbar, wenn der Überprüfungsablauf eingeschaltet ist.
Nur für Geschützt- und Privat-Projekte:
- Übersetzen
Das Projekt übersetzen und offline erstellte Übersetzungen hochladen.
- Quellcode
Ausgangszeichenketten (sofern dies in den Projekteinstellungen zugelassen wird) und Infos zu Ausgangszeichenketten bearbeiten.
- Sprachen
Übersetzte Sprachen verwalten (Übersetzungen hinzufügen oder entfernen).
- Glossar
Glossar verwalten (Einträge hinzufügen, entfernen und hochladen).
- Speicher
Übersetzungsspeicher verwalten.
- Bildschirmfotos
Bildschirmfotos verwalten (hinzufügen, entfernen und zu Ausgangszeichenketten zuordnen).
- Automatische Übersetzung
Darf automatische Übersetzungen verwenden.
- VCS
VCS verwalten und auf das exportierte Repository zugreifen.
- Abrechnung
Auf Abrechnungsdaten und -einstellungen zugreifen (siehe Abrechnung).
Diese Funktionen sind auf der Seite Zugriffssteuerung im Projektmenü Operationen ↓ Benutzer verfügbar.
Hinweis
Sie können Teams auf Sprachen oder Komponenten beschränken und ihnen bestimmte Zugriffsrollen zuweisen (siehe Liste der Berechtigungen).
Before moving a component to another project, remove it from teams defined in its current project. Moving a category requires removing its components from such teams as well. Removing the last component from a team grants its roles to the whole project, so review the team’s membership and roles first.
Teams left with moved components by an earlier release show those assignments by component ID. The assignments grant no access to the destination project. You can remove them through the REST API after reviewing the effect of an empty component selection on the original project.
Teamadministratoren¶
Added in version 4.15.
Each team can have team administrators, who can add and remove users within the team. Administrators relying on this designation must satisfy the team’s enforced two-factor authentication. Their team management access is suspended while they are blocked in any project covered by the team, or while a covered project requires two-factor authentication they have not configured. For a team covering multiple projects, the restriction applies to the whole team.
Dies ist nützlich, wenn Sie selbstverwaltete Teams bilden möchten.
Plattformweite Teamverwaltung¶
Die Verwaltung von plattformweiten Teams wird durch die globale group.edit-Berechtigung gesteuert. Hierbei handelt es sich um eine vertrauenswürdige Administratorberechtigung, die das Erstellen, Bearbeiten und Löschen von plattformweiten Teams ermöglicht, einschließlich das Ändern ihrer Rollen sowie der Auswahl von Projekten, Komponenten, Komponentenlisten und Sprachen.
Die Zuweisung von Projekten und Komponenten ist nicht auf Projekte beschränkt, auf die der Teammanager direkten Zugriff hat. Ein Teammanager kann daher bestehenden Teammitgliedern Zugriff auf ein privates Projekt gewähren, ohne selbst direkten Zugriff auf dieses Projekt zu erhalten.
Betrachten Sie group.edit als instanzweite Zugriffsverwaltung und nicht als Berechtigung, ausschließlich Teams oder Projekte zu verwalten, die für den Benutzer bereits sichtbar sind. Um die Zugriffsverwaltung in einem engeren Umfang zu delegieren, nutzen Sie ein Projekt-Administration-Team, die Arbeitsbereich-Verwaltung oder einen Teamadministrator. Teamadministratoren können Benutzer hinzufügen und entfernen, haben jedoch keine Berechtigung, den Zugriffsbereich des Teams zu ändern.
Neue Benutzer einladen¶
Beim Hinzufügen bestehender Benutzer erhalten diese eine Einladung zur Bestätigung. Mit REGISTRATION_OPEN kann der Administrator auch neue Benutzer per E-Mail einladen. Eingeladene Benutzer müssen den Registrierungsprozess abschließen, um Zugriff auf das Projekt zu erhalten.
Dazu sind keine plattformweiten Berechtigungen erforderlich, eine Zugriffsverwaltungsberechtigung für den Projektbereich (z. B. eine Zugehörigkeit im Team Administration) wäre ausreichend.
Hinweis
Wenn der eingeladene Benutzer die Gültigkeitsdauer der Einladung versäumt hat, muss eine neue Einladung erstellt werden.
Die gleiche Art von Einladungen ist plattformweit über die Verwaltungsoberfläche auf der Reiterkarte Benutzer verfügbar. Sowohl Projektadministratoren als auch Website-Administratoren können auch mehrere Benutzer auf einmal einladen, indem sie durch Leerzeichen getrennte E-Mail-Adressen einfügen. Alle in einer Massenaktion erstellten Einladungen verwenden das ausgewählte Team, und plattformweite Sammeleinladungen wenden auch die ausgewählte Superuser-Markierung an.
Die plattformweite Benutzerverwaltung wird durch die globale Berechtigung user.edit gesteuert. Anders als bei der Projektzugriffsverwaltung handelt es sich hierbei um eine vertrauenswürdige administrative Berechtigung, die das Bearbeiten von Benutzerkonten in der gesamten Instanz ermöglicht. Dazu gehören das Hinzufügen oder Entfernen des verwalteten Kontos aus plattformweiten, Arbeitsbereichs- oder Projekt-Teams sowie das Erteilen oder Entziehen des Superuser-Status, selbst für das eigene Konto des Aufrufenden. Für diese Aktionen ist weder die Berechtigung Teams verwalten noch eine separate Berechtigung für das betroffene Team erforderlich.
Behandeln Sie user.edit als praktisch gleichwertig mit Superuser-Zugriff und nicht als eingeschränkte Helpdesk-Berechtigung. Um die Zugriffsverwaltung in einem engeren Rahmen zu delegieren, nutzen Sie stattdessen ein Projekt-Administration-Team oder einen Teamadministrator.
Website-Administratoren können die Passwortauthentifizierung für einen Benutzer auch deaktivieren. Die Option API-Schlüssel neu generieren ist standardmäßig aktiviert, sodass der aktuelle persönliche API-Schlüssel nicht mehr funktioniert. Deaktivieren Sie diese Option nur, wenn der aktuelle API-Schlüssel weiterhin aktiv bleiben soll.
Sammeleinladungen werden einzeln verarbeitet. Ungültige Adressen und Adressen mit einer bereits ausstehenden Einladung werden übersprungen, während gültige Einladungen weiterhin erstellt und gesendet werden.
Geändert in Version 5.0: Weblate erstellt jetzt nicht mehr automatisch Konten oder fügt Benutzer zu den Teams hinzu. Dies geschieht erst nach Bestätigung durch den Benutzer.
Benutzer sperren¶
Added in version 4.7.
If users misbehave in your project, you can block them from contributing. Blocked users cannot access the project or use their project permissions, including project administration permissions. Site superusers are exempt.
Blocking preserves team memberships. Permissions granted by those memberships apply again when the block expires or is removed. Blocking does not cancel background work that was already authorized or remove existing administrative configuration, such as add-ons.
Benutzerbeiträge bereinigen¶
Beim Sperren von Spam- oder missbräuchlichen Konten können Projektadministratoren auch die bestehenden Beiträge des Benutzers in diesem Projekt löschen. Verwenden Sie Operationen ↓ Benutzer, sperren Sie den Benutzer und wählen Sie im Sperrformular die entsprechenden Bereinigungsvorgänge aus. Für bereits gesperrte Benutzer verwenden Sie Benutzerbeiträge bereinigen in der Liste der gesperrten Benutzer.
Die verfügbaren Bereinigungsvorgänge sind:
Benutzerbearbeitungen rückgängig machen macht die zuletzt vom Benutzer bearbeiteten Übersetzungen rückgängig.
Benutzervorschläge ablehnen lehnt ausstehende Übersetzungsvorschläge des Benutzers ab.
Benutzerkommentare löschen löscht Kommentare des Benutzers.
Website-Administratoren mit der plattformweiten user.edit-Berechtigung können den gleichen Massenbereinigungsvorgang für alle Projekte über die Verwaltungsoberfläche auf dem Reiter Benutzer durchführen. Öffnen Sie das Profil des Benutzers, wählen Sie den Reiter Bearbeiten und verwenden Sie die Funktion Bereinigungsvorgang für Beiträge.
Berechtigungsverwaltung pro Projekt¶
Sie können Ihre Projekte auf Geschützt oder Privat (siehe Projektzugriffssteuerung) setzen und den Benutzerzugriff pro Projekt einstellen.
Standardmäßig verhindert dies, dass Weblate den Zugriff von Benutzer- und Betrachter-Standardteams aufgrund der eigenen Konfiguration dieser Teams gewährt. Dies hindert Sie jedoch nicht daran, diesen Projekten plattformweit Berechtigungen zu erteilen, indem Sie die Standardteams ändern, ein neues Team erstellen oder zusätzliche benutzerdefinierte Einstellungen für einzelne Komponenten vornehmen, wie unter Plattformweite Zugriffssteuerung beschrieben.
Einer der Hauptvorteile der Verwaltung von Berechtigungen über die Weblate-Bedienoberfläche ist, dass Sie sie an andere Benutzer delegieren können, ohne ihnen das Superuser-Recht zu geben. Dazu fügen Sie sie dem Team Administration des Projekts hinzu.
Diese projektbezogene Delegation ist von der plattformweiten Berechtigung user.edit getrennt. Die Zugehörigkeit im Administration-Team eines Projekts ermöglicht die Zugriffsverwaltung nur für dieses Projekt, während user.edit die plattformweite Benutzerverwaltung in der Weblate-Bedienoberfläche und -API gewährt und nur absolut vertrauenswürdigen Website-Administratoren zugewiesen werden sollte.
Zugangstoken pro Projekt¶
Added in version 4.10.
Unter dem Reiter API-Zugang können Sie projektbezogene Zugangstoken definieren. Für die API-Tokens kann ein Ablaufdatum festgelegt werden, und ihre Berechtigungen können wie bei Benutzern durch Teamzugehörigkeiten angepasst werden.
Siehe auch
Plattformweite Zugriffssteuerung¶
Bemerkung
Diese Funktion ist auf Hosted Weblate nicht verfügbar.
Das Berechtigungssystem basiert auf Rollen, die eine Reihe von Berechtigungen definieren, und Teams, die Rollen mit Benutzern und Übersetzungen verknüpfen. Weitere Einzelheiten finden Sie unter Benutzer, Rollen, Teams, und Berechtigungen.
Die leistungsfähigsten Funktionen der Zugriffssteuerung von Weblate können in der Verwaltungsoberfläche konfiguriert werden. Sie können damit die Berechtigungen für jedes Projekt verwalten. Sie müssen die Zugriffssteuerung nicht zwingend auf Benutzerdefiniert umstellen, um sie nutzen zu können. Sie benötigen jedoch Superuser-Rechte.
Wenn Sie sich nicht für die Details der Implementierung interessieren und nur eine einfache, auf den Standardwerten basierende Konfiguration erstellen möchten oder keinen plattformweiten Zugriff auf die gesamte Weblate-Installation haben (wie bei Hosted Weblate), lesen Sie bitte den Abschnitt Projektspezifische Zugriffssteuerung verwalten.
Plattformweite Rechteverwaltung¶
Um Berechtigungen für eine ganze Instanz auf einmal zu verwalten, fügen Sie Benutzer zu den entsprechenden Standardteams hinzu:
Benutzer (dies geschieht standardmäßig durch automatische Teamzuweisungen).
Prüfer (wenn Sie den Überprüfungsablauf mit dedizierten Prüfern verwenden).
Manager (wenn Sie die meisten Verwaltungsaufgaben an jemand anderen delegieren möchten).
Sie sollten alle Projekte als Öffentlich konfigurieren (siehe Projektzugriffssteuerung), da sonst die plattformweiten Berechtigungen, die durch die Zugehörigkeit in den Teams Benutzer und Prüfer gegeben sind, keine Wirkung haben.
You may also grant additional permissions to the default teams. To change a built-in role for every team using it, customize its permissions as described in Standardteams und -rollen. For example, adding screenshot permissions to Power user affects the Users team and any other teams assigned that role.
To change permissions for only one team, create a custom role and assign it to that team. Custom roles remain independent of upstream defaults. To reduce a team’s permissions, replace or remove its existing roles as needed; adding a narrower role does not revoke permissions granted by another role.
Sie können auch einige neue benutzerdefinierte Teams definieren. Wenn Sie Ihre Berechtigungen für diese Teams weiterhin plattformweit verwalten möchten, wählen Sie einen geeigneten Wert für Projektauswahl (z. B. Alle Projekte oder Alle öffentlichen Projekte).
Eigene Berechtigungen für Sprachen, Komponenten oder Projekte¶
Sie können Ihre eigenen dedizierten Teams erstellen, um die Berechtigungen für bestimmte Objekte wie Sprachen, Komponenten und Projekte zu verwalten. Obwohl diese Teams nur zusätzliche Berechtigungen gewähren, können Sie keine Berechtigung, die von plattformweiten oder projektspezifischen Teams gewährt wurde, durch Hinzufügen einer anderen benutzerdefinierten Team aufheben.
Beispiel:
Beschränkung der Übersetzung in Tschechisch auf eine ausgewählte Gruppe von Übersetzern (während die Übersetzungen in andere Sprachen öffentlich bleiben):
Entziehen Sie allen Benutzern die Berechtigung, Tschechisch zu übersetzen. In der Standardkonfiguration kann dies durch Ändern des Benutzer-Standardteams erfolgen. Integrierte Teams lehnen diese Änderung in der Bedienoberfläche zur Teamverwaltung ab; verwenden Sie stattdessen die Django-Adminoberfläche .
Gruppe Benutzer¶ Alle Sprachen
Ausgeschaltet
Sprachen
Alle außer Tschechisch
Fügen Sie ein dediziertes Team für Tschechisch-Übersetzer hinzu.
Gruppe Tschechische Übersetzer¶ Rollen
Hauptbenutzer
Projektauswahl
Alle öffentlichen Projekte
Alle Sprachen
Ausgeschaltet
Sprachen
Tschechisch
Fügen Sie die Benutzer, denen Sie die Berechtigungen erteilen möchten, zu diesem Team hinzu.
Das Verwalten von Berechtigungen auf diese Weise ist zwar leistungsfähig, kann aber ziemlich mühsam sein. Sie können sie nur an andere Benutzer delegieren, indem Sie ihnen den Superuser-Status gewähren.
Benutzer, Rollen, Teams, und Berechtigungen¶
Die Authentifizierungsmodelle bestehen aus verschiedenen Objekten:
- Berechtigung
Durch Weblate bestimmte individuelle Berechtigung. Berechtigungen können nicht an Benutzer vergeben werden, nur über das Zuweisen von Rollen.
- Rolle
Eine Rolle definiert einen Satz von Berechtigungen (und kann an mehreren Stellen wiederverwendet werden).
- Benutzer
Ein Benutzer kann zu mehreren Teams gehören.
- Gruppe
Gruppen verbinden Rollen und Benutzer mit Authentifizierungsobjekten (Projekte, Sprachen, Komponenten und Komponentenlisten).
Bemerkung
Einem Team können auch keine Rollen zugewiesen werden. In diesem Fall wird davon ausgegangen, dass jeder das Projekt durchsuchen kann (siehe unten).
Projekt-Browsing-Zugriff¶
Ein Benutzer muss Mitglied eines Teams sein, die mit dem Projekt oder einer Komponente in diesem Projekt verlinkt ist. Eine Zugehörigkeit allein genügt, es sind keine speziellen Genehmigungen erforderlich, um ein Projekt zu durchsuchen (dies wird in dem Standardteam Betrachter angewendet, siehe Liste der Teams).
Komponenten-Browsing-Zugriff¶
Wird einem Benutzer in einem Projekt der Browsing-Zugriff gewährt, erhält er damit Zugriff auf alle Komponenten mit abgeleiteten Browsing-Berechtigungen. Wenn Eingeschränkter Zugriff aktiviert ist, erfordert der Zugriff auf normale Komponenten eine explizite Berechtigung. Benutzer mit der Berechtigung Projekteinstellungen bearbeiten können zudem alle Komponenten in diesem Projekt durchsuchen.
Umfang der Teams¶
Der Umfang der von den Rollen in den Teams zugewiesenen Berechtigungen wird nach den folgenden Regeln angewendet:
Wenn das Team eine Komponentenliste angibt, werden alle Berechtigungen, die den Mitgliedern dieses Teams gewährt werden, für alle Komponenten in den Komponentenlisten, die dem Team zugeordnet sind, gewährt, und ein Zugriff ohne zusätzliche Berechtigungen wird für alle Projekte gewährt, in denen sich diese Komponenten befinden. Komponenten und Projekte werden ignoriert.
Die Verwendung großer Komponentenlisten kann sich auf die Leistung auswirken, daher sollten Sie stattdessen den Zugriff über Projekte ermöglichen.
Wenn das Team ein Komponenten angibt, werden alle Berechtigungen, die den Mitgliedern dieses Teams erteilt wurden, für alle Komponenten gewährt, die dem Team zugeordnet sind, und ein Zugriff ohne zusätzliche Berechtigungen wird für alle Projekte gewährt, in denen diese Komponenten enthalten sind. Projekte werden ignoriert.
Andernfalls, wenn das Team irgendwelche Projekte angibt, entweder durch direkte Auflistung oder indem Projektauswahl auf einen Wert wie Alle öffentlichen Projekte gesetzt wird, werden alle diese Berechtigungen auf alle Projekte angewandt, was effektiv dieselben Zugriffsrechte für alle nicht eingeschränkten Komponenten des Projekts gewährt.
Die durch die Sprachen eines Teams auferlegten Beschränkungen werden separat angewendet, wenn geprüft wird, ob ein Benutzer Zugriff auf bestimmte Aktionen hat. Konkret gilt dies nur für Aktionen, die in direktem Zusammenhang mit dem Übersetzungsprozess selbst stehen, wie das Überprüfen, Speichern von Übersetzungen, Hinzufügen von Vorschlägen usw.
Einzelne Teamzugehörigkeiten können diese Berechtigungen zusätzlich auf ausgewählte Sprachen beschränken. Bleibt das Feld für das Sprachlimit pro Mitglied leer, gelten keine zusätzlichen Beschränkungen über die Sprachauswahl des Teams hinaus. Das gleiche Sprachlimit kann festgelegt werden, wenn neue Benutzer in ein Projektteam eingeladen werden. Wenn ein Sprachlimit pro Mitglied festgelegt ist, gewährt die Zugehörigkeit nur Berechtigungen, die für eine dieser Sprachen ausgewertet werden können. Projektweite, komponentenweite und globale Berechtigungen dieses Teams werden diesem Mitglied nicht gewährt.
Beim Herunterladen gesammelter Übersetzungen werden diese Regeln auf jede einzelne Übersetzung angewendet. Projekt-, Kategorie-, Komponenten-, Komponentenlisten- und Arbeitsbereichs-Archive enthalten nur Komponenten und Sprachen, für die der Benutzer die Berechtigung Übersetzungsdatei herunterladen besitzt. Für eingeschränkte Komponenten ist daher eine explizite Komponentenberechtigung für diese Berechtigung erforderlich, selbst wenn der Benutzer nicht eingeschränkte Komponenten im selben Projekt herunterladen kann.
Die VCS-Berechtigungen für Commit, Push, Reset und Update werden auf der Komponente ausgewertet, die Besitzerin des Repositorys ist. Ein Mitglied benötigt eine komponentenweite Berechtigung für diese Besitzerin, selbst wenn es einen Vorgang von einer verlinkten Komponente in einem anderen Projekt aus startet. Berechtigungen für verlinkte Komponenten gewähren weder diese Befugnis noch schränken sie die autorisierten Benutzer der Besitzerin ein. Eine sprachbezogene Beschränkung pro Mitglied kann diese Berechtigungen nicht gewähren.
Durch das Verlinken einer Komponente wird die Autorität des Besitzers über den gemeinsam genutzten Checkout anerkannt. Repository-Operationen wirken sich auf den gesamten Checkout und die damit verlinkten Komponenten aus. Sie gewähren keinen Zugriff auf ansonsten unzugängliche Komponentenseiten.
Der projektweite Repository-Status und die projektweiten Repository-Operationen umfassen Repositorys, für die das Mitglied über Berechtigungen des Besitzers verfügt. Andere Repositorys werden separat aufgeführt und werden weder überprüft noch geändert. Ein Vorgang wird abgelehnt, wenn dem Mitglied keines der Repositorys des Projekts zur Verfügung steht.
Die Berichte verwalten-Berechtigung gilt für den gesamten ausgewählten Berichtsbereich. Sie gewährt Zugriff auf Berichtsdaten aus eingeschränkten Komponenten sowie – im Arbeitsbereich – auf private Projekte, selbst wenn diese untergeordneten Elemente für den Benutzer ansonsten nicht sichtbar sind. Erteilen Sie diese Berechtigung nur Benutzern, denen Sie alle Berichtsdaten in diesem Bereich anvertrauen. Berichte für den gesamten Arbeitsbereich stehen normalen Benutzern erst dann zur Verfügung, wenn sie die Zwei-Faktor-Authentifizierung konfiguriert haben, sofern ein Projekt im Arbeitsbereich diese erzwingt. Superuser und Bot-Konten sind davon ausgenommen.
Die Berechtigung Komponenteneinstellungen bearbeiten ermöglicht administrative Vorgänge, die sich auf die Repository-Inhalte auswirken können. Beispielsweise können Benutzer über die Komponenteneinstellungen Dateien auswählen oder Komponenten-Erweiterungen installieren und konfigurieren. Eine Erweiterung für die automatische Übersetzung kann Übersetzungen aus einer berechtigten, eingeschränkten Ausgangskomponente in eine Komponente kopieren, auf die deren Manager Zugriff hat, selbst wenn dieser Manager nicht direkt auf die Quelle zugreifen kann; siehe Erweiterungen. Bei einer verlinkten Komponente nutzen diese Vorgänge das vollständige gemeinsame Checkout. Erteilen Sie diese Berechtigung nur Benutzern, denen der Repository-Inhaber im Zusammenhang mit diesem Checkout vertraut. Gewöhnliche Übersetzungsberechtigungen gewähren diesen administrativen Zugriff nicht.
Repository-weite VCS-Berechtigungen schützen explizite Commit-, Push-, Reset- und Update-Operationen. Sie sind für die normalen Hintergrund-Commits und -Pushes von Übersetzungsänderungen, die über eine autorisierte Komponente vorgenommen werden, nicht erforderlich.
Die Berechtigung Projekteinstellungen bearbeiten ermöglicht die dauerhafte Verwaltung des gesamten Projekts. Projektsicherungen enthalten alle Komponenten, einschließlich der eingeschränkten. Außerdem gewährt sie direkten Zugriff auf alle Projektkomponenten und erlaubt es, deren Einstellungen zu bearbeiten, sie zu löschen und den eingeschränkten Zugriff zu ändern, vorbehaltlich der Abrechnungslimits. Sie gewährt keine Berechtigungen zum Übersetzen, Überprüfen oder Herunterladen. Bei eingeschränkten Komponenten müssen diese Aktionsberechtigungen von einem Team stammen, dessen Geltungsbereich die Komponente umfasst, oder von einer Komponentenliste, die diese enthält; projektweite Aktionsberechtigungen gelten nicht, auch nicht für Projektadministratoren. Projekt- und Kategorie-Erweiterungen wirken ebenfalls auf alle kompatiblen Komponenten in ihrem konfigurierten Geltungsbereich. Erteilen Sie diese Berechtigung nur Benutzern, denen Sie die gesamten Projektdaten und diese administrativen Befugnisse anvertrauen.
Die Konfiguration einer Erweiterung wird als Systemkonfiguration gespeichert und nicht als Delegierung des Kontos, unter dem sie gespeichert wurde. Komponenten-Erweiterungen können Eingaben außerhalb der Zielkomponente verarbeiten, wenn die Erweiterung einen solchen Quellbereich dokumentiert. Die verfügbare Konfiguration und die Bedeutung von Optionen wie alle kompatiblen Komponenten hängen nicht davon ab, welcher Administrator die Erweiterung zuletzt gespeichert hat. Die Erweiterung läuft weiter, auch wenn sich die Berechtigungen oder das Konto des konfigurierenden Benutzers später ändern; überprüfen oder entfernen Sie die Konfiguration separat, wenn der Zugriff widerrufen wird.
Hinweis
Verwenden Sie Alle Sprachen oder Projektauswahl um automatisch alle Sprachen oder Projekte einzuschließen.
Beispiel:
Ein Projekt
foomit den Komponenten:foo/barundfoo/baz, mit Prüf- und Verwaltungsrechten, im folgenden Team:
Gruppe ` Administrator-Prüfer Spanisch`¶ Rollen
Zeichenketten überprüfen, Repository verwalten
Komponenten
foo/bar
Sprachen
Spanisch
Die Mitglieder dieses Teams haben diese Berechtigungen (unter Annahme der Standardrolleneinstellungen):
Allgemeiner (Browsing-)Zugriff auf das gesamte Projekt
fooeinschließlich der beiden Komponenten darin:foo/barundfoo/baz.Zeichenketten in der spanischen Übersetzung von
foo/barüberprüfen (nirgendwo sonst).VCS für das gesamte
foo/bar-Repository verwalten, z. B. ausstehende Änderungen von Übersetzern für alle Sprachen committen.
Automatische Teamzuweisungen¶
Beim Bearbeiten des Team können Sie Automatische Zuweisungen angeben. Dabei handelt es sich um eine Liste regulärer Ausdrücke, mit der neu erstellte Benutzer anhand ihrer E-Mail-Adressen automatisch einem Team zugewiesen werden. Diese Zuweisung erfolgt nur bei der Kontoerstellung.
Der häufigste Anwendungsfall für diese Funktion ist es, alle neuen Benutzer einem Standardteam zuzuweisen. Dieses Verhalten wird für die Standardteams Benutzer und Gast verwendet (siehe Liste der Teams). Verwenden Sie den regulären Ausdruck ^.*$, um alle Benutzer zu finden.
Ein anderer Anwendungsfall für diese Option könnte darin bestehen, den Mitarbeitern Ihres Unternehmens standardmäßig einige zusätzliche Rechte einzuräumen. Unter der Annahme, dass alle Mitarbeiter eine Firmen-E-Mail-Adresse in Ihrer Domain verwenden, kann dies mit einem Ausdruck wie ^.*@mycompany.com erreicht werden.
Bemerkung
Die automatische Teamzuweisung zu Benutzer und Betrachter wird immer neu erstellt, wenn Sie von einer Weblate-Version auf eine andere aktualisieren. Wenn Sie dies abstellen möchten, setzen Sie den regulären Ausdruck auf ^$ (der auf nichts zutrifft).
Bemerkung
Durch Sammeleinladungen über die Bedienoberfläche werden Einladungen erstellt. Bestehende Benutzer müssen die Einladung erst noch bestätigen, bevor sie Teammitglieder werden.
Standardteams und -rollen¶
Nach der Installation wird ein Standardsatz von Teams erstellt (Siehe Liste der Teams).
These roles and teams are created upon installation. Administrators can edit built-in role permissions in the management interface or through the REST API. Built-in roles have fixed names and cannot be deleted. The role list identifies built-in roles and indicates whether their permissions are customized. Editing a role affects every team assigned that role. You no longer need to create a custom role solely to change built-in defaults; use a custom role when you need an independent permission set for selected teams.
During upgrades, database migrations merge changes to the built-in defaults with your assigned permissions. Locally added permissions remain assigned, and locally removed permissions remain excluded. New upstream permissions are added, and permissions removed from upstream defaults are removed. Custom roles are unchanged. The merge compares permission sets, not editing history: keeping an existing default permission does not record a separate local addition. If an upstream permission is removed and later reintroduced, it is treated as a new upstream addition. A previous local removal does not survive the permission’s intervening absence from upstream defaults.
To discard customizations, select built-in roles and use Reset built-in roles to defaults in the management interface, then confirm the reset. Resetting applies the current upstream defaults to all teams using those roles.
Geändert in Version 2026.11: Built-in role permissions became editable. On the first upgrade to this version, existing built-in roles are assumed to be synchronized and receive the current defaults. Earlier changes made through the API or database are replaced. Subsequent upgrades preserve local customizations.
Existing custom roles named Discover users or View user profiles are
renamed with a (custom) suffix before the new built-in roles are created.
A numbered suffix is used if that name is already taken. Their permissions
and team assignments are preserved.
Confidential collaboration¶
The resource permission contribution.view_author controls contributor
attribution in translation history, comments, suggestions, activity, feeds, and
the REST API. Built-in translation and review roles grant it by default,
including Administration. History and attribution remain stored;
hiding identities does not remove changes, timestamps, diffs, or revert actions.
Siehe auch
Configuring confidential collaboration for the combined role and team configuration.
Regenerated translation exports require translation.download and remain
available without contributor identity access when the exporter explicitly
supports identity-safe output. Original files, original-file archives, and
unclassified exporters also require contribution.view_author because their
metadata can contain contributor identities. The built-in Access
repository and Manage languages roles grant contributor identity
access to preserve their original-file download capability. Remove this grant
from those roles too when configuring confidential collaboration.
The following inventory summarizes independent identity disclosure paths:
Oberfläche |
Authorization |
|---|---|
Editor attribution, history, comments, suggestions, feeds, notifications |
|
Regenerated content exports |
|
Original files and unclassified exports |
Download permission and contributor identity access |
Independent |
|
Full reports and change downloads |
Independent |
Own-data reports |
The report creator, limited to their own contributions |
Membership, directory, and profile information |
Existing access-management and user permissions |
Workspace-only attribution |
|
Unscoped global attribution |
Site administrators |
Administrator-configured add-on searches |
Persistent administrative configuration, independent of direct contributor access |
Administrator-configured integrations |
Trusted destinations; contributor identities are retained |
Author filters in full reports and change downloads use their independent
reports.view and change.download permissions, including when
contribution.view_author is removed.
Workspace grants do not override project, component, or language restrictions when a history entry has a more specific resource scope.
Original archives omit auxiliary files when their translation scope is not allowed. Auxiliary files without a translation scope require component-wide download and contributor identity permissions.
Configured add-ons retain their administrative search scope, just as they do for restricted components. Removing a configuring user’s contributor identity access does not disable the saved operation.
Individual notifications use the recipient’s permissions. Administrator-managed integrations, including webhooks and Slack, are trusted exports and can retain contributor identities. Configure their destinations for an appropriately restricted audience, or disable them. Weblate cannot control onward sharing or remove copies already delivered to mailboxes, downloaded files, or external systems.
This feature hides system-provided attribution, not identifying text entered by users in translations, comments, announcements, filenames, or other content. It does not provide comprehensive anonymity or prevent correlation using timing and content. See Privacy configuration for the separate Git commit identity, profile, and discovery controls.
Liste der Berechtigungen¶
Bereich |
Berechtigung |
Integrierte Rollen |
|---|---|---|
Mitwirkende |
View contributor identities |
Verwaltung |
Quelle bearbeiten |
||
Vorschlag hinzufügen |
||
Auf Repository zugreifen |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Sprachen verwalten |
||
Änderungen |
Änderungen herunterladen |
Verwaltung |
Kommentare |
Kommentar erstellen |
Verwaltung |
Quelle bearbeiten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Kommentar löschen |
Verwaltung |
|
Kommentar klären |
Verwaltung |
|
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Komponente |
Komponenteneinstellungen bearbeiten |
Verwaltung |
Komponente sperren, um Übersetzungen zu verhindern |
Verwaltung |
|
Repository verwalten |
||
Glossar |
Glossareintrag hinzufügen |
Verwaltung |
Glossar verwalten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Glossarterminologie hinzufügen |
Verwaltung |
|
Glossar verwalten |
||
Übersetzungskoordinator |
||
Glossareintrag bearbeiten |
Verwaltung |
|
Glossar verwalten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Glossareintrag löschen |
Verwaltung |
|
Glossar verwalten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Glossareinträge hochladen |
Verwaltung |
|
Glossar verwalten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Übersetzungsdienste |
Automatische Vorschläge verwenden |
Verwaltung |
Quelle bearbeiten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Übersetzungsspeicher |
Übersetzungsspeicher bearbeiten |
Verwaltung |
Übersetzungsspeicher verwalten |
||
Übersetzungsspeicher löschen |
Verwaltung |
|
Übersetzungsspeicher verwalten |
||
Projekte |
Projekteinstellungen bearbeiten |
Verwaltung |
Projektzugriff verwalten |
Verwaltung |
|
Berichte |
Berichte verwalten |
Verwaltung |
Arbeitsbereich-Verwaltung |
||
Bildschirmfotos |
Bildschirmfoto hinzufügen |
Verwaltung |
Übersetzungskoordinator |
||
Bildschirmfotos verwalten |
||
Bildschirmfoto bearbeiten |
Verwaltung |
|
Übersetzungskoordinator |
||
Bildschirmfotos verwalten |
||
Bildschirmfoto löschen |
Verwaltung |
|
Übersetzungskoordinator |
||
Bildschirmfotos verwalten |
||
Ausgangszeichenketten |
Zusätzliche Zeichenketteninformationen bearbeiten |
Verwaltung |
Quelle bearbeiten |
||
Zeichenketten |
Neue Zeichenkette hinzufügen |
Verwaltung |
Eine Zeichenkette entfernen |
Verwaltung |
|
Fehlerhafte Prüfung verwerfen |
Verwaltung |
|
Quelle bearbeiten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Zeichenketten bearbeiten |
Verwaltung |
|
Quelle bearbeiten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Zeichenketten überprüfen |
Verwaltung |
|
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Massenbearbeitung von Zeichenketten |
Verwaltung |
|
Massenbearbeitung |
||
Zeichenkette bearbeiten, wenn Vorschläge erzwungen werden |
Verwaltung |
|
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Ausgangszeichenketten bearbeiten |
Verwaltung |
|
Quelle bearbeiten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Vorschläge |
Vorschlag annehmen |
Verwaltung |
Quelle bearbeiten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Vorschlag hinzufügen |
Verwaltung |
|
Quelle bearbeiten |
||
Vorschlag hinzufügen |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Vorschlag löschen |
Verwaltung |
|
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Über Vorschlag abstimmen |
Verwaltung |
|
Quelle bearbeiten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Übersetzungen |
Sprache zur Übersetzung hinzufügen |
Verwaltung |
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Sprachen verwalten |
||
Automatische Übersetzung durchführen |
Verwaltung |
|
Automatische Übersetzung |
||
Vorhandene Übersetzung löschen |
Verwaltung |
|
Sprachen verwalten |
||
Übersetzungsdatei herunterladen |
Verwaltung |
|
Quelle bearbeiten |
||
Auf Repository zugreifen |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Sprachen verwalten |
||
Mehrere Sprachen zur Übersetzung hinzufügen |
Verwaltung |
|
Sprachen verwalten |
||
Uploads |
Autor der hochgeladenen Übersetzung definieren |
Verwaltung |
Vorhandene Zeichenketten mit Upload überschreiben |
Verwaltung |
|
Quelle bearbeiten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Übersetzungen hochladen |
Verwaltung |
|
Quelle bearbeiten |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Zeichenketten überprüfen |
||
Übersetzen |
||
Versionsverwaltung |
Zugriff auf das interne Repository |
Verwaltung |
Auf Repository zugreifen |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Repository verwalten |
||
Commit für Änderungen am internen Repository durchführen |
Verwaltung |
|
Repository verwalten |
||
Änderung aus dem internen Repository pushen |
Verwaltung |
|
Repository verwalten |
||
Änderungen im internen Repository zurücksetzen |
Verwaltung |
|
Repository verwalten |
||
Speicherort des Upstream-Repositorys anzeigen |
Verwaltung |
|
Auf Repository zugreifen |
||
Hauptbenutzer |
||
Übersetzungskoordinator |
||
Repository verwalten |
||
Aktualisieren des internen Repositorys |
Verwaltung |
|
Repository verwalten |
||
Mitteilungen |
Mitteilungen veröffentlichen |
Verwaltung |
Übersetzungskoordinator |
||
Mitteilungen löschen |
Verwaltung |
|
Übersetzungskoordinator |
||
Arbeitsbereiche |
Arbeitsbereicheinstellungen bearbeiten |
Arbeitsbereich-Verwaltung |
Projekte zum Arbeitsbereich hinzufügen |
Arbeitsbereich-Verwaltung |
|
Arbeitsbereich-Projekte hinzufügen |
||
Arbeitsbereichszugriff verwalten |
Arbeitsbereich-Verwaltung |
|
Plattformweite Berechtigungen |
Browse users |
Discover users |
Search resource contributors |
Discover users |
|
View user profiles |
View user profiles |
|
Verwaltungsoberfläche verwenden |
||
Plattformkonfiguration verwalten |
||
Neue Projekte hinzufügen |
Neue Projekte hinzufügen |
|
Neue Arbeitsbereiche hinzufügen |
Neue Projekte hinzufügen |
|
Sprachdefinitionen hinzufügen |
||
Sprachdefinitionen verwalten |
||
Teams verwalten |
||
Teaminformationen anzeigen |
||
Benutzer verwalten |
||
Benutzerinformationen anzeigen |
||
Rollen verwalten |
||
Rolleninformationen anzeigen |
||
Mitteilungen verwalten |
||
Übersetzungsspeicher verwalten |
||
Übersetzungsdienste verwalten |
||
Komponentenlisten verwalten |
||
Abrechnung verwalten |
||
Plattformweite Erweiterungen verwalten |
Warnung
Rollen haben keinen separaten Geltungsbereich; die Berechtigungen einer Rolle bestimmen deren Geltungsbereich. Eine Rolle, die eine unter Plattformweite Berechtigungen aufgeführte Berechtigung enthält, gewährt diese Berechtigung in der gesamten Weblate-Instanz, wenn sie über ein plattformweites Team zugewiesen wird. Die Projektauswahl des Teams schränkt diese Berechtigungen nicht ein.
Site-wide privileges are not granted to any default role. Treat any roles
containing them, including customized built-in roles, as trusted administrative
access because some are effectively equivalent to superuser status. For example, group.edit
allows changing team scope to grant access to private projects, and
user.edit allows users to change their own team memberships and grant
themselves superuser status. See Plattformweite Teamverwaltung and
site-wide user management for details.
Liste der integrierten Rollen¶
Discover users |
|
View user profiles |
|
Verwaltung |
|
Ausgangssprache bearbeiten |
|
Vorschlag hinzufügen |
|
Auf Repository zugreifen |
|
Glossar verwalten |
|
Hauptbenutzer |
|
Übersetzungskoordinator |
|
Zeichenketten überprüfen |
|
Übersetzen |
|
Sprachen verwalten |
|
Massenbearbeitung |
|
Automatische Übersetzung |
|
Übersetzungsspeicher verwalten |
|
Bildschirmfotos verwalten |
|
Repository verwalten |
|
Arbeitsbereich-Verwaltung |
|
Arbeitsbereich-Projekte hinzufügen |
|
Neue Projekte hinzufügen |
|
Liste der Teams¶
Die folgenden Teams werden bei der Installation (oder nach dem Ausführen von setupgroups) erstellt, und Sie können diese nach Belieben ändern. Wenn Sie die Gruppen jedoch löschen oder umbenennen, werden sie bei der Migration neu erstellt.
- Gäste
Legt die Berechtigungen für nicht authentifizierte Benutzer fest.
Dieses Team enthält ausschließlich anonyme Benutzer (siehe
ANONYMOUS_USER_NAME).Entfernen Sie Rollen aus diesem Team, um die Berechtigungen für nicht authentifizierte Benutzer einzuschränken.
Default roles: Add suggestion, Access repository, View user profiles
- Betrachter
Diese Rolle stellt die Sichtbarkeit der öffentlichen Projekte für alle Benutzer sicher. Standardmäßig sind alle Benutzer Mitglieder dieses Teams.
Standardmäßig werden alle neuen Konten durch automatische Teamzuweisungen zu Mitgliedern dieses Teams, wenn sie beitreten.
Standardrollen: keine
- Benutzer
Standardteam für alle Benutzer.
Standardmäßig werden alle neuen Konten durch automatische Teamzuweisungen zu Mitgliedern dieses Teams, wenn sie beitreten.
Default roles: Power user, Discover users, View user profiles
- Prüfer
Gruppe für Prüfer (siehe Übersetzungsabläufe).
Standardrollen: Zeichenketten überprüfen
- Manager
Gruppe für Administratoren.
Standardrollen: Verwaltung
- Projektersteller
Added in version 5.1.
Benutzer, die neue Projekte erstellen können.
Standardrollen: Neue Projekte hinzufügen
Warnung
Entfernen Sie niemals die vordefinierten Weblate-Teams und -Benutzer, da dies zu unerwarteten Problemen führen kann! Wenn Sie keine Verwendung für sie haben, entfernen Sie stattdessen einfach alle ihre Berechtigungen.
Zusätzliche Zugriffsbeschränkungen¶
Wenn Sie Ihre Weblate-Installation weniger öffentlich nutzen möchten, d. h. neue Benutzer nur per Einladung zulassen möchten, können Sie Weblate so konfigurieren, dass nur bekannte Benutzer Zugriff darauf haben. Dazu müssen Sie REGISTRATION_OPEN auf False setzen, um die Registrierung neuer Benutzer zu verhindern, und REQUIRE_LOGIN auf True setzen, um eine Anmeldung für den Zugriff auf alle Seiten der Website zu verlangen. Auf diese Weise können Sie Ihre Weblate-Installation grundsätzlich sperren.
Außerdem werden durch die Änderung von DEFAULT_ACCESS_CONTROL in 100 alle neu erstellten Projekte privat, so dass explizit Zugriff gewährt werden muss.
Hinweis
Um neue Benutzer hinzuzufügen können Sie die integrierte Funktion Neue Benutzer einladen verwenden.
Ablauf von Benutzerkonten¶
Für jedes Benutzerkonto kann ein Ablaufdatum festgelegt werden. Nach Ablauf der Frist wird das Benutzerkonto automatisch deaktiviert. Dies wird für Zugangstoken pro Projekt verwendet, kann aber auch für normale Benutzer genutzt werden.
See Privacy configuration to configure user discovery and profile access through roles.