Zwei Entscheidungen, die wie dieselbe aussehen, aber zwei verschiedene Systeme sind
Ein Admin gibt einem Teammitglied die Projekt-Rolle Admin und geht davon aus, damit ist auch der Zugriff auf die Repositories im Projekt geregelt. Oder umgekehrt: jemand hat Write-Zugriff auf alle beteiligten Repositories und bekommt deshalb automatisch Zugriff auf das Projekt dazu. Beide Annahmen sind falsch. GitHub Projects (v2) hat ein eigenes Rollenmodell, das unabhängig von den Repository-Rollen funktioniert. Was dabei trotzdem verzahnt bleibt, ist die Sichtbarkeit einzelner Einträge, und genau dort liegt der Punkt, der beim Aufsetzen eines Rollenmodells am häufigsten übersehen wird.
Die vier Projekt-Rollen: No access, Read, Write, Admin
Für ein organisationsweites Projekt gilt laut Dokumentation zunächst eine Basisrolle, die für alle Mitglieder außer den Organisationsinhabern gilt: No access (nur Inhaber und einzeln eingeladene Personen sehen das Projekt), Read (alle Mitglieder sehen das Projekt), Write (alle Mitglieder sehen und bearbeiten das Projekt) und Admin (alle Mitglieder sind Admin des Projekts). Für einzeln eingeladene Teams, Personen, Outside Collaborators und für Projekte auf Nutzerebene gelten drei Rollen: Read (ansehen), Write (ansehen und bearbeiten) und Admin (ansehen, bearbeiten, neue Mitwirkende einladen). Eine Rolle „No access“ gibt es auf dieser Ebene nicht, nur auf der Basisrolle der gesamten Organisation.
Was eine Projekt-Rolle nicht regelt
Die Dokumentation ist an dieser Stelle eindeutig und als Hinweis direkt im Abschnitt zu Projekten auf Nutzerebene platziert: „This only affects collaborators for your project, not for repositories in your project.“ Eine Projekt-Rolle, egal ob Read, Write oder Admin, verändert also nichts an den Berechtigungen für die Repositories, deren Issues und Pull Requests im Projekt verwaltet werden. Wer Admin eines Projekts ist, kann das Projekt selbst administrieren, Felder anlegen, Ansichten ändern, Mitwirkende einladen, aber damit noch keine Repository-Rechte mitbringen.
Die Nahtstelle: Sichtbarkeit bleibt an die Repo-Berechtigung gekoppelt
Umgekehrt heißt das nicht, dass beide Systeme nichts miteinander zu tun haben. An genau einer Stelle greifen sie ineinander, und zwar bei der Sichtbarkeit einzelner Einträge: „To view an item on the project, someone must have the required permissions for the repository that the item belongs to.“ Wer also Write- oder sogar Admin-Rolle im Projekt hat, aber auf das zugehörige Repository keinen Zugriff besitzt, sieht das daraus verknüpfte Issue oder den Pull Request im Projekt trotzdem nicht. Für private Repositories gilt laut Dokumentation entsprechend: „Only people with access to a private repository will be able to view project items from that private repository.“ Die Projekt-Rolle öffnet die Tür zum Projekt, die Repo-Berechtigung entscheidet, was dahinter sichtbar wird.
Ein Blick in die REST-API: wo die tatsächliche Berechtigung steht
Welche Berechtigung eine Person tatsächlich auf einem Repository hat, lässt sich über GET /repos/{owner}/{repo}/collaborators/{username}/permission abfragen. Die Antwort enthält laut Schema unter anderem die Felder permission und role_name:
{ "permission": "write", "role_name": "write", "user": { "login": "octocat", "id": 1 }}
Dieser Wert ist es, der darüber entscheidet, ob ein verknüpftes Issue im Projekt sichtbar wird, nicht die Rolle, die dieselbe Person im Projekt selbst hat. Die beiden Werte stehen in zwei getrennten Datenmodellen und werden auch getrennt abgefragt.
Rollen setzen: nur über die Oberfläche, nicht über API oder CLI
Die Dokumentation beschreibt das Setzen der Projekt-Rollen ausschließlich über die Oberfläche: im Projektmenü auf „Settings“, dort unter „Manage access“ die Basisrolle setzen oder über „Invite collaborators“ einzelne Personen mit einer Rolle einladen. Einen Weg über die REST- oder GraphQL-API oder über gh project beschreibt die Dokumentation an dieser Stelle nicht, und gh project selbst hat unter seinen Unterbefehlen (item-list, field-list, view, edit und weiteren) keinen für Zugriffsrollen. Wer Projekt-Rollen automatisiert prüfen oder setzen will, findet dafür in der offiziellen CLI aktuell keinen eigenen Befehl.
Konsequenz fürs eigene Rollenmodell
Wer ein Rollenmodell für eine GitHub-Organisation dokumentiert, muss Projects deshalb als eigene Ebene führen, nicht als Ableitung aus den Repository-Rollen. Eine Tabelle mit Repo-Rollen beantwortet nicht, wer ein Projekt sehen, bearbeiten oder administrieren darf, und eine Tabelle mit Projekt-Rollen beantwortet nicht, wer die verknüpften Issues tatsächlich zu sehen bekommt. Wie sich Team-Zuweisung und direkte Rechte zur tatsächlich wirksamen Repo-Berechtigung addieren, steht in Effektive vs. nominale Rechte in GitHub, wie du den bestehenden Rechte-Bestand wiederkehrend prüfst, in Berechtigungs-Reviews in GitHub-Organisationen. Beide Beiträge behandeln die Repository-Ebene. Projects ist eine eigene, dritte Ebene daneben, die in einem vollständigen Review genauso geprüft werden muss wie die beiden anderen.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen