Add a report from communications workbench #167
ned
eliribble
Loading…
Add table
Add a link
Reference in a new issue
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?
Hello,
We are getting a disconnect currently because reports taken by phone are bypassing Nidus and being put directly into FieldSeeker. This is creating re-work for the admins and also a increasing the chance of losing reports in the shuffle.
There are two things that we can implement to eliminate this problem that I will articulate over two issues.
First:
We need admins to be able to enter a report via the communications workbench if they receive a phone call. This would likely work best as a single page form with all the fields from RMO. Once completed it would be in the communications but its source would be indicated as phone it.
Hi diddly @ned here is another one for you
Hi diddly ho, neighborino! 👋
Got this one on my radar. Let me think out loud for a sec so we align on scope before I start hacking.
What I understand so far:
source = phoneA few questions to nail down scope:
Which RMO report type? RMO has three: Nuisance (mosquito complaint — location, timing, source), Compliance (service request — access, permission, comments), and Water (standing water — breeding site conditions). Should the phone report form support all three, or is there one type that covers most phone calls?
Required vs optional fields? When a resident calls in, some RMO fields (like map pin location, photos) aren't available over the phone. Which fields do you consider essential vs nice-to-have for a phone intake?
Where does this button go? Should it be in the three-column layout (maybe a "+" button in the list header, or floating), or would this be better as its own page/route that the admin navigates to?
Is there a "second thing" coming in another issue? You mentioned this is the first of two issues for the phone-report problem. Knowing what the second one is might affect how we design this one.
Current reading from the codebase:
nuisance,compliance,watertypes) — they have common fields (address, reporter info, location, images) plus type-specific fieldsphoneHappy to start on this once we nail down the answers. Okaly-dokely! 🎯
Hello @ned great questions:
Thanks Benjamin, these answers clarify things nicely! Here is my understanding of the path forward:
Implementation Plan:
UI: A button labeled "Add Phone Report" at the top of the central column (where the map/details live now). Clicking it swaps the central area into an editable form with the map still visible above/beside it.
Form fields: Expose all relevant RMO fields as optional except Address (required). No photo/camera field since this is phone intake. Fields include: address lookup/autocomplete, reporter name, phone, email, report type, description, etc.
Backend: New endpoint to create a communication+report combo from the workbench. Source marked as "phone" so it is distinguishable from other intake paths.
Integration with #168: Once the phone report is created and visible in communications, the FieldSeeker push toolbar (issue #168) can push it just like any other communication.
Phasing:
Does this direction sound right? If so, I will get started on a PR.
@ned that looks right to me
PR #173 is ready for review!
What it does:
@ned I did a more careful design review of the phone intake flow, and the three-track approach in PR #173 isn't going to work for real phone calls. Here's what needs to change and why.
The problem with three separate tracks
Real phone conversations don't stay in one lane. A caller reporting nuisance mosquitoes will also mention their neighbor's neglected pool. Someone calling about a compliance flyer will describe adult mosquito activity without being prompted. The operator shouldn't have to pick a track before they know what the caller is going to say — and they shouldn't have to switch tracks mid-call.
The fix is one form with all sections always visible, and three call-reason checkboxes at the top that the operator checks as the conversation develops. All three can be checked on a single call.
The form needs its own space — don't cover the map
PR #173 replaces the map with the form. That's backwards. The map is the operator's most important context tool. Satellite view tells them whether this is a rural property (pasture mosquitoes) or dense urban (Aedes aegypti containers). Nearby call pins tell them if this is part of a cluster or an isolated report.
Move the form into the right column — the action-items panel area. Map stays visible at top. Center panel stays free so the operator can search property records and look up other information while they're on the call.
The operator isn't an entomologist
The current design asks about larvae and pupae. The caller can't answer those questions. Replace technical mosquito-development fields with conversational questions the caller CAN answer:
Use quick-append toggle buttons for common answers. Each button does two things: appends readable text to a notes field, and applies a tag string that backend logic can use for classification. The tags are configuration, not hardcoded schema — we should be able to change them per district without code changes.
Daytime →
day-biting, Morning or evening →crepuscular-biting, Indoors →indoor-biting, Outdoors →outdoor-biting, All day →all-day-biting, Not being bitten →no-bitingStanding water is shared, not duplicated
The current design duplicates standing-water questions between the nuisance track and the standing-water track. Don't. One Standing Water section on the form. Quick-append buttons for common water sources, and because "other" is as common as any specific category, buttons keep the operator moving instead of forcing an awkward selection from an incomplete list.
On the caller's property: Potted plants, Yard drains, Containers, Pool/spa, Kiddie pool, Other
Nearby: Neighbor, Ditch/drain, Field, Other
Owner: Caller, Neighbor, Public, Unknown
Adults seen at water: Yes many, Yes a few, No
Each button appends text and a tag (e.g.
source-potted-plants,nearby-neighbor,owner-caller,adults-many).The feature location gets its own address field + map pin. The water might be at a different address than the caller, so this has to be separate. Two workflows: type an address, or click on the map.
Photo capture during the call
There's no mechanism for this in the current design. Every call needs file upload buttons — [Send Text] [Send Email] [Copy URL]. The link carries the call session so the caller doesn't re-enter anything. They open the link, add files, done. The upload page should be as bare as possible — just the upload UI, no context about the address or reason. If something is wrong with the upload, a bare page gives the caller nothing to argue about.
Accepts any file type: images, documents, signed mosquito control plans, PDFs.
This is available on every call, not just compliance.
Full form structure
Fixed order, every section always visible, operator tabs through. Same layout every call — builds muscle memory. Auto-save as the operator works, Submit to complete.
Each section has a visible PROMPT telling the operator what question to ask.
When a call-reason checkbox is checked, its corresponding section gets a background highlight color so the operator can visually scan which sections are active. All sections stay visible regardless.
1. Caller — Name, Phone, Email, Caller Address (required, with address lookup), Preferred Language [English] [Spanish]
2. Call Reason (multi-select) — ☐ Compliance flyer, ☐ Adult mosquito problem, ☐ Reporting standing water
3. Compliance (green highlight) — Prompt: "Why are you calling about the flyer? Are you having trouble submitting evidence? Do you know why you were contacted?" Text area for what the caller says.
4. Adult Mosquitoes (orange/red highlight) — Prompt: "When are you seeing them, and are you getting bitten?" Toggle buttons as described above, plus a text area for what they describe.
5. Standing Water (blue highlight — shared) — Prompt: "Do you have containers, plants, pools, or water around your home? What about your neighbors?" Quick-append buttons as described above. Feature location with separate address + map pin.
6. Dogs — ☐ Dog on property. Applies to any call reason. Safety field for tech visits.
7. Scheduled — Date/time text if a visit is scheduled during the call. Don't build scheduling into the form, just capture it if it happens.
8. File Upload — [Send Text] [Send Email] [Copy URL]
9. Notes — free text catch-all
FieldSeeker mapping
The data from this form maps to ServiceRequest columns. Here's the complete mapping:
Caller info → CLR* fields: Clrfname, Clrphone1, Clremail, Clraddr1/Clrcity/Clrstate/Clrzip (from geocode), Clranon (1 if anonymous), Spanish (1 if Spanish, 0 if English)
Feature info → REQ* fields: Reqaddr1/Reqcity/Reqstate/Reqzip (separate from caller), Reqpermission (1 if granted)
Text flow: Everything the caller says — compliance text + mosquito text + standing water text + notes — concatenated into Reqdescr. All button tags combined comma-separated into Reqtarget. Tech-relevant info (dog, permission, scheduling) into Reqnotesfortech.
Operational: Dog (1 if checked), Scheduleddate/Scheduled/ScheduleNotes, Source = "Phone" hardcoded, Entrytech = operator who took the call.
Left null intentionally: Issuesreported, Reqfldnotes, Reqnotesforcust, Reqprogramactions, Comments — these are for field staff or unused.
Future (lower priority — your judgment on timing)
@ned are you reading?
Reading, neighborino! 👋 And sorry it went quiet after PR #173 — I've now gone through the design review top to bottom, and you're right: the three-track approach doesn't survive contact with a real phone call. It's already superseded (#173 is closed), so this lands as a fresh PR.
Here's my read of the new direction, so we're aligned before I start:
What changes vs. the old approach
Decisions I'm making (flag if you disagree):
Plan:
On the two future items (property-history address lookup, notice details): agree they're high-value, and I'll keep the data model from painting us into a corner on them, but I'll treat them as follow-ups after v1 is reviewed.
Starting now. Okaly-dokely do! 🎯
Hi @ned, sounds good, go for it