volunteer pages

[mwellman17]

Draft.

Adds a landing page for volunteers at /volunteer
TODO: known volunteers can authenticate with an API key, optionally saves cookie for future use
Q.) Will each volunteer have their own unique API key?
Q.) If yes, should each volunteer see only specific sites they are assigned on the updater form ?

Adds a site updater form at /volunteer/updater (pictures below)
TODO: package form input for API consumption
Q.) If dates or availability is unknown, how should the UI send either websites or contact info? Should there be a generic text input for those kinds of unknowns?

Q.) What other forms or resources should be added for volunteers?
Q.) Should there be an admin page here for managing volunteers?

[mzagaja]

A few thoughts:

Q.) Will each volunteer have their own unique API key?

I think it makes sense to give each volunteer in the volunteers table their own password or "key". From a user perspective is this passed as a URL param or similar?

Q.) If yes, should each volunteer see only specific sites they are assigned on the updater form ?

I think it makes sense to make them all available in a first iteration, to simplify both the data structure and also to allow volunteers to update extra sites if they have bandwidth, but would defer to @madeleine-b on this.

Q.) If dates or availability is unknown, how should the UI send either websites or contact info? Should there be a generic text input for those kinds of unknowns?

A good question for the front-end team. @WheresHJ @madeleine-b, or @hblumberg can probably provide some good direction on this.

Q.) Should there be an admin page here for managing volunteers?

Let's defer adding an "admin interface" into a separate pull request. I think we should aim to ship the volunteer/user facing component first so we can test it, and separately you or someone else can work on the admin interface task.

Q.) What other forms or resources should be added for volunteers?

Also will let front-end team weigh in on this. I'm hoping I can find time to focus on this PR tomorrow night so we can try and ship the first iteration. I know it might need some love/work from the database perspective as well. Specifically we need to confirm:

1. Production database is designated, updated with latest data, and no longer being used by others when they "test". Folks should be testing against a local database. I usually use pg_dump to copy production to my local machine, but we can also make a remote vaccinatema_development DB if it helps folks.
2. Once we get a version of this on staging, we should work with the site checking team to test/validate.

[mwellman17]

@mzagaja I got most of that answered in a conversation with Madeleine last week.

I'd like to get this onto staging soon, then I can break up Madeleine's notes to a few trello cards and get this ready to test. I've been adding to this branch slowly over the last three weeks so I apologize for the large size of this pull request.

[mzagaja]

@mwellman17 Sounds like a good plan to me! Just wanted to make sure we weren't neglecting your questions :).

[mwellman17]

Still work to be done here, but if we can get this PR into main the remaining changes can be incremental

[mzagaja]

Is there a way to review functionality when the auth part is not yet working? I would say the route loads fine, but then I'm blocked from further review by the auth requirement. It seems like the auth part is also going to need an update to the database and dbschema.sql which defines the state of a fresh working database.

I would suggest just finishing up the small amount that seems to be left of the auth prototype and then let's land this and poke at it.

[mwellman17]

Is there a way to review functionality when the auth part is not yet working?

Oh yeah there is. That would be super helpful, my bad for not mentioning it.

Since auth isn't set up I'm using the get volunteer by email route, so as long as you enter the email of a volunteer in the system you can log in for now.

Admin email: lisa@test.com
Volunteer email: bart@test.com

[mzagaja]

Ready to merge!