Adding the BMP Inspection feature service to the Firm Edit Maps

[KCI-Ablowers]

The firms need the ability to see and edit only their inspection records in the feature service. Could we share the _NNG_BMP_Inspection_Prod20180424 feature service with the firm groups, add it to each Firm's Edit Map, apply a query based on the firm name and then "un-share" the web map with that firm. The last step would only work if they could still use the Edit App without the map being shared with them. Un-sharing the map would remove the ability for a firm to open the web map and remove the query applied to the BMP Inspection feature service.

[talllguy]

Isolating the inspections to a particular firm is challenging due the inability to publish a configurable view in AGOL. There is no way to "unshare" a web map with a particular group. We can prevent group members from adding new content to a group and from editing, but they can always save a copy of a map and then remove any filters.

The firm's requirement to edit existing inspections is satisfied by the Inbox feature in Survey123. The table that powers the inspection is not meant to be edited directly. It lacks the validation that S123 enforces.

What reasons are there for allowing direct edits to the inspection that cannot be met with the inbox?

[KCI-Ablowers]

Technically, there isn't a need to edit the feature service directly. However, I think we need a solid method for QAQC'ing inspection data, which I don't think we have focused on too much. Since @johnshiu added the ETL Issues to the BMP Inspections table, there needs to be some type of viewer for the inspection records (queried by firm) or exported table (queried by firm) for the user.

An in-house example is our first production run. @brentreeves75 wanted a copy of our inspection records, so I made a simple web app for myself with the attribute widget set to allow a CSV export. This worked because only our inspection records were present at the time. He reviewed the CSV export and sent me back the updates. Regretfully, I made those updates directly to the inspections table in feature service, which I will not do moving forward. These updates can and should be done in the Sent box by editing then resubmitting the survey to avoid creating a duplicate record.

Another thing we should note (I will add to the SOP) is that the inspection records will be wiped (by firm) when pushed using the field-to-source ETL. When this occurs, the firm/person performing QAQC should clear the sent box on all of the devices (PC, iPad, etc.) used for data collection. This would eliminate the need to scroll through a ton of surveys looking for the one that needs the updates. On the flip side, once the sent box is cleared, how would a user edit an inspection rating?

[talllguy]

Briefly, now that we have a better handle on the consultant groups, it'd be easier to make a per-group survey, that'd have the team built in. This was the original plan. That would allow us to make inbox edits filtered.

More to come.

[talllguy]

After today I think we should rethink this. Editing in the map might not be so bad. One user asked how they would find one to edit in the inbox if there were hundreds. @johnshiu do the PLTS checks do QC on inspections? Usability might trump keeping edits in S123. Maybe.

[johnshiu]

Yes, the in-place field ETL does perform QC on inspections and updates the FLD_ETL_ISSUES field.

One way to potentially add this is similar to what was done with the overlay #104 and the definition query. Instead, you would have a definition query for the firm name, so that each firm could only see/edit their own inspections. You could additionally add the FLD_ETL_ISSUES is not null check as well so they only see errored inspections, or they can do that locally in the web map themselves against the firm-filtered layer.

[talllguy]

I like the idea of another definition query for handling inspection edits directly in WAB. The downside is that it is another n layer to maintain.

We must prevent one firm from editing another's inspections inadvertently, though. I had concerns that a view #222 or edit layer would expose one firm's inspections to another. A query should provide enough of a barrier that any cross-firm edits would be in bad faith (e.g. alter the Firm field to have it show up under another).

I have also considered making n copies of the inspection form for each firm with the FIRM_NAME hardcoded in. That would make the Inbox edits available to all users of the firm, but maintaining a single survey form is cleaner and easier. I will test out the definition query approach for inspection edits.

I also wonder if Survey123 can submit edits to a definition queried layer 🤔

[johnshiu]

I agree that the definition queries get very cumbersome to manage on the feature service end with so many versions. It should be the safest, however. You could also lock that firm_name field from being editable in the web map so they can't accidentally change it.

Also, don't know if this is what you're thinking of doing, but you could also create one feature service, with n layers, each pointing to a different version, instead of n feature services with 1 layer. Might be easier to manage.

[talllguy]

Do I need to filter the #231 flag in the definition query or are those ones pre-filtered at a lower, database level?

[johnshiu]

Those GDB_* fields are only accessible directly in Oracle, so you shouldn't be able to see them ever in ArcMap/Catalog. Therefore, you don't need to worry about filtering those.

[talllguy]

Closed via https://github.com/kcigeospatial/MDOT-SHA-NPDES-Next-Gen/issues/213#issuecomment-405609560