m/paliad
1
0
Fork 0
Code Issues 146 Pull Requests 8 Actions 1 Packages Projects Releases Wiki Activity

Bug: FilterBar timeline + type filters don't narrow Verlauf list (Slice 2/3 regression) #32

New Issue
Open
opened 2026-05-09 16:35:30 +00:00 by mAi · 1 comment
mAi commented 2026-05-09 16:35:30 +00:00
Collaborator
Copy Link

Source: m @ 2026-05-09 18:32: "The filters in the project views dont work - at least not those for timeline and type etc."

Symptom

On /projects/<id> Verlauf tab, the FilterBar's timeline-related axes (likely timeline_status, timeline_track from Slice 2/3 + the existing project_event_kind from t-paliad-170) do not narrow the rendered list. Selecting a chip changes the URL state but the displayed events are unchanged.

Likely cause (priority order)

  1. customRunner / wire-shape evolution. Slice 4 (7930ee0) changed the /timeline response from []TimelineEvent to {events, lanes} envelope. The customRunner in client/projects-detail.ts likely still reads the response as []TimelineEvent and fails silently to apply axis filters; the bar updates URL but the data layer ignores. Defensive fallback was claimed but may not cover the filter-narrowing path.
  2. Axis filter dispatch. The new timeline_status + timeline_track axes added in Slice 2/3 — verify their facet renderers are wired into the client-side filter predicate. Empty filter predicate → no narrowing.
  3. project_event_kind axis. This was riemann's t-paliad-170 axis. Slice 1's loadTimeline rewrite may have skipped wiring the axis filter into the new response-handling path. Compare with /inbox where the axis works.

Repro

  1. Visit /projects/<id> (any project with a few events).
  2. Click Verlauf tab.
  3. Open FilterBar, select a chip (e.g. timeline_status: predicted or project_event_kind: deadline_created).
  4. Observe: the URL gains the query param, but the visible list stays unchanged.

Fix shape

Minimal: trace the filter-application code path in the customRunner; ensure the new envelope ({events, lanes}) reaches the existing axis-filter logic. If the bar's facet-to-predicate dispatcher dropped the new axes, wire them up. If the customRunner does its own server-side fetch, also verify the URL params are forwarded to /timeline?<axis>=<value>.

No SmartTimeline redesign needed. Single-commit fix on mai/<worker>/verlauf-filterbar-fix.

Acceptance

  • All FilterBar axes on the Verlauf tab actually narrow the rendered timeline.
  • URL params round-trip cleanly (page reload preserves filter state).
  • bun build clean.

Filed by maria/paliad-head autonomously per m's directive.

**Source:** m @ 2026-05-09 18:32: "The filters in the project views dont work - at least not those for timeline and type etc." ## Symptom On `/projects/<id>` Verlauf tab, the FilterBar's timeline-related axes (likely `timeline_status`, `timeline_track` from Slice 2/3 + the existing `project_event_kind` from t-paliad-170) do not narrow the rendered list. Selecting a chip changes the URL state but the displayed events are unchanged. ## Likely cause (priority order) 1. **customRunner / wire-shape evolution.** Slice 4 (`7930ee0`) changed the `/timeline` response from `[]TimelineEvent` to `{events, lanes}` envelope. The customRunner in `client/projects-detail.ts` likely still reads the response as `[]TimelineEvent` and fails silently to apply axis filters; the bar updates URL but the data layer ignores. Defensive fallback was claimed but may not cover the filter-narrowing path. 2. **Axis filter dispatch.** The new `timeline_status` + `timeline_track` axes added in Slice 2/3 — verify their facet renderers are wired into the client-side filter predicate. Empty filter predicate → no narrowing. 3. **`project_event_kind` axis.** This was riemann's t-paliad-170 axis. Slice 1's `loadTimeline` rewrite may have skipped wiring the axis filter into the new response-handling path. Compare with /inbox where the axis works. ## Repro 1. Visit `/projects/<id>` (any project with a few events). 2. Click Verlauf tab. 3. Open FilterBar, select a chip (e.g. `timeline_status: predicted` or `project_event_kind: deadline_created`). 4. Observe: the URL gains the query param, but the visible list stays unchanged. ## Fix shape Minimal: trace the filter-application code path in the customRunner; ensure the new envelope (`{events, lanes}`) reaches the existing axis-filter logic. If the bar's facet-to-predicate dispatcher dropped the new axes, wire them up. If the customRunner does its own server-side fetch, also verify the URL params are forwarded to `/timeline?<axis>=<value>`. No SmartTimeline redesign needed. Single-commit fix on `mai/<worker>/verlauf-filterbar-fix`. ## Acceptance - All FilterBar axes on the Verlauf tab actually narrow the rendered timeline. - URL params round-trip cleanly (page reload preserves filter state). - bun build clean. Filed by maria/paliad-head autonomously per m's directive.
mAi commented 2026-05-09 16:52:22 +00:00
Author
Collaborator
Copy Link

