Consider using something other than Clubhouse "on site" status to determine if a Ranger is working

[srabraham]

IMS currently uses a Clubhouse Person's on_site status to gate a bunch of access.

Full example: Operator Abraham doesn't have any access to IMS pre-event. He shows up on-playa and has HQ mark him as being on-site for the event. Now, IMS will grant him the access he needs as an Operator for that event. When he tells HQ he's done for the year, they mark him off-site, and he loses his IMS access.

@mikeburg suggested while talking with me recently that we might consider looking at timesheet information instead, because on_site isn't really meant for what we're using it for. @mikeburg: what's the reason timesheets would be preferable? I wasn't totally clear on that after we talked.

[mikeburg]

@srabraham Timesheets confirm whether the person actually worked during the event. The on-site flag only indicates that they showed up at the HQ Window at some point, but it does not provide evidence of any work being performed.

[srabraham]

Ah, thanks, that makes sense. On-site is certainly simple. How would you suggest checking if someone is done for the year? The on-site flag is currently serving useful double-duty, blocking access to people before they check in with HQ and again after they check out.

[mikeburg]

Sorry I meant to mention the on site flag is NOT an off-site reliable indicator. This last event only 15% of the volunteers were marked off site. This is way up from previous years. My theory is the HQ Window Interface is to blame. The check-in/out management page underwent a major overall, and ask-if-they-are-done indicator is not prominent enough.

The bigger question is: what security risks arise from allowing access until a specific deadline, such as mid-September or later? For example, imagine a Ranger heads home and suddenly remembers information they forgot to enter into the IMS. If the on-site flag is used as a gatekeeper, the Ranger is unable to enter the information directly. Instead, they must email someone to have it entered, which could lead to issues. They might either forget to send the email altogether or not know who to contact, resulting in the info being lost.

[srabraham]

Good points! The use of that "on-site" flag to gate IMS access long predates my involvement around here, so I'm not sure of what the original intentions were. With respect to wanting to add information after leaving the playa, I had that exact experience, so I agree!

OK, so maybe what we'd want is to grant access to a person some number of hours before their first scheduled on-playa shift, and to extend it some number of hours (or days) after their last shift (and possibly totally disregard on-site)? I'll have to dig into the timesheet data a bit to understand intricacies. A boolean column has the advantage of being trivially simple

[flwyd]

Having worked a bunch of end-of-the event HQ window shift, I suspect most of the folks who get marked off-site are folks who show up at the window to return their event radio before heading home. Folks who don't have a radio just pack up and leave, without telling HQ that they're gone. (Folks will sometimes tell the window to mark them off-site when signing out of the last shift of the week, but this probably isn't very common.)

I concur that it's weird to have an access control that results in "You can log onto the IMS when you get home, but only if you don't tell HQ you're leaving."

[wsanchez]

This is part of why the on-site flag is not used once I reconfigure the server when we all leave the event.

We have some trade-offs to make, and the reason I went this way is that:

• If you don't work in 2025, you don't need access to the IMS in 2025, even if you are an operator.
• Working in 2025 is not the same as "have signed into a shift in 2025". An OOD may start days before their first shift and need access to IMS.
• Leaving the even site and still having access is not great, but it's not the end of the world; you had legitimate access. After the event, I change which positions have access, and turn off use of the on-site flag, which addresses this.

So I don't think the on-site flag is working poorly for managing access.

What I'd like to see is a few methods for handling ACLs:

• For some roles, access should be valid at all times.
• For other roles access should be limited to during the event, if they are working that event.
• For other roles access should be limited to when they are on duty in that role.

Note that right now roles are "person" or "position" and I think "team" would be useful as well, as "Council" would be handy, and that's not a position.

For "during the event" I think we can give an event a start time and end time, though that's a bit complicated but the fact that because of NVO, we open new events very early in the year. In fact, I should create 2025 now.

[srabraham]

It sounds like on-site is still a not-so-bad solution, then?

FYI @wsanchez, we now have team-based access support: #1587
and also, note that the "requireActive" flag is now gone, as it's been moved over to being per-access entry (always vs onsite) rather than global for the server.