[Feature]: Extra Data Prompt

[cbyrdmo]

What problem are you trying to solve?

The extra data prompt is really handy. It would be nice to allow it to have multiple lines.
I can see facility as one. We always call start mileage also..

What would you like it to do?

Make Extra Data Prompt on unit status multiple entries.

How do you handle it now?

It is just added as a note now.

What kind of group are you in?

CERT / community emergency response

Who do you think needs this?

Likely useful to most groups running TicketsCAD

Could you help build or test it? (optional)

No response

[rjonesbsink]

Had a look at how extra_data is wired, since @cbyrdmo's example (facility and start
mileage on the same status) turns out to sit close to some plumbing that already exists.
Reading only — scope and shape are yours.

Where the single-entry limit lives

It's the schema rather than the UI. un_status declares one of each:

extra_data_type     enum('none','facility','mileage','location','note','numeric')
extra_data_required tinyint(1)
extra_data_label    varchar(64)
extra_data_target   enum('incident','unit','action_log','assignment')

So a status collects one datum, with one label, routed to one place. Multiple entries
means those four become a list, and the ['type' => …, 'value' => …] payload that
responder_set_status_internal() takes becomes a collection.

The part I'd think about first: the target is per-status, not per-datum

That's the bit that doesn't obviously generalise. A status collecting two things may
want them in two different places, and today there's one extra_data_target for the
whole status. @cbyrdmo's pair is a good illustration:

• facility → assignment is implemented — _phase95_route_to_assignment() writes
  assigns.rec_facility_id, which is the per-unit destination hospital from Phase 116.
• mileage → currently only meaningful at incident scope, where it inserts a row in
  the mileage table. _phase95_route_to_assignment() opens with
  if ($type !== 'facility') return; — "facility is the only assignment-scoped datum
  today".

So for their case both data want to land on the same assignment row, and one of the two
routes doesn't exist yet.

The storage is already there, which may make this smaller than it looks

assigns carries both, side by side on the same row:

rec_facility_id    (written today, by the facility path)
start_miles        int
on_scene_miles     int
end_miles          int

And api/incident-detail.php:208-210 already SELECTs start_miles, on_scene_miles
and end_miles for display.

But nothing writes them. Searching the tree for start_miles returns exactly one
hit — that SELECT. So there's a per-assignment mileage column that is read and shown and
never populated by any current path. I'd guess it's a v3 column the NewUI inherited and
displays, with no writer carried across, but that's a guess rather than something I
checked.

If that's right, then for the facility-plus-start-mileage case specifically, the storage
and the display both already exist and what's missing is the collection: a status being
allowed to ask for two things, and the assignment router learning mileage.

Not proposing any of this. You'll know whether multi-entry is worth the schema
change versus, say, a numeric field with a good label, and whether those mileage
columns are meant to be alive or are due for removal. Flagging it because "make it
multiple" reads like a UI change and the interesting constraint is one layer down —
and because a column that's displayed but never written seems worth knowing about
either way.

Happy to test.

[ejosterberg]

Good pointer, @rjonesbsink — useful that this sits close to existing plumbing rather than needing something new from the ground up. The schema change (single extra_data_* columns → a list) is the real scope question here, since it touches how existing installs' data migrates too. Leaving open as a feature request for Eric's call on priority.

[ejosterberg]

Eric asked for a recommendation with real options and trade-offs here, so let me lay those out.

What's actually true today, confirmed against the code: a status collects at most one datum (un_status.extra_data_type/required/label/target are single columns, not a list), and _phase95_route_to_assignment() in the assignment-write path explicitly gates on if ($type !== 'facility') return; — mileage is a no-op there today. Separately, assigns.start_miles/on_scene_miles/end_miles already exist in the schema and are already SELECTed and displayed by api/incident-detail.php — nothing currently writes them. That's a real gap independent of whatever we decide about multi-entry.

Three options, smallest to largest:

1. Wire up the mileage column that already exists — no schema change. Add a mileage case to _phase95_route_to_assignment()'s type switch, same shape as the existing facility case. This alone doesn't let one status collect BOTH a facility and mileage at once — but it means an install can configure one status (say, "En Route") to collect mileage and a different status ("Available") to collect the destination facility, and both would actually work end to end for the first time. Cheapest possible change, zero migration risk, ships today. Doesn't solve simultaneity if that's the real ask.

