Show human-readable owner and workflow metadata in unified search results

[alexeygrigorev]

Show human-readable owner and workflow metadata in unified search results

Status: pending
Tags: bug, portal, frontend, work-engine, design, P1
Depends on: #57
Blocks: None

Scope

The #57 Designer acceptance pass found that unified search separates result types correctly, but task results expose raw UUIDs in operator-facing metadata instead of readable owner/workflow names. This weakens workflow-first recovery because the operator has to interpret implementation IDs.

Evidence:

• .tmp/screenshots/issue-57/desktop-portal-unified-search-results.png
• .tmp/screenshots/issue-57/mobile-pixel7-portal-unified-search-results.png

Observed example:

• The task result for Approve assistant-generated podcast prep document shows metadata like Assignee 00000000-0000-0000-0000-000000000001 and a truncated workflow UUID instead of Grace and Issue 57 podcast workflow acceptance.

Acceptance Criteria

• Task search results show human-readable assignee names when user data is available.
• Task search results show workflow titles when bundle data is available.
• Raw IDs are hidden from default result summaries and moved to debug/detail affordances only if needed.
• Desktop and Pixel 7 screenshots show readable task/workflow metadata in unified search.
• No-result, partial-source, and loading/error copy remains intact.

Suggested Verification

• Seed a task linked to a bundle and assignee.
• Search for the task through the portal unified search.
• Confirm result grouping still distinguishes tasks, workflows, docs, artifacts, and assistant jobs where available.

[alexeygrigorev]

Software Engineer handoff for #62.

Summary:

• Enriched unified search task results with user and bundle lookup metadata when /api/users and /api/bundles are available.
• Task summaries and visible row chips now show Assignee Grace and workflow titles instead of raw assignee/bundle UUIDs.
• Preserved raw IDs in route/filter fields only, so debug/detail paths and task/workflow navigation still have stable identifiers.
• Kept no-result, partial-source, loading/error states unchanged; partial-source rendering is covered by existing frontend tests and screenshot fixture.

Changed files:

• lambda-functions/src/lambda_functions/search_handler.py
• frontend/src/app.js
• tests/docs_app/test_backend_full_app_search_auth.py
• tests/docs_app/test_frontend_routes_and_links.py

Verification:

• uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app/test_backend_full_app_search_auth.py::test_search_handler_returns_typed_docs_and_work_results_with_source_states tests/docs_app/test_backend_full_app_search_auth.py::test_search_handler_hides_task_ids_when_user_or_bundle_lookup_is_unavailable — passed, 2 tests
• uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app/test_frontend_routes_and_links.py::test_unified_search_groups_source_states_and_routes_actions — passed, 1 test
• uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app — passed, 111 passed, 3 skipped
• cd lambda-functions && uv run --extra search python -m lambda_functions.build_search_index --docs-dir ../content --output ../.tmp/dataops-content-search.index — indexed 357 documents
• git diff --check — passed

Screenshots:

• .tmp/screenshots/issue-62/desktop-portal-unified-search-readable-task-metadata.png
• .tmp/screenshots/issue-62/mobile-pixel7-portal-unified-search-readable-task-metadata.png

Skipped:

• Work-engine checks were not run because no work-engine/ files were touched.
• tests/frontend block-editing smoke tests were not run; they require the Docker dev stack and cover editor behavior outside this search metadata change.

Acceptance criteria status:

• Task search results show human-readable assignee names when user data is available.
• Task search results show workflow titles when bundle data is available.
• Raw IDs are hidden from default result summaries and moved to route/filter fields only.
• Desktop and Pixel 7 screenshots captured with readable task/workflow metadata.
• No-result, partial-source, and loading/error copy remains intact.

Ready for Tester and Designer review.

[alexeygrigorev]

DESIGN PASS

Role: Designer
Viewport coverage: desktop 1440x1000; Pixel 7 mobile 412x915

Verdict

#62 passes design audit for the unified search task-result metadata fix.

Confirmed:

• Task result default summaries show readable metadata: Assignee Grace and Workflow Issue 57 podcast workflow acceptance.
• Visible result chips show owner Grace and the workflow title instead of raw assignee/bundle UUIDs.
• No raw UUIDs are visible in the inspected default task result summaries or chips on desktop or Pixel 7.
• No text overlap is visible. Desktop keeps the action separated from metadata; Pixel 7 wraps the title, summary, chips, and action into a readable single-column result.
• Partial-source state remains visible and readable in both screenshots.
• No-result copy remains intact in renderUnifiedSearchResults for empty unified search results.

