This makes the display of folders in the `<h1>` look like the prototype.
It alters the behaviour we’ve initially built here by only ever showing
a maximum of two levels of hierarchy (the current folders and its
parent).
If the user is looking at the notifications page for all message types
(which is what we show ‘caseworkers’) then it doesn’t make sense to ask
the API for the data retention period for that message type (because
it will be `None`). Doing so causes the API to return a `404`, which
then causes the admin app to return `404`.
Passing through `None` as the value of limit days will just cause the
API to return everything in the `notifications` table, which is fine
for us.
Some users are bookmarking the sign in page for quick access to their
Notify service.
If they’re already signed in when they used this bookmark they get
redirected. However the redirect isn’t very smart, because it just takes
them to their list of services. This isn’t great if they only have one
service.
This commit redirects them to the `show_accounts_or_dashboard` endpoint
instead, which does the work to figure out which page is most useful
to show someone when they sign in.
Also changing this for `/register`, although it’s less likely that
someone will have bookmarked this page.
Often people will be editing the existing name, not changing it
completely.
This matches what we do when someone wants to rename their template or
service.
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.
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.
- 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.
