feat(status): add --project flag for filtering boards by project name

- Implemented the --project flag in the pcli status command to filter boards based on the specified project name. - Updated the command to resolve project names to IDs using case-insensitive matching. - Adjusted the totalBoards count in the output to reflect the number of boards matching the project filter. - Enhanced command help text and README documentation to include usage examples for the new flag. - Verified functionality through manual testing and ensured default behavior remains unchanged when the flag is omitted. feat(board): expand GetBoard response to include labels and card associations - Modified the Board struct to include Labels, CardLabels, and CardMemberships fields. - Updated the GetBoard method to parse additional fields from the API response. - Enhanced ListCardsByBoard to include label names for each card based on the enriched board data. - Ensured backward compatibility by making new fields optional and preserving existing output structure.
2026-02-18 21:38:41 +00:00
parent 22d5848e1a
commit 7937266262
17 changed files with 61 additions and 10 deletions
@@ -0,0 +1,37 @@
+## Context
+
+The Planka v2 API `GET /api/boards/:id` response includes an `included` object with: `users`, `boardMemberships`, `labels`, `lists`, `cards`, `cardMemberships`, `cardLabels`, `taskLists`, `tasks`, `attachments`, `customFieldGroups`, `customFields`, `customFieldValues`. Currently `GetBoard` only parses `lists` and `cards`, discarding everything else.
+
+The `CardLabel` and `Label` types already exist in `model/types.go`. The `Board` struct has `Lists` and `Cards` fields but not `Labels`, `CardLabels`, or `CardMemberships`.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Parse `labels`, `cardLabels`, and `cardMemberships` from the `GetBoard` response
+- Make label data available on the `Board` struct for downstream consumers
+- Enrich `ListCardsByBoard` output so `card list --board` includes label names per card
+
+**Non-Goals:**
+- Parsing all included fields (users, taskLists, attachments, customFields, etc.) — only what's needed now
+- Adding label data to `card list --list` (uses a different API endpoint that doesn't include labels)
+- Changing the `card get` response (already returns card-level data via a different endpoint)
+
+## Decisions
+
+### Add fields to Board struct rather than creating a separate BoardDetail type
+**Decision**: Add `Labels`, `CardLabels`, and `CardMemberships` as optional fields on the existing `Board` struct with `omitempty`.
+
+**Alternative**: Create a `BoardDetail` struct for the enriched response. Rejected — the fields are simply absent when not fetched (e.g., `ListBoards`), and `omitempty` handles this cleanly without a type split.
+
+### Add Labels field to CardWithList for card list --board output
+**Decision**: Add a `Labels` field (`[]string` of label names) to the `CardWithList` struct. `ListCardsByBoard` will resolve card→label associations via the `cardLabels` join table and `labels` list from the board response.
+
+**Alternative**: Return full `Label` objects per card. Rejected — label names are sufficient for display and filtering; full objects add noise to output.
+
+### Use join-table approach matching the API structure
+**Decision**: Keep `CardLabel` as the join entity (cardId + labelId), and resolve to label names at the point of use (in `ListCardsByBoard`). This mirrors the Planka API's relational structure.
+
+## Risks / Trade-offs
+
+- **[Additive JSON fields]** → `card list --board` output will include a new `labels` array per card. Existing consumers that don't use this field are unaffected. Scripts using strict JSON parsing may need updating.
+- **[Partial included parsing]** → We still skip users, taskLists, attachments, etc. This is intentional — parse only what's needed. Future changes can add more fields incrementally.