Boards, Spalten und Lanes

Ein Board liegt in einer Collection. Collections sind die Art, wie Boards gruppiert werden — „Produkt", „Kundenarbeit", „Intern" —, und ein Board sitzt an der Wurzel einer Collection, nie unter einem anderen Board.

Ein Board ist dreierlei zugleich, und es lohnt sich, das zu trennen:

Ein Raster — seine Spalten und Lanes.
Ein Dokument — ein Textkörper über dem Raster, in den man schreibt.
Eine Menge Karten — die Seiten sind und eine eigene Seite haben.

Das Raster

Spalten sind die Stationen: Zu tun, In Arbeit, Fertig. Jede hat eine Beschriftung und, wenn Sie möchten, ein Symbol. Eine Farbe hat sie nicht, und das ist Absicht: Sie wäre eine zweite Marke neben dem Symbol, und die schwächere von beiden — eine Farbe muss man je Board lernen, ein Zeichen nicht.

Lanes sind die waagerechte Teilung: nach Team, nach Arbeitsstrang, nach Kunde. Eine Lane hat eine Beschriftung und sonst nichts — die Marke tragen die Spalten, und beide zu markieren ergibt ein Board, das in zwei Richtungen gleichzeitig ruft.

Beides sind schlicht Listen am Board. Spalten umzuordnen heißt, die Liste umzuordnen. Einklappen lässt sich beides, und die stille Zeile für Karten ohne Lane ebenso; dieser Zustand steht am Board, eine Spalte klappt also für alle zu, die das Board öffnen.

curl -X PATCH "$BASE/api/v1/workspaces/$WS/boards/$BOARD" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "columns": [
      { "id": "…uuid…", "label": "Zu tun"  },
      { "id": "…uuid…", "label": "In Arbeit"  },
      { "id": "…uuid…", "label": "Fertig" }
    ]
  }'

Drei Eigenschaften dieses Aufrufs tragen:

Die Liste wird ganz ersetzt, nicht verschmolzen. Schicken Sie jede Spalte mit, die bleiben soll. Es gibt keinen Aufruf „eine Spalte hinzufügen" — zwei Clients, die je eine Spalte an eine unvollständige Liste hängen, sind genau der Weg, auf dem ein Board still eine Station verliert.
Die Kennungen vergeben Sie. Die Kennung einer Spalte gehört Ihnen und gilt nur für dieses Board. Genau das erlaubt, „In Arbeit" in „In Bearbeitung" umzubenennen, ohne eine einzige Karte anzufassen: Die Karten zeigen auf die Kennung, nicht auf die Beschriftung.
Eine Spalte zu löschen verschiebt ihre Karten nicht. Sie behalten die Kennung, die sie hatten, und die gruppierte Abfrage meldet sie darunter. Nichts geht verloren, und nichts wird still einer Station zugeschlagen, die Sie nicht gewählt haben — aber ein Board in diesem Zustand hat Karten, die Sie im Raster nicht sehen, bis Sie die Spalte wieder anlegen oder die Karten verschieben.

Ein neues Board beginnt ohne Spalten und ohne Lanes. Der Server hat keine Meinung dazu, wie Ihre ersten drei Spalten heißen sollten; das entscheidet, was das Board anlegt.

Der Textkörper des Boards

Ein Board trägt ein eigenes Dokument über dem Raster — derselbe Editor, den auch eine Seite hat. Er ist für das, was eine Spaltenüberschrift nicht sagen kann: wofür dieses Board da ist, wie es geführt wird, was „Fertig" hier bedeutet.

Karten lassen sich in diesen Textkörper einbetten, ein Absatz kann also auf die Karte zeigen, um die es geht, und die Karte bleibt eine Karte.

Kommentare am Textkörper des Boards sind nicht gebaut. Kommentare an Karten schon.

Ein Board lesen

Ein Board wird in einer Anfrage gelesen, gruppiert:

GET /api/v1/workspaces/{workspaceId}/boards/{boardId}/cards

Die Antwort sind Gruppen aus (Spalte × Lane), jede mit einem Fenster von Karten, einem eigenen Cursor und einer Gesamtzahl. Diese Form ist der Punkt: Ein Board mit zehntausend Karten muss den Kopf jeder Spalte zeichnen, ohne jede Karte zu lesen, und ein Board als eine flache Liste zu blättern kann das nicht. windowSize legt fest, wie viele Karten je Gruppe kommen.

Zweierlei sollte man erwarten:

Ein leeres Board hat keine Gruppen, nicht eine leere Gruppe je Spalte. Gruppen entstehen aus Karten.
Es gibt eine Gruppe ohne Spalte — die Karten, die nie platziert wurden. Eine Zeile, die über die allgemeine Zeilen-API in die Datenbank hinter dem Board kommt, landet dort. Ohne diese Gruppe gäbe es solche Karten, und man käme nicht an sie heran.

Ein Board wird betrachterabhängig gelesen. Eine Karte, deren Seite Sie nicht lesen dürfen, fehlt ganz, statt als Platzhalter zu erscheinen — Zahlen und Cursor sind also von Person zu Person verschieden. Das ist dieselbe Regel wie sonst überall: „Sie dürfen es nicht sehen" und „es gibt es nicht" sehen absichtlich gleich aus.

Rechte

Auflisten und Lesen eines Boards braucht read auf seiner Collection.
Anlegen braucht edit auf der Collection.
Ändern eines Boards — Titel, Symbol, Spalten, Lanes — braucht edit auf dem Board.
Löschen braucht full. Es geht in den Papierkorb und nimmt die Datenbank dahinter mit aus der Reichweite.

Eine Karte zu verschieben regelt das Board, nicht die Seite der Karte. Wer edit auf dem Board hat, darf eine Karte ziehen, deren Seite er nicht lesen darf — er ändert, wo eine Karte liegt, nicht, was sie sagt. Diese Karte zu öffnen braucht weiterhin read auf der Seite, und darin zu schreiben edit.

Diese Trennung ist es, die ein Board in einem Team benutzbar macht, in dem nicht alles für alle lesbar ist.

Ein Board ist keine Datenbankansicht

Falls Sie typisierte Datenbanken mit gespeicherten Ansichten kennen: Ein Board ist keine davon mit angeschraubtem Kanban-Layout. Es ist eine eigene Art Dokument, Geschwister einer Seite, mit eigenem Textkörper und eigener Konfiguration. Hinter seinen Karten sitzt zwar eine Datenbank, die das Board sich selbst anlegt und verwaltet — aber das Raster gehört dem Board, nicht einer Ansicht.

Was ein Board nicht kann

Keine WIP-Limits. Nichts zählt die Karten einer Spalte gegen eine Obergrenze.
Keine Filter und keine Sortierung. Ein Board steht immer in Board-Reihenfolge — der Reihenfolge, in der Karten platziert wurden. Es gibt kein „nur meine", kein „nach Priorität sortieren".
Keine Vorlagen, keine Automatisierungen, keine Kartenbilder, kein öffentlicher Freigabelink.
Kein Import aus einem anderen Werkzeug.

Jeder dieser Punkte ist eine protokollierte Entscheidung und kein Versehen, und keiner davon steht kurz bevor.