It feels like a solid reckon that knowing what’s in a folder before you
click on it will help you navigate around.
However, what do you show in a folder if you’re filtering by template
type? We think that:
- if you’re not filtering you should see all folders, even empty ones
- if you’re filtering you should only see folders that will get you to
relevant templates
This matches what happens when you filter templates, we don’t ‘grey out’
the non-email templates, we hide them completely.
The logic then extends to how we describe the contents of a folder, ie
we won’t count its subfolders if they don’t contain templates of the
type we’re looking for. This means that however you see the folder
described (eg ‘3 templates, 1 folder’) will match what you see when you
click into it.
Having this stuff split across various points in `conftest.py` was
making my brain melt.
This way I feel like it’s easier to see the input/output of the test.
A folder is relevant if it, or any of its descents contain a template of
the kind you’re looking for.
If you’re not filtering by template type then you should see all
folders.
This commit extends the tests to not only look at the name of the
displayed templates and folders, but also the hint text underneath.
Because there are going to be more variations of this hint text in the
future we need to make sure it’s tested.
Doing this in its own commit so only the meaningful changes show up in
the commits that actually change stuff.
- Add a GET / POST view: manage template folder
- Add a template for that view, where a user can rename their
folder
- Add an API client method for updating a folder
- Test the new feature, including the test that service without
permissions cannot manage a folder
Follows what we’re doing with the folders stuff. Avoids having too many
very straightforward methods on the model. Especially when the data they
need is only used by the form. So it’s better to encapsulate the logic
in the form.
Currently the order of API keys seems to be non-deterministic:
d46caa184e/app/dao/api_key_dao.py (L32-L39)
Generally we sort things alphabetically, unless there’s a good reason to
do otherwise.
This commit sorts the API keys alphabetically.
It’s redundant to make two API calls here, one to get all keys and one
to get a single key. Since the API calls are sequential we can speed
things up by getting the one key from the list of all keys.
Currently, a user can select a reply-to email address or text message
sender when uploading a CSV file but this is ignored and the default is
always used instead. As a first step towards changing this, this adds
the sender_id (if selected) to the S3 metadata so that this information
can be used when processing the job.
If the browser posts the value of `<input value='None'>` to the server
it does so as a string.
We want to post a value of `None` (actually JSON `null`) to the API. To
do this we:
- set the value in the form class to `'None'` (ie a string)
- convert to `None` (as a type) afterwards
However seeing `x = 'None'` in code looks a bit like a mistake. So to
make sure it looks deliberate and clear what is happening this commit:
- makes a reusable constant for `'None'`
- adds a comment explaining why it’s a string
This commit adds logic to:
- take the list of selected folders and templates
- split it into two lists (of folders and templates)
- `POST` that data to the API, to effect the movement of said folders
and templates
I’ve tried to architect it in such a way that we can easily add more
template ‘operations’ in the future, as we add more forms to the choose
template page.
This commit adds:
- checkboxes to let you select a template or folder
- radio buttons to let you select where to move those template(s) and/or
folder(s) to
It only does the `get` part of this work; handling the `post` and
calling API will be done in a subsequent commit.
This has two advantages:
- less logic in the view
- lets us filer the available navigation by which channels (email, text
letter) a service has available
We’re going to need a way to find out if, for a given ID:
1. its a template or a folder
2. if it belongs to a given service
To do 2., we can make a set of all the IDs, to see if a given ID is a
member of that set.
To do 1. we can make two sets, one for templates and one for folders.
The natural home for these sets is on the service model.
It would be quite easy to dissociate the search box from the things its
supposed to be searching.
This commit adds assertions to make sure that the things the search box
is targeting are on the page
