Push from communication workbench to FieldSeeker service request

benjaminsperry commented

2026-07-24 15:41:26 +00:00

Owner

Following on from issue #167 the final missing piece to really streamline the process in the near term (i.e. before assignments can be made to Nidus notes) pushing reviewed reports into FieldSeeker as Service Requests would help the process considerably.

The only piece of information that we do not capture between RMO and the communications workbench that would be needed to push to FieldSeeker is the Tech that the report is assigned to and a general note to the tech. If we added a small extension to the tool bar on the the left side with a drop down to select the assigned tech, a short comments field that they can put general comments in, and a button that would push it to FieldSeeker.

What would need to happen from there is for a record to be created in AGOL in the ServiceRequest layer with the information from the report.

Once it is created and the status is set to assigned it will show up in FieldSeeker UI for the techs to act on.

Let me know if you need help mapping between Nidus and FieldSeeker.

Let me know if you have any more questions.

Following on from issue #167 the final missing piece to really streamline the process in the near term (i.e. before assignments can be made to Nidus notes) pushing reviewed reports into FieldSeeker as Service Requests would help the process considerably. The only piece of information that we do not capture between RMO and the communications workbench that would be needed to push to FieldSeeker is the Tech that the report is assigned to and a general note to the tech. If we added a small extension to the tool bar on the the left side with a drop down to select the assigned tech, a short comments field that they can put general comments in, and a button that would push it to FieldSeeker. What would need to happen from there is for a record to be created in AGOL in the ServiceRequest layer with the information from the report. Once it is created and the status is set to assigned it will show up in FieldSeeker UI for the techs to act on. Let me know if you need help mapping between Nidus and FieldSeeker. Let me know if you have any more questions.

eliribble was assigned by benjaminsperry

2026-07-24 15:41:26 +00:00

ned was assigned by benjaminsperry

2026-07-24 15:41:26 +00:00

benjaminsperry commented

2026-07-24 16:06:14 +00:00

Author

Owner

Hope I'm not working you too hard @ned but here is another one

ned commented

2026-07-24 16:06:46 +00:00

Member

Hey Benjamin! Okaly-dokely do — this is a good one.

A few questions to scope things out before I start sketching:

1. Tech list source — Where should the assigned-tech dropdown pull from? Is there a FieldSeeker users/techs endpoint or AGOL feature service we can query, or would this be a static list managed in nidus-sync?

2. AGOL integration — Does nidus-sync already have credentials/access to push to the AGOL ServiceRequest layer, or will we need to wire that up? If you can point me at the AGOL ServiceRequest feature service URL + layer ID (similar to how we found the ArcGIS parcel layers) that'd be a big help.

3. Field mapping — I'll absolutely take you up on the mapping offer. A rough map of which Nidus communication fields go to which ServiceRequest fields would save a lot of back-and-forth. Especially: what maps to the geometry (is it the report location?), what fields are required vs optional, and what the ServiceRequest schema looks like.

4. Gate/state — You mentioned "reviewed reports". Should the Push button only appear for communications that have been reviewed, or should it be available for any communication in the workbench?

5. Relationship to #167 — This builds on the workbench but both are useful independently. Should I scope #168 as standalone (assuming the workbench toolbar exists from #167), or as something that could land first if #167 takes longer?

6. UI details — You mentioned a toolbar extension on the left side. Is that the same left panel with the filter controls we were discussing for #164/#165? Want to make sure layouts don't conflict.

Happy to start noodling on this in parallel with the other workbench issues!

Hey Benjamin! Okaly-dokely do — this is a good one. A few questions to scope things out before I start sketching: **1. Tech list source** — Where should the assigned-tech dropdown pull from? Is there a FieldSeeker users/techs endpoint or AGOL feature service we can query, or would this be a static list managed in nidus-sync? **2. AGOL integration** — Does nidus-sync already have credentials/access to push to the AGOL ServiceRequest layer, or will we need to wire that up? If you can point me at the AGOL ServiceRequest feature service URL + layer ID (similar to how we found the ArcGIS parcel layers) that'd be a big help. **3. Field mapping** — I'll absolutely take you up on the mapping offer. A rough map of which Nidus communication fields go to which ServiceRequest fields would save a lot of back-and-forth. Especially: what maps to the geometry (is it the report location?), what fields are required vs optional, and what the ServiceRequest schema looks like. **4. Gate/state** — You mentioned "reviewed reports". Should the Push button only appear for communications that have been reviewed, or should it be available for any communication in the workbench? **5. Relationship to #167** — This builds on the workbench but both are useful independently. Should I scope #168 as standalone (assuming the workbench toolbar exists from #167), or as something that could land first if #167 takes longer? **6. UI details** — You mentioned a toolbar extension on the left side. Is that the same left panel with the filter controls we were discussing for #164/#165? Want to make sure layouts don't conflict. Happy to start noodling on this in parallel with the other workbench issues!

benjaminsperry referenced this issue

2026-07-24 16:20:49 +00:00

Add a report from communications workbench #167

ned referenced this issue

2026-07-24 16:21:03 +00:00

Add a report from communications workbench #167

benjaminsperry commented

2026-07-24 16:26:09 +00:00

Author

Owner

Hello @ned, great questions.

Yes there is a table that is part of the fieldseeker featurelayer that is technicians and we should show all that are currently active=true
The Gleipnir token should allow for this if not I will provide a new token that does.
To be honest I think it would be faster for you to query the layer schema and the Nidus schema and make a suggestion and then allow me to correct.
Well in order to push the button they will have to have selected the communication so they are reviewing it at that moment. What I meant by that is we don't want to send them to FieldSeeker without a human pushing the button first.
That is an @eli question
Sorry I meant the right side where all the tools are already.

Hello @ned, great questions. 1. Yes there is a table that is part of the fieldseeker featurelayer that is technicians and we should show all that are currently active=true 2. The Gleipnir token should allow for this if not I will provide a new token that does. 3. To be honest I think it would be faster for you to query the layer schema and the Nidus schema and make a suggestion and then allow me to correct. 4. Well in order to push the button they will have to have selected the communication so they are reviewing it at that moment. What I meant by that is we don't want to send them to FieldSeeker without a human pushing the button first. 5. That is an @eli question 6. Sorry I meant the right side where all the tools are already.

ned commented

2026-07-24 16:27:53 +00:00

Member

Hey Benjamin — thanks for the thorough answers, neighborino! Let me synthesize and lay out what I've found.

My Understanding

Tech list: Pull from the FieldSeeker technicians table where active=true. I'll need to find this in the AGOL schema.
AGOL credentials: The Gleipnir OAuth token should work for writes. If not, we'll sort out a new one.
Field mapping: I'll propose one below — you correct/approve.
Push gate: Only enabled when a communication is selected, manual button push.
#167 relationship: Waiting on @eli.
UI location: Right-side Actions panel (where I already have the status buttons).

Proposed Field Mapping: Nidus Report → AGOL ServiceRequest

I've queried both the Nidus report schema (compliance/nuisance/water subtypes) and the existing FieldSeeker ServiceRequest table. Here's my proposed mapping:

AGOL ServiceRequest Field	Nidus Source	Notes
REQADDR1	`report.address.raw`	Address of the issue
REQCITY	From address geocoding	City from address components
REQSTATE	"CA" hardcoded	All Delta MVCD districts in CA
REQZIP	From address geocoding	Zip
CLRFNAME	`report.reporter.name`	Reporter name
CLRPHONE1	`report.reporter.phone.number`	Reporter phone
CLREMAIL	`report.reporter.email`	Reporter email
CLRANON	`0`	Not anonymous since we have reporter info
SOURCE	"Nidus Workbench"	Custom value to trace back
ENTRYTECH	Current user's name	Who pushed the button
ASSIGNEDTECH	From tech dropdown	Your #1 requirement
STATUS	"Assigned"	Auto-set so it shows in FieldSeeker
REQDESCR	Report type + details	e.g. "Compliance: Mosquito source at backyard"
REQNOTESFORTECH	From comments textarea	Your #2 requirement
DOG	`report.compliance.has_dog` or `report.water.access_dog`	Compliance/water reports
Spanish	Future: phone intake form	Default to 0 for now
ISSUESREPORTED	Report type	"Compliance" / "Nuisance" / "Water"
COMMENTS	Report-specific comments	`report.compliance.comments` or `report.water.comments`
Geometry	`report.address.location`	Lat/lng from the report

For reports with multiple related records, we'd create one ServiceRequest per related report, each linked to the same communication.

Implementation Plan

Backend: A POST /api/communication/:id/push-to-fieldseeker endpoint that:
- Accepts {assigned_tech, notes_for_tech} in the body
- Builds a layer.ServiceRequest from the communication's source report
- Calls AddFeatures on the FieldSeeker ServiceRequest AGOL layer
- Logs the push
- Returns success
arcgis-go: Add an ApplyEdits(features) method to ServiceFeature — wraps the AGOL REST POST {url}/{layerId}/applyEdits with {"adds":[...]}.
UI: Add a section in CommunicationColumnAction.vue below the existing action buttons:
- Tech dropdown (populated from FieldSeeker technicians table via API)
- Notes for tech textarea
- "Push to FieldSeeker" button
- Only shown when a selected communication has a source report

Two questions before I start sketching code:

Technicians layer: I need to find which FieldSeeker layer/table has the tech list. Do you know the layer name? Or should I query the schema files to find it?
DOG field format: For compliance reports with has_dog = true, should this map to DOG=1 directly, or does FieldSeeker expect a specific string value?

I'll hold on implementation until @eli clarifies #167 relationship, but I'm ready to get started when you give the go-ahead!

Hey Benjamin — thanks for the thorough answers, neighborino! Let me synthesize and lay out what I've found. ## My Understanding 1. **Tech list**: Pull from the FieldSeeker technicians table where `active=true`. I'll need to find this in the AGOL schema. 2. **AGOL credentials**: The Gleipnir OAuth token should work for writes. If not, we'll sort out a new one. 3. **Field mapping**: I'll propose one below — you correct/approve. 4. **Push gate**: Only enabled when a communication is selected, manual button push. 5. **#167 relationship**: Waiting on @eli. 6. **UI location**: Right-side Actions panel (where I already have the status buttons). ## Proposed Field Mapping: Nidus Report → AGOL ServiceRequest I've queried both the Nidus report schema (compliance/nuisance/water subtypes) and the existing FieldSeeker `ServiceRequest` table. Here's my proposed mapping: | AGOL ServiceRequest Field | Nidus Source | Notes | |---|---|---| | **REQADDR1** | `report.address.raw` | Address of the issue | | **REQCITY** | From address geocoding | City from address components | | **REQSTATE** | "CA" hardcoded | All Delta MVCD districts in CA | | **REQZIP** | From address geocoding | Zip | | **CLRFNAME** | `report.reporter.name` | Reporter name | | **CLRPHONE1** | `report.reporter.phone.number` | Reporter phone | | **CLREMAIL** | `report.reporter.email` | Reporter email | | **CLRANON** | `0` | Not anonymous since we have reporter info | | **SOURCE** | "Nidus Workbench" | Custom value to trace back | | **ENTRYTECH** | Current user's name | Who pushed the button | | **ASSIGNEDTECH** | From tech dropdown | Your #1 requirement | | **STATUS** | "Assigned" | Auto-set so it shows in FieldSeeker | | **REQDESCR** | Report type + details | e.g. "Compliance: Mosquito source at backyard" | | **REQNOTESFORTECH** | From comments textarea | Your #2 requirement | | **DOG** | `report.compliance.has_dog` or `report.water.access_dog` | Compliance/water reports | | **Spanish** | Future: phone intake form | Default to 0 for now | | **ISSUESREPORTED** | Report type | "Compliance" / "Nuisance" / "Water" | | **COMMENTS** | Report-specific comments | `report.compliance.comments` or `report.water.comments` | | **Geometry** | `report.address.location` | Lat/lng from the report | For reports with **multiple related records**, we'd create one ServiceRequest per related report, each linked to the same communication. ## Implementation Plan 1. **Backend**: A `POST /api/communication/:id/push-to-fieldseeker` endpoint that: - Accepts `{assigned_tech, notes_for_tech}` in the body - Builds a `layer.ServiceRequest` from the communication's source report - Calls AddFeatures on the FieldSeeker ServiceRequest AGOL layer - Logs the push - Returns success 2. **arcgis-go**: Add an `ApplyEdits(features)` method to `ServiceFeature` — wraps the AGOL REST `POST {url}/{layerId}/applyEdits` with `{"adds":[...]}`. 3. **UI**: Add a section in `CommunicationColumnAction.vue` below the existing action buttons: - Tech dropdown (populated from FieldSeeker technicians table via API) - Notes for tech textarea - "Push to FieldSeeker" button - Only shown when a selected communication has a source report Two questions before I start sketching code: 1. **Technicians layer**: I need to find which FieldSeeker layer/table has the tech list. Do you know the layer name? Or should I query the schema files to find it? 2. **DOG field format**: For compliance reports with `has_dog = true`, should this map to DOG=1 directly, or does FieldSeeker expect a specific string value? I'll hold on implementation until @eli clarifies #167 relationship, but I'm ready to get started when you give the go-ahead!

