Backend - Operator Admin Page - Determining which riders and drivers are signed up through an organization.

[stephenscapelliti]

Considering the functionality of the New Operator Admin Page:

I am a rider or volunteer driver who has signed up on carpoolvote.com, despite the warning that "CARPOOL VOTE IS NOT CURRENTLY TAKING SIGNUPS". I might have signed up by visiting the website and ignoring the warning, or I might have signed up through an org.

• Although the driver list includes an "Org" column, it is not evident whether the driver (or rider) has signed up through an org.

• We cannot determine whether a rider or driver has signed up independently or through an organization. For future use of the site, will the inclusion of an org identifier be mandatory for the org to use the service?

• If a rider or driver currently on the list has signed up through an org, notifying him/her/them that the site was not reliably operational at the time of their sign-up could unintentionally interfere with an otherwise correctly-arranged match by an org. How can we best alert a rider or driver who signed up prior to the change to org-facing of that fact? Should we alert them? Consider that one goal of making CarpoolAction org-facing was to put responsibility for contacting riders and drivers on the participating orgs and not on ProgCode/CarpoolAction staff.

• Currently, the driver list available through the Operator Admin Page indicates "Status" for the volunteered ride (i.e., Pending or Expired), but it does not state the date of the ride.

[jkbits1]

@stephenscapelliti thanks all good points - final item is addressed by #384

[jkbits1]

@stephenscapelliti again thinking aloud while writing so bear that in mind, but don't hold back on comments either!

At the moment, the system doesn't really include the concept of "signed up through an org" so that concept needs to be addressed somehow first. I've been wondering how an offer/rider request will be recorded as part of an organisation since the revised structure based around operators was proposed.

New bulk input methods (as in #385) can be designed to support this. However, it's not clear to me if the operator approach is only planned to work using bulk input.

There seems some benefit to continue to support individual input of ride requests/offers. For one off entries, it may be easier than the bulk update process. It also allows individuals to help out.

So handling "attaching" an org to an individual entry - here are a couple of ideas.

The very simplest approach, for if we just have the one organisation, is to have a default value for the org set automatically. However, although it's easy, we don't really gain much from doing that (and potentially increase confusion).

The next idea, which isn't that hard to do, and allows for correct data (barring data input mistakes) is to have an "organisation" drop-down on the driver/rider front-ends. The individual could choose the org (and some option for none). This is quite tempting as we get all the correct info for a small effort, barring typos.

The third option is to make it possible on the operator page to set an org for a driver or rider. This is perfectly possible, but a little more work to implement technically. This does handle all situations.

Maybe some mix of the above would work best. Do we have any concrete thoughts on this from the operators?

[jkbits1]

@stephenscapelliti your third point, about notifications, is good but tricky! Maybe we should address this after some of the other points are decided on? If so, maybe it should be a separate issue so it doesn't get forgotten

[jkbits1]

@stephenscapelliti if we want, we can keep this issue open as a discussion area. Or, we could consider it closed due to recent functionality that's been added. Any thoughts?