Files
PaperClipAI/ui/src/lib/task-views.ts
T
DottaandPaperclip b31ec0a2dc feat(ui): link routines to a filtered task list (#18317)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Routines create tasks that people need to inspect and manage.
> - The routines list sends its View all runs link to Audit.
> - Tasks already supports routine origin filters in its API, but the
page has no control for them.
> - This pull request adds a Routine tasks checkbox and links to that
selection.
> - People can inspect routine work in the normal task list, search, and
board views.

## Linked Issues or Issue Description

**What existing behavior does this improve?**

The routines list link and the Tasks filters.

**Current behavior**

View all runs opens Audit. People cannot select routine-created tasks in
the Tasks filter menu.

**Proposed behavior**

View all tasks opens `/issues?view=all&originKind=routine_execution`.
Routine tasks is selected. People can toggle or clear it from Tasks.

**Reason and benefit**

People can use normal task controls to inspect work created by routines.
The filter includes manually started routine runs. It excludes manual
tasks and other automatic work.

**Breaking changes**

The routines list link changes its label and destination. No API,
schema, authorization, or routine execution contract changes.

## What Changed

- Add Routine tasks under Visibility in the current, streamlined, and
legacy Tasks filters. Keep Live runs only in the same group and use Show
agent-created tasks with proper capitalization where that control is
available.
- Keep the selection in the URL through reload, search, task navigation,
and checkbox changes.
- Apply the existing API origin filter before pagination. Include
routine tasks even when other automatic tasks are hidden.
- Keep source filtering in the shared task filter module and collection
owners. Reuse the existing company-scoped issue-list contract. Hide the
live-run control in the design sandbox, which does not load live-run
IDs.
- Update regression coverage, product docs, feature/access maps, and the
toolbar preview.

## Verification

- All 58 final-head checks are complete with no failures for
`f46c2e409b20fa372d166f4721601a0471894fb0`, including successful `ci /
verify` and `ci / e2e` gates. Greptile and Paperclip Review rate this
commit 5/5 with no actionable findings or unresolved review threads. [CI
run](https://github.com/paperclipai/paperclip/actions/runs/41078093110).
- Local checks pass: full repo typecheck/build for the feature, UI
typecheck/build after the final refinements, token gates, feature-map
checks, and Storybook catalog generation.
- Regression coverage exercises both real list implementations, filter
grouping and selection, search and all board columns, URL/pagination
state, and mixed pending-decision batches. The Visibility update passed
all 89 relevant tests across separate runs. The final sandbox correction
passes all 10 filter-menu tests, including three cases that reproduced
the bug before the fix. The earlier broad UI run passed 10,043 tests
across 845 files.
- Browser proof used the actual local app with disposable PostgreSQL
data: three tasks created through the routine-run API and one manual
task. Followed View all tasks; verified the selected Routine tasks
checkbox under Visibility, toggling, reload, search, and board view.
Checked current, streamlined, and legacy filter presentations.
Screenshots show the link, routine-only results, and requested
capitalization/grouping.
- Failure accounting: the initial broad UI run found two preference
expectations that needed the new false default; those were corrected
before the full UI pass. Scrolling tests hit five-second timeouts in
combined runs and passed in isolated reruns without timeout changes. A
duplicate full local UI run was stopped after the earlier final-commit
CI UI lanes passed, with no failures reported in that stopped run.
- Full local `pnpm test:run` could not complete because native
PostgreSQL initialization exhausted the host semaphore pool. A direct
initdb probe confirmed `could not create semaphores: No space left on
device`. Browser verification used a disposable container; no host
settings or other workspace processes were changed.
- Review found that the newly exposed live-run control could empty the
design sandbox, which has no live-run IDs. The sandbox now disables that
unsupported control; its regression test failed before the fix and
passes after it.

## Risks

- Low risk. The change uses the existing routine origin and read
permissions. A routine task remains automatic work, including when a
person starts it manually.
- The routine checkbox is exposed only on the Tasks collection. Other
filter consumers retain their controls and normalize the new field to
false.
- Routine histories and Audit run links inside routine details keep
their current behavior.

## Model Used

- OpenAI GPT-6, through Codex, assisted with implementation and
verification. The exact runtime model ID and context window are not
exposed in this session. Capabilities used: repository editing, command
execution, tests, and browser interaction.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-30 10:28:58 -05:00

154 lines
5.4 KiB
TypeScript

import type { InboxTab } from "./inbox";
/**
* The single view registry behind the merged Tasks surface (PAP-670).
*
* Inbox stopped being its own nav row and its five tabs became views inside
* Tasks, alongside the status presets that used to live only inside the task
* list's filter popover. Every view is addressed as `/issues?view=<key>`.
*
* Each view declares which surface renders it:
* - `inbox` — the attention-ordered inbox list (unread state, archive,
* date groups, mixed approval/failed-run/join-request rows).
* - `issues` — the task collection list (board/list modes, filters, columns).
*
* Views are *not* reimplemented on the other surface: pointing a view at the
* component that already owns those behaviours is what keeps them intact.
*/
export const TASK_VIEW_KEYS = [
"mine",
"unread",
"blocked",
"recent",
"everything",
"all",
"active",
"backlog",
"done",
] as const;
export type TaskViewKey = (typeof TASK_VIEW_KEYS)[number];
export type TaskViewSurface = "inbox" | "issues";
export interface TaskView {
key: TaskViewKey;
label: string;
surface: TaskViewSurface;
/** Which inbox tab renders this view (`inbox` surface only). */
inboxTab?: InboxTab;
/** Status filter applied on entry (`issues` surface only). */
statuses?: string[];
/** One-line description shown in the Views menu. */
hint: string;
}
export interface TaskViewGroup {
label: string;
views: TaskView[];
}
export const TASK_VIEW_GROUPS: TaskViewGroup[] = [
{
label: "My work",
views: [
{ key: "mine", label: "Mine", surface: "inbox", inboxTab: "mine", hint: "Assigned to you or waiting on you" },
{ key: "unread", label: "Unread", surface: "inbox", inboxTab: "unread", hint: "Tasks you touched with new activity" },
{ key: "blocked", label: "Blocked", surface: "inbox", inboxTab: "blocked", hint: "Blocked tasks, grouped by blocker" },
{ key: "recent", label: "Recent", surface: "inbox", inboxTab: "recent", hint: "Everything you touched lately" },
{ key: "everything", label: "Everything", surface: "inbox", inboxTab: "all", hint: "Tasks, approvals, failed runs and join requests" },
],
},
{
label: "Organization",
views: [
{ key: "all", label: "All tasks", surface: "issues", statuses: [], hint: "Every task in the organization" },
{ key: "active", label: "Active", surface: "issues", statuses: ["todo", "in_progress", "in_review", "blocked"], hint: "Open tasks, running or not" },
{ key: "backlog", label: "Backlog", surface: "issues", statuses: ["backlog"], hint: "Not started yet" },
{ key: "done", label: "Done", surface: "issues", statuses: ["done", "cancelled"], hint: "Completed and cancelled" },
],
},
];
const VIEWS_BY_KEY = new Map<TaskViewKey, TaskView>(
TASK_VIEW_GROUPS.flatMap((group) => group.views.map((view) => [view.key, view] as const)),
);
export const DEFAULT_TASK_VIEW: TaskViewKey = "mine";
export const TASK_VIEW_PARAM = "view";
export const TASK_LAST_VIEW_KEY = "paperclip:tasks:last-view";
export function isTaskViewKey(value: unknown): value is TaskViewKey {
return typeof value === "string" && VIEWS_BY_KEY.has(value as TaskViewKey);
}
export function taskView(key: TaskViewKey): TaskView {
return VIEWS_BY_KEY.get(key)!;
}
/** Resolves a `?view=` value, falling back to `null` so callers can pick a default. */
export function normalizeTaskViewKey(value: string | null | undefined): TaskViewKey | null {
return isTaskViewKey(value) ? value : null;
}
export function taskViewPath(key: TaskViewKey): string {
return `/issues?${TASK_VIEW_PARAM}=${key}`;
}
/** Inbox tab → view key, for redirecting the retired `/inbox/*` URLs. */
const VIEW_BY_INBOX_TAB: Record<InboxTab, TaskViewKey> = {
mine: "mine",
unread: "unread",
blocked: "blocked",
recent: "recent",
all: "everything",
};
export function taskViewForInboxTab(tab: string | null | undefined): TaskViewKey {
return (tab && tab in VIEW_BY_INBOX_TAB)
? VIEW_BY_INBOX_TAB[tab as InboxTab]
: DEFAULT_TASK_VIEW;
}
export function loadLastTaskView(): TaskViewKey {
try {
return normalizeTaskViewKey(window.localStorage.getItem(TASK_LAST_VIEW_KEY)) ?? DEFAULT_TASK_VIEW;
} catch {
return DEFAULT_TASK_VIEW;
}
}
export function saveLastTaskView(key: TaskViewKey): void {
try {
window.localStorage.setItem(TASK_LAST_VIEW_KEY, key);
} catch {
/* Navigation still works without storage; the default view just returns. */
}
}
/**
* Query params that only the organization task list understands. A deep link
* carrying one of these (the dashboard's "assigned to me", a workspace
* drill-in, a search hand-off) must not land on a My-work view, so it resolves
* to `All tasks` instead of the user's last-used view.
*/
export const ORGANIZATION_SCOPED_PARAMS = [
"assignee",
"workspace",
"participantAgentId",
"originKind",
"q",
] as const;
/** Resolves which view a `/issues` visit opens. */
export function resolveInitialTaskView(
requested: string | null,
hasOrganizationScopedParam: boolean,
lastUsed: TaskViewKey,
): TaskViewKey {
const explicit = normalizeTaskViewKey(requested);
// Inbox views can't apply organization filters, so a link carrying one
// opens All tasks rather than silently dropping the filter.
if (hasOrganizationScopedParam && (!explicit || taskView(explicit).surface === "inbox")) return "all";
return explicit ?? lastUsed;
}