Simon Willison’s Weblog

The simplest possible call queue

6th March 2021

Originally posted to my internal blog at VaccinateCA

Today I’ve been working on the queue calling mechanism for the new Django backend.

We want to do a trial run of the system as soon as possible, so I opted to create the simplest possible version of this that could work.

The Django app is going to work a little bit different from our existing Airtable system. The Airtable system defines a number of different filtered views for locations that we want to call, and leaves it to our caller app to load in rows from those views, select a random location from the options and “lock” that location so no-one else is given it to call for at least twenty minutes.

For the new system, we’re going to switch to having an explicit “locations to call” list, which our staff can add locations to and manipulate. This will continue to evolve over time—there’s already discussion of having multiple queues, and assigning different callers to different queues depending on their status and trainining.

For the moment though, the simplest thing is to have a database table with a list of locations that need to be called in it.

I implemented the first version of this in issue 70. I’m using Django’s admin actions mechanism, which allows you to add bulk actions to the admin change list for any model.

The neat thing about admin actions is that you can apply them to multiple rows in the Django admin action interface: by clicking their checkboxes, by shift-clicking a range of checkboxes or with a “select all” option that can apply to the current page or every row that matches the current set of filters.

Combined with a rich set of filters this is a really powerful way of applying bulk actions to items in your database. The admin actions framework then provides a Django ORM queryset to your action code, which can act on it however it wants.

My first version of the code adds a new admin action for each of the “call request reasons” in the database (currently four, but more to come shortly).

Here’s an animated demo showing how the new mechanism works:

Next up: implement the /api/requestCall API that the caller app uses to fetch the next location that the user should call! #54

The Django app on Google Cloud

Alex Vandiver has done a superb job getting the Django app in a state where it can run on our Google Cloud infrastructure. Most of today’s commit activity was from Alex, and in addition to having continuous deployment running via Google Cloud Build and Cloud Run thanks to Alex we also have improvements like isort, python-dotenv and the (new to me) django-migration-linter.