Screenshots inspected:

• .tmp/screenshots/issue-62/desktop-portal-unified-search-readable-task-metadata.png
• .tmp/screenshots/issue-62/mobile-pixel7-portal-unified-search-readable-task-metadata.png

Verification run:

• uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app/test_backend_full_app_search_auth.py::test_search_handler_returns_typed_docs_and_work_results_with_source_states tests/docs_app/test_backend_full_app_search_auth.py::test_search_handler_hides_task_ids_when_user_or_bundle_lookup_is_unavailable — passed, 2 tests
• uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app/test_frontend_routes_and_links.py::test_unified_search_groups_source_states_and_routes_actions — passed, 1 test
• git diff --check — passed

Files changed by Designer: none.

Designer recommendation: after Tester passes #62, this can proceed to PM acceptance.

[alexeygrigorev]

TEST PASS

Role: Tester
Branch/worktree: worktree-issue-62 at /home/alexey/git/dataops/.tmp/worktrees/issue-62

Verdict

#62 passes the Tester gate. The changed backend/frontend behavior satisfies the groomed acceptance criteria, and the search-specific #57 design blocker is technically resolved pending Designer review.

Acceptance Criteria

• Task search results show human-readable assignee names when user data is available.
  • Verified in backend payload tests and screenshots: task summary/chips show Assignee Grace / owner Grace.
• Task search results show workflow titles when bundle data is available.
  • Verified in backend payload tests and screenshots: task summary/chips show Workflow Issue 57 podcast workflow acceptance.
• Raw IDs are hidden from default result summaries and moved to route/filter fields only.
  • Verified via tests and direct payload inspection: summary and context exclude the assignee/bundle UUIDs; route.bundleId, fields.assignee_id, and fields.bundle_id remain available.
• Desktop and Pixel 7 screenshots show readable task/workflow metadata in unified search.
  • Inspected both screenshots. No raw UUIDs, 404, blank state, error page, overlap, or unreadable layout observed.
• No-result, partial-source, and loading/error copy remains intact.
  • Covered by the full docs app suite and inspected screenshot partial-source state.

Commands Run

• uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app/test_backend_full_app_search_auth.py::test_search_handler_returns_typed_docs_and_work_results_with_source_states tests/docs_app/test_backend_full_app_search_auth.py::test_search_handler_hides_task_ids_when_user_or_bundle_lookup_is_unavailable tests/docs_app/test_frontend_routes_and_links.py::test_unified_search_groups_source_states_and_routes_actions
  • Result: PASS, 3 passed.
• uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app
  • Result: PASS, 111 passed, 3 skipped.
• uv run --project lambda-functions --extra search python -m lambda_functions.build_search_index --docs-dir content --output .tmp/dataops-content-search.index
  • Result: PASS, indexed 357 documents.
• uv run --project lambda-functions --extra search python -m py_compile lambda-functions/src/lambda_functions/search_handler.py
  • Result: PASS.
• node --check frontend/src/app.js
  • Result: PASS.
• git diff --check
  • Result: PASS.
• Direct payload verification with a synthetic work fetcher and assignee=<raw UUID> filter.
  • Result: PASS. Visible summary/context hid raw IDs; route/filter fields retained raw IDs.

Screenshot Evidence

• .tmp/screenshots/issue-62/desktop-portal-unified-search-readable-task-metadata.png
• .tmp/screenshots/issue-62/mobile-pixel7-portal-unified-search-readable-task-metadata.png

Blockers / Risks

No Tester blockers found. Work-engine checks were not rerun because no work-engine/ files changed and #62 is scoped to the portal unified search metadata blocker from #57.

Ready for Designer review, then PM acceptance if Designer confirms the visual gate.

[alexeygrigorev]

ACCEPTED

Role: Product Manager acceptance for #62

Operator-perspective verdict: ACCEPT. Unified search task results now show human-readable owner/workflow metadata in the default operator view. The inspected desktop and Pixel 7 screenshots show Assignee Grace, owner Grace, and Workflow Issue 57 podcast workflow acceptance / workflow chip text instead of raw assignee or bundle UUIDs. Raw IDs are retained only in route/filter/detail fields needed for navigation and filtering, not in default summaries or visible chips.