2. A second, fixed extra-data slot. Add extra_data_type_2/extra_data_label_2/extra_data_required_2/extra_data_target_2 alongside the existing four columns. Covers exactly the two-things-at-once case you described (facility + mileage on one status change) without a new table. Existing installs are unaffected — new columns default to "none." The UI gets a second, optional field-config block in the status editor instead of a repeatable list. Doesn't generalize past two; if a third need shows up later, this shape gets awkward fast (a third set of _3 columns would be a bad sign).

3. Full multi-entry — a child table. A new un_status_extra_fields table (status_id, field_type, label, required, target, sort_order), status editor gets a real repeatable "add another field" list, and the collection payload becomes an array instead of one {type, value} pair. This is the properly general answer and the one that ages best if agencies keep asking for more combinations — but it's real schema work, a migration path for existing single-extra_data configs, and changes the shape of data responder_set_status_internal() accepts and every consumer of it reads. Biggest option by a wide margin.

My recommendation: do #1 first regardless of what else you decide — it's close to free and it closes a real "the column is right there and nothing writes it" gap on its own. Then see whether #1 alone satisfies the reported need (mileage and facility on separate statuses may be good enough in practice) before committing to #2 or #3. If simultaneity turns out to matter, I'd reach for #2 over #3 — two is what's actually been asked for, and building the general N-field version before a second real use case shows up is exactly the kind of thing worth waiting on.

Let me know which of these you want to move on, or if you'd rather just start with #1 and revisit.

[cbyrdmo]

On idea #1, Instead of collecting mileage on the available stage could you collect it on 'at destination"

[ejosterberg]

Built the missing piece — the second slot's admin UI is in now. Settings → Unit Statuses → any status → "Second Extra Data Prompt" gives you the same Type/Send To/Prompt Label/Required fields as the first slot, independently. So a status can now collect e.g. a destination Facility (routed to the assignment) and starting Mileage (routed wherever you point it) on the same status change.

@cbyrdmo — on your "at destination" question: that's just a matter of which status you configure the Mileage prompt on. Set it on whichever status change actually happens at destination, not necessarily "Available." Any status can carry either slot now.

Live on training and Bloomington.

[cbyrdmo]

If you select TRP from the situation screen it has a pop up for facility.

If you select the same from the incident screen using the action pull down and select trp it gives you a pop up box but no facility list as from the situation screen.

It also greys out the the options to change the destination or action, if you change to trp arrive and then select trp for a stop to another facility. Once you change the pull down option it greys them out and you can no longer change the status unless you leave the page and change the status. It also is not updating the activity log for the destination that is selected in that field

[ejosterberg]

Found it, and it's bigger than the popup -- the Incident page's status-change path never got any of this feature. window.TCADStatusExtraDataPrompt (the facility picker) had been referenced in the code since July but was never actually built anywhere -- it silently fell back to a plain browser prompt() that can't show a facility list, which is symptom 1. That's also what caused symptom 2: when that fallback prompt was cancelled or given bad input, nothing re-enabled the dropdown, so it stayed stuck until you left the page. And symptom 3 (no activity log entry) was because the Incident page's status writer never got the second-slot support at all -- it only knew about slot 1.

Fixed all three:

• Built the missing facility picker for real, matching what the Situation screen already has.
• The status dropdown now re-enables itself after ANY outcome -- cancel, error, or a network hiccup -- not just success.
• The Incident page's status writer now handles both extra-data slots, and the activity log records what was actually picked (e.g. "TRP [Destination: Regional Medical] [Starting mileage: 12345]") instead of just the status name.

Also handles either slot being the facility one -- your setup (destination as one field, something else as the other) works regardless of which slot each is configured in.

Shipping in the next release. Can you confirm and close this once it's live?

[cbyrdmo]

Maybe I am not using this correctly. When I enter a Transport, it pops up for facility, I am not finding the second data option to enter mileage. When I do Trp arrived it asks for mileage then.

[ejosterberg]

Found it. The dual-slot feature only ever worked on two of five places a status change can happen -- the dashboard's Responders widget and the Incident Detail page. It never worked on Unit Detail, the mobile interface, or the /s command bar, because none of those three had any idea slot 2 existed: they never fetched the second slot's config from the API, and their status-change logic only ever checked the first slot.

So on Transport (if that's configured with a second slot for mileage), you'd get the facility prompt from slot 1, and slot 2 would simply never be offered -- not because it wasn't configured, but because the page you were on had never been taught to look for it.

Fixed all three to chain slot 1 then slot 2, matching how the dashboard widget and Incident Detail page already do it. Also fixed the command bar's refusal check, which only looked at slot 1 -- a status needing only a second slot used to slip past it and fail confusingly instead of telling you to use the modal.

Live on training and Bloomington now. Can you try Transport again and confirm both prompts show up?