Allow customizable fields and columns in worklists

Objective

• Let teams shape worklist rows so the right context shows without opening every work order or quote—for example quote cleanup (reason not booked, alternate follow-up date) and event triage (assigned inspector on the row).
• Support saved view configuration per worklist (which fields/columns are visible), in the spirit of column choices elsewhere in the product.
• Explore making status-style columns with icons optional where they add noise for a given workflow.
• A possible later increment (from the same feedback) is lightweight inline editing for surfaced fields (for example reassigning an event inspector from the list).

Background

• Default and custom worklists today render each match as a compact row (inspection, quote, or event) with a fixed layout: key identifiers, StatusBadges on inspection rows (SingleJobsBar + StatusBadges), and limited inline metadata—not user-chosen columns.
• Product feedback compares the desired experience to Reports Hub–style column picking (choose a small set of fields to see in the list and persist that layout).
• A lighter-weight alternative raised in discussion is surfacing the existing required info block for the entity in the row (or expanded area) instead of fully arbitrary per-field columns, if that trades implementation cost for usefulness.
• Event-based lists today show the inspector name in the subtitle of SingleEventBar when populated, but there is still demand to treat “who is assigned” as a first-class, scannable column for busy queues.
• Screenshot from the original thread (current worklist / nav context):

• Slack context (verbatim request thread): Message from ryan

Scope

Frontend

• Worklists live under attik-frontend/src/app/tools/work/[[...type]]/page.tsx, which loads company worklists from GET worklist, renders WorklistMenu (attik-frontend/src/app/tools/work/WorklistMenu.tsx), built-in task lists (quotes, agreements, unconfirmed, published, paid, invoices), and routes matching /work/:worklistId into WorklistResolver (attik-frontend/src/components/task-check/WorklistResolver.tsx).
• WorklistResolver calls worklist/:id/data and branches by worklistType (inspections | quotes | events), rendering SingleJobsBar, SingleQuoteBar, SingleEventBar, or grouped variants—so any column or field surfacing will likely extend these row surfaces (and possibly DropdownBar expand content) rather than only the page shell.
• Inspection rows today combine datetime, address, StatusBadges (attik-frontend/src/components/task-check/SingleJobsBar.tsx referencing attik-frontend/src/components/ui/StatusBadges.tsx), and a work order link.
• Event rows (attik-frontend/src/components/task-check/SingleEventBar.tsx) already concatenate event time, address, and inspector name in a single subtitle line when event.inspector is present.
• Quote rows are the heaviest client surface (attik-frontend/src/components/task-check/SingleQuoteBar.tsx) and are the natural place for quote-specific columns such as reason-not-booked or follow-up dates if those fields exist on the populated quote payload from the worklist data API.
• For “similar to Reports Hub” column configuration UX only as a pattern reference (not in scope to copy wholesale unless product wants alignment): attik-frontend/src/app/tools/data-exports/components/ReportColumnsSection.tsx models multi-column pick, order, and labels for tabular reporting.

Backend

• Worklist definitions and query execution are centered on attik-backend/src/routes/worklist.ts (including GET /worklist, GET /worklist/:id, GET /worklist/:id/data, create/update routes noted in file comments around the handler exports).
• The worklist Mongoose model in attik-backend/src/models/worklistSchema.ts today stores type, display / groupedBy, conditions, limit, sort, and flags like isActive—there is no persisted “visible columns” or per-view field layout yet; extending the schema (or a sibling document) would be part of owning saved views if product confirms that approach.
• attik-backend/src/models/conditionsSchema.ts and worklist query helpers (for example inspection-time matching via attik-backend/src/util/functions/worklist/inspectionTimeMatch.js) underpin which rows appear; column work is mostly additive to what each returned row carries and how the client lays it out, unless new fields require projection or population changes in the /data pipeline.

Product / architecture decisions (for the implementer)

• Decision needed: Arbitrary field/column picker vs. a bounded set (for example “required info only” or a curated catalog per entity type).
• Decision needed: Whether saved views are per user, per company default, or per worklist definition shared by all viewers of that worklist.
• Decision needed: Scope of inline editing in a first release (read-only columns only vs. specific editable fields such as event assignment).

References

• Message from ryan (Slack)
• Worklist UI entry: attik-frontend/src/app/tools/work/[[...type]]/page.tsx
• Custom worklist rendering: attik-frontend/src/components/task-check/WorklistResolver.tsx
• Worklist API and data: attik-backend/src/routes/worklist.ts
• Worklist persistence shape: attik-backend/src/models/worklistSchema.ts