Acceptance criteria checked:

• Task search results show readable assignee names when user data is available.
• Task search results show readable workflow titles when bundle data is available.
• Default task summaries and visible result chips do not expose raw UUIDs.
• Desktop and Pixel 7 screenshots show readable metadata with no visible layout blocker.
• No-result, partial-source, loading/error copy remains intact; partial-source state is still visible in the screenshots.

Scope check: implementation stays within #62's portal unified-search metadata fix and does not expand into unrelated #57 work. This resolves the #57 search blocker that reported raw UUIDs in portal unified search task results. #57 may still depend on other blocker follow-ups, including #61.

PM verification run:

• uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app/test_backend_full_app_search_auth.py::test_search_handler_returns_typed_docs_and_work_results_with_source_states tests/docs_app/test_backend_full_app_search_auth.py::test_search_handler_hides_task_ids_when_user_or_bundle_lookup_is_unavailable tests/docs_app/test_frontend_routes_and_links.py::test_unified_search_groups_source_states_and_routes_actions — PASS, 3 passed
• uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app — PASS, 111 passed, 3 skipped
• uv run --project lambda-functions --extra search python -m lambda_functions.build_search_index --docs-dir content --output .tmp/dataops-content-search.index — PASS, indexed 357 documents
• node --check frontend/src/app.js — PASS
• git diff --check — PASS

Screenshots inspected:

• .tmp/screenshots/issue-62/desktop-portal-unified-search-readable-task-metadata.png
• .tmp/screenshots/issue-62/mobile-pixel7-portal-unified-search-readable-task-metadata.png

Blockers: none.

Branch may be committed with Closes #62.

[alexeygrigorev]

ON-CALL REPORT

Role: On-Call Engineer
Commit monitored: ca832adb15fb58634a5af811ccdf76df08e3abc3 (ca832ad, main, origin/main)
Run trigger: push from Merge issue #62 readable search metadata

CI/CD status

• PASS: Validate Planning Docs — https://github.com/DataTalksClub/dataops/actions/runs/28321296242
• PASS: Validate DataOps Content — https://github.com/DataTalksClub/dataops/actions/runs/28321296237
• FAIL: Deploy DataOps V1 Lambda — https://github.com/DataTalksClub/dataops/actions/runs/28321296243

Deploy workflow detail

Deploy DataOps V1 Lambda completed the repo/test pre-deploy gate successfully:

• PASS: docs app tests
• PASS: browser-backed docs portal flow
• PASS: work-engine tests
• PASS: work-engine typecheck
• PASS: work-engine build
• PASS: work-engine Playwright E2E
• PASS: search index build
• PASS: search handler smoke against built index
• PASS: full app handler smoke
• PASS: SAM validate
• PASS: SAM build artifact

The deploy job then failed in Deploy DataOps v1 stack; deployed smoke tests were skipped because the stack update rolled back.

Classification

External AWS deploy-role drift tracked by #60. No #62 repo/test-code failure found, and no on-call code fix was made.

Exact blocker from the failed deploy log:

• Assumed role: arn:aws:sts::817685572750:assumed-role/dataops-github-actions-deploy/dataops-v1-deploy
• Missing permission: s3:CreateBucket
• Resource: arn:aws:s3:::dataops-v1-dataopsexportarchivebucket-e1p2pwzirfeb
• Failing CloudFormation resource: DataOpsExportArchiveBucket (AWS::S3::Bucket)
• Stack: dataops-v1 in eu-west-1
• Result: CREATE_FAILED on DataOpsExportArchiveBucket, then UPDATE_ROLLBACK_COMPLETE

This is consistent with the known #60 deploy-role drift, now surfacing on the S3 export archive bucket permission before the workflow can reach deployed smoke tests.

Fixes made

None. The failure is external AWS IAM/configuration drift, not a safe repo-side fix.

Required next step

A credentialed AWS operator needs to update the live deploy role/stack for #60 so arn:aws:iam::817685572750:role/dataops-github-actions-deploy has the scoped S3 permissions needed to create/manage the dataops-v1-* export archive bucket, alongside the known EventBridge permissions. After that, rerun Deploy DataOps V1 Lambda on main and monitor the deployed smoke tests.