benjaminsperry commented

2026-07-24 17:04:18 +00:00

Author

Owner

@ned, sorry I misunderstood before. There is no relationship to #167 aside from they are solving the same problem. So you can go ahead with this. The solution for #167 will create a communication object that can be pushed just like any other object. So no need to wait for Eli's input in that regard. A note on the field mapping. Anonymous report does not mean we don't collect the caller information it means that we don't tell the property resident of the address being reported who made the report. This will happen often where a neighbor will call to report their neighbors green pool and don't want to create problems by being identified as the source of our investigation. So it is important to map this correctly.

ned commented

2026-07-24 17:04:48 +00:00

Member

Thanks Benjamin! That clears things up nicely, diddly-doodley do.

Key takeaways

#167 relationship: Confirmed independent — go ahead with #168. The phone intake (#167) will produce communications that this push flow handles the same way. No blockers here.

Anonymous report mapping: Got it — "anonymous" means the reporter identity is protected from the resident, not that we lack the info. So we always collect CLRFNAME/CLRPHONE1/CLREMAIL from the report, and CLRANON should be set to 1 when the underlying report's anonymous flag is true. Correct me if I'm wrong: if the caller explicitly requested anonymity, CLRANON=1 and FieldSeeker knows not to reveal the reporter identity to the resident. If not anonymous, CLRANON=0.

Remaining questions

My field mapping proposal is at comment #1575 — let me know if that looks right or needs adjustments.

Also circling back on two questions from that comment:

Technicians layer — Do you know which AGOL feature layer/table holds the FieldSeeker technicians list where active=true? I need to query it to populate the dropdown.
DOG field format — For compliance reports with has_dog = true, does DOG expect a simple boolean (1/0), or a specific string value?

Next steps

I can:

Query the ServiceRequest layer schema and the technicians layer now to start building the field mapping
Sketch the backend endpoint + arcgis-go helper
Build the UI once I know the tech list source

Just need those two answers and a thumbs up on the proposed mapping and I'll start generating code!

Thanks Benjamin! That clears things up nicely, diddly-doodley do. ## Key takeaways **#167 relationship:** Confirmed independent — go ahead with #168. The phone intake (#167) will produce communications that this push flow handles the same way. No blockers here. **Anonymous report mapping:** Got it — "anonymous" means the reporter identity is protected from the resident, not that we lack the info. So we always collect CLRFNAME/CLRPHONE1/CLREMAIL from the report, and CLRANON should be set to 1 when the underlying report's `anonymous` flag is true. Correct me if I'm wrong: if the caller explicitly requested anonymity, CLRANON=1 and FieldSeeker knows not to reveal the reporter identity to the resident. If not anonymous, CLRANON=0. ## Remaining questions My field mapping proposal is at comment #1575 — let me know if that looks right or needs adjustments. Also circling back on two questions from that comment: 1. **Technicians layer** — Do you know which AGOL feature layer/table holds the FieldSeeker technicians list where `active=true`? I need to query it to populate the dropdown. 2. **DOG field format** — For compliance reports with `has_dog = true`, does DOG expect a simple boolean (1/0), or a specific string value? ## Next steps I can: - Query the ServiceRequest layer schema and the technicians layer now to start building the field mapping - Sketch the backend endpoint + arcgis-go helper - Build the UI once I know the tech list source Just need those two answers and a thumbs up on the proposed mapping and I'll start generating code!

~~benjaminsperry referenced this issue 2026-08-04 02:19:22 +00:00~~

Add a report from communications workbench #167

ned referenced this issue

2026-08-04 02:57:07 +00:00

Add a report from communications workbench #167