Skip to content

BDMS 414: updates to the contact response for searches#280

Merged
jirhiker merged 3 commits into
stagingfrom
jab-contact-search-update
Dec 9, 2025
Merged

BDMS 414: updates to the contact response for searches#280
jirhiker merged 3 commits into
stagingfrom
jab-contact-search-update

Conversation

@jacob-a-brown

@jacob-a-brown jacob-a-brown commented Dec 9, 2025

Copy link
Copy Markdown
Contributor

Why

This PR addresses the following problem / context:

  • The frontend 's needs the contact's id to allow the user to click on the contact and navigate immediately to the contact's detail page
  • The frontend intends to display the associated things for a contact when it is searched

How

Implementation summary - the following was changed / added / removed:

  • Added the contact's id to its properties field
  • Added the associated things to its properties field. Because the thing_type is unknown until they have been retrieved the only fields returned in the array of things are:
    • the name (in the label field to correspond with how the names are returned elsewhere)
    • the id
    • the thing_type

Notes

Any special considerations, workarounds, or follow-up work to note?

  • When the thing model was refactored a while ago to allow multiple well purposes we forgot to update the /search endpoint. To fix this I removed well_purpose from the search's well_response and now return a field called well_purposes that evaluates to a list of purposes (i.e. a list of one or more strings)
    • e.g. "well_purposes": ["Domestic", "Irrigation", "Observation"] or "well_purposes": ["Open, unequipped well"]
  • eager loading is used to get a contact's emails, phones, addresses, and things since it's unknown how many will be returned, and since they are used in every response from the search query

Adding the id field will enable the frontend to allow users to click
on a searched contact and go to the contact detail page
This information is now housed in the WellPurpose model, which has a
1:M relationship with Thing. When this refactor occurred we never
updated the search endpoint to reflect this change.
Adding the contact's id enables the frontend to quickly navigate to
its detail view. Including associated things provides context about the
contact's relationships, enhancing the search experience. Since the ID
is also included the frontend can use it to go to the thing's detail
page.
@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

Files with missing lines Coverage Δ
api/search.py 97.82% <100.00%> (ø)
db/thing.py 97.94% <ø> (-0.03%) ⬇️
tests/test_search.py 93.75% <100.00%> (+0.41%) ⬆️

... and 4 files with indirect coverage changes

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@TylerAdamMartinez TylerAdamMartinez left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's perfect 😍

@jirhiker jirhiker merged commit 6fdeaab into staging Dec 9, 2025
6 checks passed
@TylerAdamMartinez TylerAdamMartinez deleted the jab-contact-search-update branch February 26, 2026 18:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants