Meeting Notes 20200804

We took a little time to get back up to speed (again). It felt like we did understand the data model we'd come up with previously though and have filled in the test data so we will continue with that and with the issues we've created already.

Chris suggested that we switch to having an API server and a separate server for the web pages so we're going to go with that.

We pulled out the user stories for the resource booking part:

Resource booking As a user, I want to be able to book a hotdesk. As a user, I want to be able to book a room for a meeting or event. As a user, I want to be able to book a laser-induction. As a user, I want to be able to book time on the CNC and laser machines. As an organiser, I want people to be able to book rooms by the hour but machines by the half-day. As a potential hotdesker, I want to be able to book a hotdesk without having to set up an account/password. As a user, I want to be able to pre-book to hot desk or use a machine and pay by cash when I arrive

Infrastructure Notes Three components: an API server; a web server (which calls the API server and generates server-side HTML); client-side code (which can also call the API server to update things interactively) Client-side code will be jQuery based (at least until our needs become such that implementing a React system makes sense)

If a resource has min_length or max_length then this means there are no slot rules. Alternatively we could query for slot rules first and fall back on min/max length, we might want to make this call during implementation as right now it doesn't seem obvious that either way would be better.

Slot rules should be in the database, and is a many-to-many relationship to resources, because we're likely to share slot rules between laser-cutters and desks (for example)