HydraIssues

Problem

hydraissue stores a venue per issue but cannot filter by it.

The write path exists:

• SessionContext.Venue (internal/store/issue.go:116), set through session on POST /api/v1/issues and through the venue form field on POST /report (internal/api/handlers_web.go:160).
• IssueSummary.Venue (internal/store/issue.go:158), populated from issue.Session.Venue into the index (internal/store/store.go:590-601).

The read path does not:

• Store.List(status, category, project, activeOnly) has no venue argument.
• apiListIssues (internal/api/handlers_issues.go:87) exposes only status, category, project, active_only and stage.
• The admin web list has no venue column and no venue facet.

So the data is there and unreachable.

Request

1. Add a venue argument to Store.List and a ?venue= query parameter to GET /api/v1/issues.
2. Add a venue column and a venue filter to the admin issue list.
3. Show the venue on the issue detail page.

Also needed: backfill and set on update

updateIssueRequest (internal/api/handlers_issues.go:24) has no session field, so an existing issue's venue cannot be set through the API. Every issue that predates this has no venue and will never appear in a venue feed. Add session to the update request, or add a dedicated PATCH /api/v1/issues/{id}/venue.

Then backfill. As of today only 51 issues carry a venue, spread over inconsistent values: Rupelmonde and rupelmonde, Gallo-Romeins against the hydravenues id gallo-romeins-museum, and cloud-seven / nerdland as a single string. Normalize to the hydravenues venue id, and consider validating the value against the hydravenues venue list at write time.

cloud-seven / nerdland also shows that one issue can belong to two venues. Decide whether venue stays a single string or becomes a list before backfilling.

Why

Blocks the venue-scoped issue feed in hydravenues, which is the thing that lets a venue contact see their own issues instead of mailing us a document. See the Cloud Seven master tracker.