restrict signature input by time

[bjmllr]

Basically, we build every Tuesday through Saturday, 7:45 am to 4 pm.

The org would like the ability to restrict volunteer sign-in and sign-out to specified time ranges.

[pat]

Just while I'm glancing at this and thinking through things a little:

• Are volunteers forced to check-in within ranges, but can check-out anytime they like?
• Or, should volunteers be automatically signed out at the end of the time range?
• Should there be any allowance for exceptions to the time range rules?

[bjmllr]

I think automatic check-out would run afoul of the grant requirements since we can't automatically collect a check-out signature. Maybe we can send an email to the volunteer asking them to please sign out in addition to the Hotel California rule.

[leesharma]

Is this still a desired feature?

If so, it sounds like this is what we need–let me know if I'm off at all:

• Admins should be able to set a time range for checkins and checkouts in the admin interface (with some reasonable default)
• Outside of the time range, volunteers shouldn't see the "invalid" options on the drop down list (decided from the time selector, I assume, not the current time)
• Send an email to volunteers who check in but don't check out

Anything else?

[glazomaniac]

Those are definitely desired features, especially the last one.

[crawfoal]

When the volunteers are selecting a time, they get a widget to select the time with. This widget is from lolliclock, and it looks like an actual clock, not a list. From what I've seen looking at the documentation and code, there isn't a built in way to make invalid options look and behave disabled. I think we could either use a different time picker that uses lists, or we could write js and css to make times outside of the admin set range look and behave disabled.

For that first option, we could use something like the one from pickadate. I think different fields would be needed for hours and minutes, unless there's a good interval to show for the available times that doesn't make the list too long.

For the second option, we could use some css to make hours & minutes outside of this range look disabled (transparent/lighter), and then write some js to ignore clicks/touches outside of the approved range.

Is there a preference for one of these options over the other, or another suggestion?

[bjmllr]

I think this issue requires server side validation, but these are good points, we can improve the UX by also giving indications in the UI of what inputs will pass validation.

@glazomaniac is there an interval that makes sense to use? Do we expect volunteers to give exact (down to the minute) times, or do we expect them to round to (for example) the nearest half-hour? The second link in @crawfoal 's comment has a demo of a time picker configured for half-hours.

@jenpen might have some ideas on how to work with the current pickers.

[glazomaniac]

I'm not sure what the grant requires (and apparently, no one is?). Specificity is probably useful, but if intervals are easier for y'all, I'd go with 15 minute ones if at all possible. Thanks for all y'all's work on this!

[crawfoal]

I can get started on this if the following tasks sounds good to everyone:

• create a "settings" page in the admin tools area so that admins can set limits for signing in and out (defaults to 7am - 5pm to give them a little wiggle room from what they said - 7:45am to 4pm)
• for the shift events model, add a validation to the occured_at attribute based on admin's settings
• change the time picker to TimePicki (easy to limit selectable times, has separate hour and minute fields which is more usable for larger time ranges than a single field)

I believe that the email reminder has already been implemented.

[bjmllr]

@crawfoal sounds great!

That breakdown of the tasks makes sense to me. I'd suggest doing each task in a separate commit if possible, or even separate PRs.

Since there's default behavior, it should be possible get the validation and picker working before adding the admin page, if you want. That approach might require some rework at the end, but I'd guess the user-defined intervals will add complexity to the other tasks.

I believe that the email reminder has already been implemented.

Yes, in #125.