werkator build succeeded after 00:40
Co-authored-by: claude-code <claude-code@javagil.de>
125 lines
5.4 KiB
Markdown
125 lines
5.4 KiB
Markdown
# 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](../../dashboard/src/test/kotlin/de/hoennig/werkregie/dashboard/sources/TaigaSourceTest.kt): "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](../../dashboard/src/test/kotlin/de/hoennig/werkregie/dashboard/sources/TaigaSourceTest.kt): "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](../../dashboard/src/test/kotlin/de/hoennig/werkregie/dashboard/sources/TaigaSourceTest.kt): "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](../../dashboard/src/test/kotlin/de/hoennig/werkregie/dashboard/sources/TaigaSourceTest.kt): "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](../../dashboard/src/test/kotlin/de/hoennig/werkregie/dashboard/sources/TaigaSourceTest.kt): "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
|
|
|
|
- [x] 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.
|