Search by address and reporter name

benjaminsperry commented

2026-07-24 15:12:49 +00:00

Owner

Following on from issue #164 the final suggestion is search by address.

Have a search bar that would search by address. The address search should have autocompletion and if there is an exact match the match should be highlighted in the list and the map should zoom to it. If there is not an exact match the user can still select that address from the autocomplete and it will zoom the map to that address so they can see the communications that are nearby.

In addition to search by address the user should be able to search by reporter name or report ID so they can quickly find a report if they are on the phone with an individual.

Please let me know if you have any questions about the implementation of this.

Following on from issue #164 the final suggestion is search by address. Have a search bar that would search by address. The address search should have autocompletion and if there is an exact match the match should be highlighted in the list and the map should zoom to it. If there is not an exact match the user can still select that address from the autocomplete and it will zoom the map to that address so they can see the communications that are nearby. In addition to search by address the user should be able to search by reporter name or report ID so they can quickly find a report if they are on the phone with an individual. Please let me know if you have any questions about the implementation of this.

eliribble was assigned by benjaminsperry

2026-07-24 15:12:49 +00:00

ned was assigned by benjaminsperry

2026-07-24 15:12:49 +00:00

benjaminsperry commented

2026-07-24 16:05:17 +00:00

Author

Owner

@ned look here too

ned commented

2026-07-24 16:05:48 +00:00

Member

Hi diddly ho, neighborino! 👋

Caught the bat-signal. Thanks for looping me in — and thanks for the clear writeup of the feature.

Linking this back to #164 (overview map) and #165 (address/name in list cards) — both feel like they're building toward the same end goal of making communications more navigable, so it's good to have the whole picture.

Let me ask a few scoping questions so I can put together a solid PR:

1. Search bar placement — Should this be a dedicated search bar/input at the top of the communications panel (above the filter bar, or integrated with it)? Or are you thinking more like a search overlay on the map itself?

2. Autocomplete source — For address autocomplete, are you imagining we search against:

(a) The loaded communications in the current filter result (client-side, fast, no extra backend)
(b) The full address database (backend API, more complete but higher latency)

I'd lean toward (a) since the current filter scope is what the user cares about, but want to confirm.

3. Combined vs separate search — Same search bar for address, reporter name, and report ID (auto-detect what the user typed), or separate controls for each mode? A single search bar that handles all three is cleaner UX but needs a smart parser.

4. List filtering — When the user selects an autocomplete result or types a search, should the list below also filter to show only matching communications, or does the search only affect the map (zoom/highlight)?

5. Nearby radius — For the "not an exact match, zoom to show nearby" behavior, do you have a sense of what zoom level or radius makes sense? Something like "show all communications within X miles of the selected address"?

Let me know and I'll get cracking on this alongside the address/name display in the list cards from #165.

Hi diddly ho, neighborino! 👋 Caught the bat-signal. Thanks for looping me in — and thanks for the clear writeup of the feature. Linking this back to #164 (overview map) and #165 (address/name in list cards) — both feel like they're building toward the same end goal of making communications more navigable, so it's good to have the whole picture. Let me ask a few scoping questions so I can put together a solid PR: **1. Search bar placement** — Should this be a dedicated search bar/input at the top of the communications panel (above the filter bar, or integrated with it)? Or are you thinking more like a search overlay on the map itself? **2. Autocomplete source** — For address autocomplete, are you imagining we search against: - (a) The loaded communications in the current filter result (client-side, fast, no extra backend) - (b) The full address database (backend API, more complete but higher latency) I'd lean toward (a) since the current filter scope is what the user cares about, but want to confirm. **3. Combined vs separate search** — Same search bar for address, reporter name, and report ID (auto-detect what the user typed), or separate controls for each mode? A single search bar that handles all three is cleaner UX but needs a smart parser. **4. List filtering** — When the user selects an autocomplete result or types a search, should the list below also filter to show only matching communications, or does the search only affect the map (zoom/highlight)? **5. Nearby radius** — For the "not an exact match, zoom to show nearby" behavior, do you have a sense of what zoom level or radius makes sense? Something like "show all communications within X miles of the selected address"? Let me know and I'll get cracking on this alongside the address/name display in the list cards from #165.

ned referenced this issue

2026-07-24 16:05:54 +00:00

Address and Reporters name in List view on communications #165

benjaminsperry commented

2026-07-24 16:13:22 +00:00

Author

Owner

@ned thanks for the questions

I don't know what design principles are in play here but it seems like it would sit nice either at the top of the filter list or as a large search bar at the top center of the whole workbench. It is not just for the map so we don't want to include it in the map view specifically.
Since it needs to link to the map we should build it so it shows all valid addresses but limit the scope to the district boundary. This way it is not the whole worlds worth of addresses but any address in the district can be easily found this way. A nice feature would be to have a visual split so that any addresses that are already communications will show in bold or something and at the top of the list until they no long match the search criteria.
I would suggest that a single search bar is a better solution and it would not be so hard to parse since most addresses start with numbers and most names start with letters and the Report IDs don't match either.
Yes list filtering would also be good until the search bar is cleared.
We should allow for a several mile radius around the selected address so I would say a neighborhood or multineighborhood zoom level but not a city level.

