Open RobRuana opened 7 years ago
This brings up some business process questions. Do we want non-security staff handling 'attendee incidents' and logging them independently of our security crew? Like, is this for "staffer showed up to shift drunk, told him to go sleep it off" or is it for "someone was causing a public disturbance and I handled it without calling security?"
If it's the latter, and if we WANT certain staff to be doing this, we would really want to set up guidelines on how to behave in these situations. If it's the former, we might think about different levels of 'incident' (like warning, debug, error... er, no wait) with different accesses. And in either case, we want to loop in the DI on this and see if they'd use this feature and what they'd want from it.
Oh, and if we're doing this in RAMS already, we definitely want to record the fk_ids of Attendees who are involved. Maybe a field for "bystander" and "involved attendees" to delineate between 'people who we might want to contact to get more info about this incident from' and 'people who are Causing Problems'. It'd have to be optional, just so you could log incidents that don't actually involve paying attendees.
Whoops, I think this was meant to target staff incidents rather than attendee incidents.
As an admin, I would like to be able to log an incident involving an staffer and view that staffer's incident history, so that I can determine if an staffer is a bad actor or if the current incident is isolated.
The incident log should be accessible by admins, and locked down with the same access controls as the watchlist.
The incident log should capture, at a minimum, the following fields: