votingworks / arlo

GNU Affero General Public License v3.0
143 stars 26 forks source link

Endpoints for audit board flow #118

Open MorganLove opened 5 years ago

MorganLove commented 5 years ago

GET/POST Edit/Create an audit board member endpoint GET Audit board status endpoint POST/GET Ballot endpoint POST Audit board sign off endpoint POST Get correlated url from human readable token

Also need to update the uuid generation for elections to be human-readable, and update the POST to /election/{electionId}/audit/jurisdictions to take only an array of strings (for the audit board names) and return the full object with human-readable uuids, the names, and empty member arrays.

Or we need to update the jurisdictions POST endpoint to either accept human readable tokens and/or uuids, or have either or both of those generated on the back end and returned in the jurisdictions array.

MorganLove commented 5 years ago

@benadida If we are redirecting from a human readable url like /auditboard/blue-elephant-spring to the actual url like /election/{uuid}/board/{uuid} we need to store those correlations in the database. And so we'd need to either generate them on the front end and pass it back when creating audit boards, or have them generated on the back end and returned in the jurisdictions array. And also we'll need to have an endpoint for getting the correlated /election/{uuid}/board/{uuid} url from POSTing a blue-elephant-spring type of token when someone navigates to /auditboard/{human_token}.

(List in original issue updated.)

MorganLove commented 5 years ago

@benadida I found a library that could generate these sorts of human readable uuids: https://github.com/linus/greg

Here is a port of it for python: https://gist.github.com/prschmid/4447660

Ideally, in order to guarantee that we do not have duplicates issued, they should be generated on the server side and checked to make sure they are unique in the database before being sent to the front end, just in case.

benadida commented 5 years ago

Cool, thanks for these pointers @MorganLove. I don't think we should try to make all of our UUIDs human-readable. That will make them much longer than we strictly need them to be for the purposes of someone typing them in.

Agree that we'll need some work on the backend to store and retrieve the human-readable tokens to UUID correspondences.