Fix on mai/maxwell/bug-bundle-filterbar @ c2f1c29 (bundled with #33).

Root cause. The Verlauf FilterBar mounted only time + project_event_kind axes — timeline_status / timeline_track chips were never rendered. Worse, the customRunner was draining predicates into loadEvents() (the legacy /api/projects/{id}/events endpoint) which writes a now-dead events array; the SmartTimeline render reads timelineRows, so even when chips did fire, the filter pass landed on a branch that never reached the DOM.

Fix.

  • Mount all three axes (timeline_status, timeline_track, project_event_kind) on the bar.
  • Rewrite the customRunner to drain bar state into verlaufFilters; renderTimeline applies them client-side via applyTimelineRowFilters immediately before calling renderSmartTimeline.
  • project_event_kind rides through effective.filter.predicates.project_event.event_types (substrate-shaped); timeline_status / timeline_track sit on raw BarState — the customRunner now receives a state argument as a 2nd param so the very first run (before the handle is assigned) sees the URL-hydrated BarState too.
  • Backend: added ProjectEventType to TimelineEvent so project_event_kind can match against the underlying paliad.project_events.event_type for milestone rows.
  • Track-chip semantics: chip counterclaim matches both bare counterclaim and counterclaim:<id>; parent_context:<id> is intentionally not matched by the parent chip (it's the CCR-child-viewing-parent overlay).

Verified.

  • go build ./..., go vet ./..., unit tests pass.
  • bun run build clean (2171 keys).
  • URL params round-trip on reload (existing url-codec already handled tl_status + tl_track).

Commit: c2f1c29b10

Fix on `mai/maxwell/bug-bundle-filterbar` @ c2f1c29 (bundled with #33). **Root cause.** The Verlauf FilterBar mounted only `time` + `project_event_kind` axes — `timeline_status` / `timeline_track` chips were never rendered. Worse, the `customRunner` was draining predicates into `loadEvents()` (the legacy `/api/projects/{id}/events` endpoint) which writes a now-dead `events` array; the SmartTimeline render reads `timelineRows`, so even when chips did fire, the filter pass landed on a branch that never reached the DOM. **Fix.** - Mount all three axes (`timeline_status`, `timeline_track`, `project_event_kind`) on the bar. - Rewrite the customRunner to drain bar state into `verlaufFilters`; `renderTimeline` applies them client-side via `applyTimelineRowFilters` immediately before calling `renderSmartTimeline`. - `project_event_kind` rides through `effective.filter.predicates.project_event.event_types` (substrate-shaped); `timeline_status` / `timeline_track` sit on raw BarState — the customRunner now receives a `state` argument as a 2nd param so the very first run (before the handle is assigned) sees the URL-hydrated BarState too. - Backend: added `ProjectEventType` to `TimelineEvent` so `project_event_kind` can match against the underlying `paliad.project_events.event_type` for milestone rows. - Track-chip semantics: chip `counterclaim` matches both bare `counterclaim` and `counterclaim:<id>`; `parent_context:<id>` is intentionally not matched by the `parent` chip (it's the CCR-child-viewing-parent overlay). **Verified.** - `go build ./...`, `go vet ./...`, unit tests pass. - `bun run build` clean (2171 keys). - URL params round-trip on reload (existing url-codec already handled `tl_status` + `tl_track`). Commit: https://mgit.msbls.de/m/paliad/commit/c2f1c29b103d5afddde7b42896f0596012b37a9d
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#32
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?