werkregie/doc/prs/2026-10-11-PR#21-taiga.md

PR#21: Taiga Stories, Tasks and Issues Assigned to the User

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

Problem

The user plans the work in Taiga: user stories, tasks and issues of several projects. Werkregie shows what the agents and the pipeline do, but not what the user is to work on next.

Non-Goals

• No link between a story and its pull requests or its Werkbaum node; that is a follow-up PR.
• No writing to Taiga.
• No other task board than Taiga yet, but the configuration leaves room for them.

Specification

Feature: the user's Taiga items in the panel "Aufgaben"

Scenario#21.01: the open items assigned to the user show

… so that the user sees in Werkregie what to work on.

• Given a task board of type taiga with the projects shop and the user's credentials
• When the dashboard reads it
• Then each open user story, task and issue of shop assigned to the user is a row in "Aufgaben", with its subject, status, project, "US #600" and a link to its Taiga page

Verified by

• TaigaSourceTest: "the open stories, tasks and issues assigned to the user, in each configured project".
• Manual: the demo shows three rows "US #214", "Task #88" and "Issue #41" in "Aufgaben"; a second instance in mode server without token, on port 4748 by --config, beside the running one on 4747.

Scenario#21.02: the configured statuses come first

… so that the items in work and the ready ones stand at the top.

• Given the statuses "In Arbeit", "Bereit"
• When the page shows items in "Bereit", "In Arbeit" and "Neu"
• Then the order is "In Arbeit", "Bereit", "Neu"; a status matches regardless of case

Verified by

• TaigaSourceTest: "the configured statuses rank first, in their order; any other open status after them".
• Manual: the demo shows "In Arbeit", "Bereit", "Neu" in this order.

Scenario#21.03: one login lasts until the token expires

… so that Werkregie does not log in every minute.

• Given a source that has logged in
• When Taiga rejects the token with 401
• Then the source logs in once more and reads again

Verified by

• TaigaSourceTest: "one login serves many fetches; an expired token leads to one new login".

Scenario#21.04: a failed login keeps the password secret

… so that the error shown on the page carries no secret.

• Given a wrong password
• When the dashboard reads Taiga
• Then the source reports a failed login for the user, without the password

Verified by

• TaigaSourceTest: "a failed login names the user, never the password".

Scenario#21.05: a missing setting is named

… so that the user knows what to add to the configuration.

• Given a task board without projects, or without a password in its variable
• When the dashboard reads it
• Then the source reports the missing setting by its name

Verified by

• TaigaSourceTest: "without projects or password the source says what is missing".

Scenario#21.06: no task board, no panel

… so that a page without Taiga does not show an empty panel.

• Given a configuration without taskboards
• When the page shows the dashboard
• Then the panel "Aufgaben" is hidden, and the sessions stay in their panel

Verified by

• Manual: a second instance in mode local, on port 4748 by --config with the user's configuration without taskboards: "Aufgaben" hidden, 9 sessions, 22 pull requests.

Solution

• taskboards in dashboard.yml: a list of task boards with name, type, url, username or usernameEnv, passwordEnv, projects and statuses; only type: taiga exists, another type stops the start with a message.
• TaigaSource logs in with POST /api/v1/auth and keeps the token until Taiga rejects it. Per project it resolves the slug and reads userstories by assigned_users, tasks and issues by assigned_to, each with status__is_closed=false and without pagination.
• Item.rank carries the place of the status in statuses; the page sorts "Aufgaben" by it, then by the latest change.
• JsonHttp.post for the login; its errors never carry the body.
• The panel "Offene Sessions" takes sessions only, no longer everything open that is no pull request or message.
• The demo, the example configurations and dashboard/README.md show the task board.
• Version 0.9.0.

Open Questions

• Does the user's Taiga answer as the tests assume? The fake follows the Taiga API documentation; the check against the user's instance follows the deployment, with the user's credentials in dashboard.env.

Additional Changes

• Werkbaum: the PWA is checked offline on Android; iOS and desktop stay open.

Follow-up PRs

• A story links to its pull requests and its Werkbaum node.