“Irgendwas sieht anders aus und funktioniert plötzlich nicht mehr.” Diesen Satz hören wir im Support immer mal wieder. Meist steckt kein Fehler dahinter, sondern das Rechtesystem von Redmine - ein Bereich, den viele Teams seit der Erstinstallation nie bewusst angefasst haben. Solange alles läuft, fällt das nicht auf. Sobald sich aber etwas ändert, beispielsweise nach einem Update oder beim Anlegen einer neuen Rolle, beginnt das Rätselraten.
Dieser Beitrag richtet sich an Redmine-Administratoren und Projektverantwortliche, die ihr Rechtesystem optimieren wollen (tiefes technisches Wissen brauchst du dafür nicht). Wir erklären, wie das Berechtigungssystem aufgebaut ist, und geben dir eine kompakte Liste an Do’s und Don’ts für ein nachvollziehbares, zukunftsicheres Konzept.
Warum ist das für Redmine-Administratoren wichtig?
Ein sauberes Rollenkonzept hält dein Redmine übersichtlich - auch wenn neue Projekte und Leute dazukommen. Unklare Rechte kosten dich Zeit bei jeder Rückfrage. Und sie sind ein Sicherheitsthema: Wenn jemand mehr sieht oder darf als gedacht, fällt das oft erst spät auf. Wer die Rechte einmal bewusst aufsetzt und kurz dokumentiert, spart sich später das Rätselraten vom Anfang.
Die zwei Ebenen, an denen die meisten scheitern
Redmine verteilt Rechte nicht an einzelne Personen, sondern an Rollen. Eine Rolle wird einmal zentral unter Administration -> Rollen und Rechte definiert. Sie ist im Kern eine Sammlung von Berechtigungen. Eine Person bekommt diese Rolle anschließend pro Projekt zugewiesen, und damit greifen deren Rechte. Wichtig ist die Frage, wo ein Recht überhaupt wirkt:
Die meisten Berechtigungen werden pro Projekt ausgewertet. Sie steuern, was eine Rolle innerhalb eines bestimmten Projekts darf: Tickets sehen, Tickets bearbeiten, Wiki pflegen, Dateien hochladen und so weiter. Sie greifen nur in den Projekten, in denen der Person die Rolle zugewiesen ist. Dieselbe Person kann also in Projekt A mehr dürfen als in Projekt B - je nach dort zugewiesener Rolle.
Nur wenige Berechtigungen gelten systemweit (global). Sie sind an kein einzelnes Projekt gebunden. Das bekannteste Beispiel ist Projekt anlegen: Wer dieses Recht über seine Rolle hat, darf neue Projekte erstellen, unabhängig von einem bestehenden Projekt. Das Verwalten eines bestehenden Projekts - also bearbeiten, schließen oder Mitglieder verwalten - ist dagegen projektbezogen: Diese Rechte vergibst du pro Rolle, und sie gelten nur in den Projekten, in denen jemand diese Rolle hat. In der Praxis steckt das oft in der Manager-Rolle. Wer ein Projekt anlegt, bekommt darin außerdem automatisch eine festgelegte Rolle - in vielen Installationen Manager (einstellbar in den Projekt-Einstellungen) - und darf sein Projekt deshalb anschließend auch verwalten.
Eine gute Gesamtübersicht liefert dir der Berechtigungsbericht unter Administration -> Rollen und Rechte. Dort siehst du alle Rollen und ihre Rechte als Matrix nebeneinander und erkennst auf einen Blick, wo eine Rolle mehr oder weniger darf als gedacht.
Der dritte, oft übersehene Punkt:
- Ein Recht greift nur, wenn das zugehörige Modul im Projekt aktiviert ist. Wer das Wiki-Modul im Projekt deaktiviert hat, dem nützt das Wiki-Recht nichts. Genau hier entsteht die häufigste Verwirrung - das Recht ist gesetzt, aber die Funktion taucht nicht auf, weil das Modul fehlt.
Sonderfall Nichtmitglied und Anonymous: Diese beiden eingebauten Rollen sorgen besonders oft für Unsicherheit, weil sie sich anders verhalten als normale Projektrollen. Du weist sie niemandem manuell zu, sie greifen automatisch und nur in öffentlichen Projekten. Nichtmitglied gilt für angemeldete Benutzer, die im Projekt kein Mitglied sind; das kann auch intern relevant sein, wenn ein Projekt für alle Mitarbeitenden sichtbar sein soll. Anonymous gilt dagegen für gar nicht angemeldete Besucher und greift nur, wenn anonymer Zugriff überhaupt erlaubt ist (Einstellung Authentifizierung erforderlich deaktiviert). In einem internen, datenschutzbewussten Redmine ist das meist nicht so - dann hat die Anonymous-Rolle gar keine Wirkung und ist eher ein Thema für öffentlich zugängliche Redmines. Sei bei beiden trotzdem sparsam: Was du hier erlaubst, gilt für jeden.
Do’s
Arbeite nach dem Least-Privilege-Prinzip. Fang lieber eng an und erweitere gezielt, wenn ein Bedarf entsteht. Das ist deutlich einfacher, als hinterher zu klären, warum eine Rolle Rechte hat, die niemand mehr begründen kann.
Arbeite im Alltag nicht mit Administratorrechten. Ein Administrator umgeht in Redmine alle Berechtigungsprüfungen - für ihn funktioniert immer alles, egal wie die Rollen gesetzt sind. Einen Fehler in den Rechten merkt er so nie. Der betroffene Anwender wiederum weiß gar nicht, was er können sollte, und meldet es deshalb auch nicht - oder er hält gleich das ganze System für schlecht, dabei stimmt nur die Konfiguration nicht. Gewöhn dir darum an, mit einem normalen Benutzerkonto zu arbeiten und Änderungen damit zu prüfen. Mit deinem Hintergrundwissen erkennst du am ehesten, wenn etwas nicht so läuft, wie du es gedacht hast.
Weniger ist mehr - bilde nicht jede Unternehmensrolle 1:1 ab. Nur weil es im Organigramm Teamleitung, Fachbereich und drei Abteilungen gibt, braucht Redmine nicht für jede dieser Stellen eine eigene Rolle. Redmine-Rollen orientieren sich an Tätigkeiten im Projekt, nicht an Stellenbezeichnungen. Oft reichen ein paar gut zugeschnittene Rollen für das, wofür sonst ein Dutzend kaum unterscheidbarer Rollen angelegt wird. Je weniger Rollen du pflegen musst, desto leichter bleibt das Ganze nachvollziehbar.
Benenne Rollen nach ihrer Funktion - und halte das auch ein. Eine Rolle “Manager mit Löschfunktion” sollte auch tatsächlich löschen dürfen. Klingt selbstverständlich, ist es in der Praxis aber nicht: Wir sehen regelmäßig Rollennamen, die ein Recht versprechen, das gar nicht hinterlegt ist. Spätestens beim nächsten Audit kostet das Zeit und Nerven.
Prüfe nach jedem Plugin-Update kurz die Rechte. Updates können neue Berechtigungen mitbringen oder bestehende anders einsortieren. Ein kurzer Blick auf die betroffenen Rollen erspart dir die Rückfrage “warum ist das jetzt anders?”.
Dokumentiere dein Rollenkonzept einmal sauber. Eine knappe Übersicht, welche Rolle wofür gedacht ist, reicht schon. Sie hilft jedem, der später dazukommt - und dir selbst, wenn du in einem Jahr nicht mehr weißt, warum du was entschieden hast.
Don’ts
Häufe nicht alles auf eine Sammelrolle. Eine einzige “Mitarbeiter”-Rolle, die alles darf, ist bequem, aber nicht steuerbar. Sobald jemand etwas weniger dürfen soll, musst du eine zweite Rolle bauen und stehst wieder am Anfang.
Schließe nicht von der Position auf die Rechte. Ein Geschäftsführer braucht in Redmine nicht automatisch Administratorrechte oder darf alles, nur weil er an der Spitze steht. Frag nicht “welche Position hat die Person?”, sondern “was muss die Person in Redmine tun, um ihre Aufgabe zu erfüllen?”. Rechte sollen die Funktion im Unternehmen unterstützen, nicht den Rang abbilden.
Wichtig: Der Administrator-Status ist in Redmine keine Rolle, sondern ein eigener Schalter im Benutzerprofil. Er übergeht das ganze Rollen- und Rechtesystem und sollte nur an Leute gehen, die Redmine wirklich administrieren - nicht an die mit dem höchsten Rang.
Vermeide zwei fast gleich benannte Rollen mit unterschiedlichen Rechten. Oft gibt es einen guten Grund für zwei ähnliche Rollen - zum Beispiel interne und externe Entwickler, die unterschiedlich viel dürfen sollen. Nur heißen sie dann gern “Entwicklung” und “Mitarbeiter Entwicklung”, und nach ein paar Monaten weiß niemand mehr, welche welche ist. Wenn der Unterschied wichtig ist, mach ihn im Namen eindeutig - etwa “Entwicklung intern” und “Entwicklung extern”. So steht der eigentliche Grund direkt im Rollennamen.
Ändere nicht im Live-Betrieb wild an Rechten herum. Teste Änderungen an einem unkritischen Testprojekt oder zumindest mit einer Testrolle, bevor du sie systemweit ausrollst.
So könnte ein einfaches Rollenkonzept aussehen
Damit ein Team sieht, welche Rolle was darf arbeitet man ein Rollenkonzept aus und veröffentlicht das am Besten in einer für alle zugänglichen Redmine Wiki-Seite. Im Idealfall sind die Rollen nach Funktion benannt und die Berechtigungen werden pro Rolle erweitert.
| Bereich | Berechtigung | Melder | Bearbeiter | Manager |
|---|---|---|---|---|
| Tickets | Tickets sehen | ✓ | ✓ | ✓ |
| Tickets | Tickets anlegen | ✓ | ✓ | ✓ |
| Tickets | Notizen hinzufügen | ✓ | ✓ | ✓ |
| Tickets | Tickets bearbeiten | - | ✓ | ✓ |
| Tickets | Tickets löschen | - | - | ✓ |
| Zeiterfassung | Aufgewendete Zeit buchen | - | ✓ | ✓ |
| Wiki | Wiki-Seiten bearbeiten | - | ✓ | ✓ |
| Dateien | Dateien hochladen | - | ✓ | ✓ |
| Projekt | Projekt bearbeiten | - | - | ✓ |
| Projekt | Mitglieder verwalten | - | - | ✓ |
| Projekt | Versionen verwalten | - | - | ✓ |
Tickets löschen: Redmine ist unter anderem auch ein Nachschlagewerk dafür, was wann wie in einem Projekt mal passiert ist - gelöschte Tickets reißen Lücken in diese Historie. Löschen gehört deshalb immer in Manager- oder sogar Admin-Hand.
Plugins bringen eigene Rechte mit
Wer kommerzielle Plugins einsetzt, sollte wissen, dass diese in der Regel ihre eigenen Berechtigungssektionen mitbringen. Beim Templates-Plugin etwa gibt es eine eigene Sektion, die zusätzlich zu den Standardrechten gesteuert wird. Das ServiceDesk-Plugin verhält sich ähnlich. Nach der Installation oder einem Update lohnt sich deshalb der Blick nicht nur auf die Standardrechte, sondern auch auf die plugin-spezifischen Abschnitte unter Administration -> Rollen und Rechte.
Schneller zum Konzept mit dem Redmine AI Plugin
Wer mit unserem Redmine AI Plugin bereits arbeitet, kann sich ein solches Konzept übrigens vom KI-Assistenten entwerfen lassen. Du beschreibst ihm direkt in Redmine deine Teams und ihre Aufgaben, und er liefert einen Vorschlag. Eingerichtet wird weiterhin von Hand, der Entwurf erleichtert dir jedoch den Start.
So kann zum Beispiel der Prompt aussehen:
Hilf mir, ein Rollen- und Rechtekonzept für unser Redmine zu entwerfen (deutsche Oberfläche). Arbeite nach dem Least-Privilege-Prinzip. Unsere Gruppen: interne Entwickler (arbeiten aktiv an Tickets, buchen Zeit), externe Entwickler (zeitweise im selben Projekt, sollen nur eigene Tickets sehen, keine fremden Zeitbuchungen, kein Löschen), Projektleitung. Schlage gestaffelte Rollen nach Funktion vor, liste je Rolle die konkreten Redmine-Berechtigungen auf, vergib Löschrechte nur an Manager/Admin und gib das Ergebnis als Berechtigungsmatrix aus.
Den Vorschlag übernimmst du nicht blind: Gleich ihn mit den Do’s und Don’ts aus diesem Beitrag ab und teste ihn mit einem normalen Benutzerkonto. Das AI Plugin ist als monatliches Add-on zu unserem Managed Redmine Hosting verfügbar.
Fazit
Das Rechtesystem von Redmine ist mächtig, aber kein Hexenwerk - vorausgesetzt, man behandelt es bewusst statt es einfach laufen zu lassen. Wer einmal ein klares, dokumentiertes Rollenkonzept aufsetzt und es nach Updates kurz gegencheckt, erspart sich genau das Rätselraten, mit dem dieser Beitrag begonnen hat.