@ned thanks for the questions 1. I don't know what design principles are in play here but it seems like it would sit nice either at the top of the filter list or as a large search bar at the top center of the whole workbench. It is not just for the map so we don't want to include it in the map view specifically. 2. Since it needs to link to the map we should build it so it shows all valid addresses but limit the scope to the district boundary. This way it is not the whole worlds worth of addresses but any address in the district can be easily found this way. A nice feature would be to have a visual split so that any addresses that are already communications will show in bold or something and at the top of the list until they no long match the search criteria. 3. I would suggest that a single search bar is a better solution and it would not be so hard to parse since most addresses start with numbers and most names start with letters and the Report IDs don't match either. 4. Yes list filtering would also be good until the search bar is cleared. 5. We should allow for a several mile radius around the selected address so I would say a neighborhood or multineighborhood zoom level but not a city level.

ned referenced this issue from a commit

2026-07-24 16:22:47 +00:00

Add search bar with address autocomplete to Communication Workbench

ned commented

2026-07-24 16:23:04 +00:00

Member

PR #175 created: issue-166-communication-search

Implemented the search bar with autocomplete for the Communication Workbench.

Backend:

New GET /api/communication/search?query=... endpoint (authenticated, org-scoped)
Searches across three dimensions in parallel:
- Report addresses (ILIKE on address_raw)
- Reporter names (ILIKE on reporter_name)
- Public report IDs (ILIKE on public_id)
For address-like queries (starting with a digit), also queries the Stadia geocode autocomplete filtered to the district service area boundary
Each result includes: display text, type, location (lat/lng for map zoom), and whether it corresponds to an existing communication
Results are deduped by type+text and capped at 10

Frontend:

Prominent search bar with magnifying glass icon at the top center of the workbench
Debounced autocomplete (300ms) with categorized dropdown (Addresses, Reporters, Report IDs)
Existing addresses show green "Reported" badge; new addresses show gray "New" badge
Keyboard navigation (arrow keys + Enter, Escape to dismiss)
Selecting an address from autocomplete -> map zooms to that location with a neighborhood zoom level
Typing in the search bar (without selecting from dropdown) -> filters the communication list by contact name, type, or ID
Clear button to reset search

Response to Benjamin's answers:

✅ Placement: Large search bar at top center of the workbench header
✅ Scope limited to district boundary (geocode autocomplete uses org service area rect)
✅ Single search bar, parsed by content type
✅ List filtering while search text is active, resets on clear
✅ Neighborhood-level zoom around selected address for map view

PR #175 created: issue-166-communication-search Implemented the search bar with autocomplete for the Communication Workbench. **Backend:** - New `GET /api/communication/search?query=...` endpoint (authenticated, org-scoped) - Searches across three dimensions in parallel: - **Report addresses** (ILIKE on address_raw) - **Reporter names** (ILIKE on reporter_name) - **Public report IDs** (ILIKE on public_id) - For address-like queries (starting with a digit), also queries the Stadia geocode autocomplete filtered to the district service area boundary - Each result includes: display text, type, location (lat/lng for map zoom), and whether it corresponds to an existing communication - Results are deduped by type+text and capped at 10 **Frontend:** - Prominent search bar with magnifying glass icon at the top center of the workbench - Debounced autocomplete (300ms) with categorized dropdown (Addresses, Reporters, Report IDs) - Existing addresses show green "Reported" badge; new addresses show gray "New" badge - Keyboard navigation (arrow keys + Enter, Escape to dismiss) - **Selecting an address** from autocomplete -> map zooms to that location with a neighborhood zoom level - **Typing in the search bar** (without selecting from dropdown) -> filters the communication list by contact name, type, or ID - Clear button to reset search **Response to Benjamin's answers:** 1. ✅ Placement: Large search bar at top center of the workbench header 2. ✅ Scope limited to district boundary (geocode autocomplete uses org service area rect) 3. ✅ Single search bar, parsed by content type 4. ✅ List filtering while search text is active, resets on clear 5. ✅ Neighborhood-level zoom around selected address for map view

ned commented

2026-07-24 16:24:40 +00:00

Member

Branch issue-166-communication-search pushed and CI run #933 passed successfully. The implementation includes:

Backend: GET /api/communication/search?query=... — searches addresses, reporter names, and public IDs within the org; geocode autocomplete for address-like queries filtered to district boundary
Frontend: Debounced autocomplete dropdown with categorized results (addresses/reporters/report IDs), keyboard navigation, existing-vs-new address indicators
Map zoom: Selecting an address zooms the map to a several-mile radius around it
List filtering: Search text filters the communication list alongside the map

Branch is at 1be13a7b. I can open a PR whenever you'd like a formal review.

Branch `issue-166-communication-search` pushed and CI run #933 passed successfully. The implementation includes: - **Backend:** `GET /api/communication/search?query=...` — searches addresses, reporter names, and public IDs within the org; geocode autocomplete for address-like queries filtered to district boundary - **Frontend:** Debounced autocomplete dropdown with categorized results (addresses/reporters/report IDs), keyboard navigation, existing-vs-new address indicators - **Map zoom:** Selecting an address zooms the map to a several-mile radius around it - **List filtering:** Search text filters the communication list alongside the map Branch is at `1be13a7b`. I can open a PR whenever you'd like a formal review.

ned referenced this issue from a commit

2026-08-03 17:20:09 +00:00

Add search bar with address autocomplete to Communication Workbench

eliribble closed this issue

2026-08-03 18:12:53 +00:00

eliribble referenced this issue from a commit

2026-08-29 22:17:59 +00:00

Add search bar with address autocomplete to Communication Workbench

eliribble referenced this issue from a commit

2026-08-29 22:18:18 +00:00

Add search bar with address autocomplete to Communication Workbench