Show IMS number and "create incident" button on Field Report page

[virtual256]

Frequently, experienced Rangers will stop by the Operator shack to get the relevant IMS number for their Field Incident Report. As is, this will usually get entered into the subject line. Adding a dedicated place for this (and possibly a note to stop by the Operator shack) will help to streamline the process of attaching FIRs to IMS entries.

[prqpn]

OODs have also requested the ability to have a new Incident be created upon submitting a (Field) Incident Report for which it is known a corresponding Incident does not already exist. (OTDB 2023 #234; from OOD AAR).

[srabraham]

I'm going to take a shot at @prqpn's request

[srabraham]

OK, so here's my plan: we'll create a new view-only "IMS #" field on the Field Report page. If there's not an IMS # already for the FR, then we'll show a button to let the user create one. We'll only show the button if the user has writeIncidents permissions.

While I'm in here, I'd also like the make the FR instructions collapsible, since they're very long and noisy for operators. We can have the instructions be visible by default, but hidden for people with writeIncidents permissions.

[kimballa]

Thanks Abraham!

Just to double check where you're going with this:

• There will be a view-only IMS # field on the "New/View Field Report" page.
• When a user is creating a new field report, this will be blank. If an operator has said "btw, Bucket, when you create your field report, reference IMS 123", they'll still just type 123 in the title field as is current best-practice (e.g SA at Camp Incidentful - #123).
• If the field report is already attached to an incident, and you're viewing the field report (rather than creating a new one), the IMS # field will be populated with the incident it is attached to. (And, presumably, this is a link that lets them go to the incident in question?)
• If the field report is not attached to an incident, and the user has writeIncidents permission, the empty IMS # field is replaced with a button to Create new incident.
• When clicked, that button will:
  • Create this Field Report with the text in the title/body (i.e., act as a submit button), if this is a brand new FR,
  • Create a new Incident,
  • Set the Incident title to the title from the field report,
  • Add the author of the field report to the Rangers list,
  • And attach the field report to the Incident in question.

Is my understanding correct?

+1 to implementing all of that, and +1 to collapsable instructions (and hiding them intelligently based on user role).

If the "read only field" to display the attached IMS # is in fact a link to the Incident in question, I would suggest that should also be a button, if the user has readIncidents permission. (e.g.: [View IMS #123]).

In which case I think the UI change cases are:

• If the user has no incident-level permissions, they see nothing they don't see today / no change to the UI.
• If the field report is attached somewhere and (the user has readIncidents or writeIncidents permission), you have a button to view the incident.
• If the field report is unattached and the user has writeIncidents permission, you'd have a button to create the new incident
• If field report is unattached and the user only has readIncidents permission, they see nothing there. (Effectively the same case as for users with no permission beyond creating field reports.)

fwiw, I think the original request from @virtual256 was to create a separate field for intended incident # where the field report author could enter the number given to them verbally by the Operator (rather than an IMS # field that shows the actually bound incident post-attachment); presumably that could lead to the following UX improvements:

• The "attach field report" drop down in an Incident display would put any field reports with matching intended incident # at the top of the dropdown list
• The Incident display page could have a banner or mid-screen toast or other highlight saying something like "There are new field reports for this incident" with a button to quickly preview the field report(s) in question and/or directly attach them to the incident.
• When viewing the field report, someone with writeIncidents permission could have a button that says "Attach directly" which would attach the field report to the intended incident.
• After the field report is attached to an incident, the intended incident # is updated to the actually-attached incident, and is not directly writable in the UI.

To be clear, I think the improvements you are proposing (i.e., the first / second bulleted lists above) are helpful and I am +1 to both. But they are slightly different from what I understood the spirit of the request to be.

I might suggest that these might be separate feature improvements / issue #'s here.

[srabraham]

Hey @kimballa , your understanding of my next steps (which are now in a PR) are almost totally correct. The one correction (relevant to your text afterward too) is that I provide the linkified incident number even for people without readIncidents. They can click on it and get a "permission denied", but that's consistent with the rest of the system (indeed, we show incident numbers in the Field Reports table page, even for people without readIncidents).

I see what you mean about @virtual256 's ask versus my suggestion. Hmmm...I'll ponder that. Let's discuss it when we talk soon

Sidebar: the "attached incident reports" dropdown is now easier to work with, so that's cool, and makes the Operator's situation a fair bit better: #1319

[kimballa]

nice! (And, a button that leads to "permission denied" is also fine imo.)

btw, I think it's actually totally reasonable in #1319 to just not show field reports attached to some other incident. So long as there's an easy way (which I think there is) to unattach a FR from a given incident, a workflow of "consciously unattach, followed by re-attach to new target" seems reasonable for that fairly rare case, and eliminates clutter in the more common case of "Attach an unattached FR to this incident."