The template list wasn’t getting the right class applied because the
check was referring to an undefined variable (`can_manage_folders`) that
should have been removed when all other references to it were.
Sometimes, when filtering the view by template type, the message was
saying the folder was empty, when really it should have been saying that
there were no templates of the ‘type’ you’re looking for, eg:
> There are no email templates in this folder
This was because it was looking at the filtered list of templates, not
all templates to determine whether a folder was really empty.
It’s a bit rudimentary to only show the current place in the hierarchy
and the parent. You lose a sense of how deep you are.
But we can’t just show the full path, because it can be arbitrarily
long. So what this commit does is show the full path, but truncates the
display of any items. Further-up than the current folder or its parent.
This also helps disambiguate between folders and templates, because
folders are always shown with the folder icon.
This probably won’t affect many teams, because we don’t anticipate a lot
of deep nesting.
We already have a pattern for navigation folders and searching for
templates – let’s use it for the copy page too. And I reckon we can
represent services as folders if the user has multiple services they
could copy a template from.
Updated the move folder form to add a hint for the radio button for the
current folder saying 'current folder'. This hint does not get shown if
you are viewing all folders (so you are not inside a folder).
Also stopped a default radio button from being selected on the form.
so that they better align with the front-end, where they'll be used in
data attributes. Also, making the kebab case is nice because it doesn't
give favouritism to either JS or python naming conventions
WTForms coerces `None` as a choice to `'None'` as a string when
rendering form fields (form fields will only ever have string data
because that what the browser posts back).
But internally WTForms coerces `None` to mean an unset value, ie where
the user hasn’t selected a radio button:
283b280320/src/wtforms/utils.py (L1-L20)
We shouldn’t use `None` to mean two different things. And in fact we
can’t, because it in effect means that we’re always getting a value
for the `move_to` field, even if the user hasn’t chosen to move any
templates. Which results in some very expected behaviour.
Since we’re letting users add new folders directly from the choose page
it makes sense that they should also be able to add templates from
there.
This resolves the problem we saw in user research where people found it
hard to know where to go to add a new folder when they were all behind
one green button.
Since you can now see them when searching you should also be able to
select and move them. Which means that they needed to be included in
the `Form`’s list of possible choices of things to move.
If you have a folder structure like this:
> FA / FB / FC
and you search for ‘FA’, it’s very noisy to see:
> FA / FB
> FA / FB / T1
> FA / FB / T2
> FA / FB / FC
> FA / FB / FC / T3
> …
It’s clearer to just show:
> FA / FB
This also has the benefit of, if you type ‘template’ (for example) you
don’t get every item any more, because it’s only looking at the name of
the thing. It used to look at the entire description, ie:
> A / B / C / Example
> Text message template
Now it only searches on the name:
> A / B / C / *Example*
> Text message template
Things in subfolders need to be in the page so we can search for them.
But the default view should be only the things are the current level.
So we can use CSS to hide items that are below the current level.
So that the live search can filter things, they need to be on the page
when it loads. We want to make search work across folders, so all the
things in subfolders need to be in the page.
They also need the full path appending to them, so that you can tell
which ones are in which folders.
This won’t show items that are in a folder above the one you’re
currently in – my reckon is that when you’re narrowing down by clicking
into a folder that you only want to search for things in that folder.
The Jinja template for the ‘choose templates’ page is now pulling in
data from a lot of diparate places in order to work out what to show. As
we add more logic about what to show (in order to make the live search
work) it’s going to get harder to have all this logic in the Jinja
template.
This commit refactors it back into Python where we have more language
features for managing complex logic.
It’s a bit weird to call this file a model, in that it’s dealing with
some presentational logic, rather than just data. Conceptually it’s more
like a view model[1].
1. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
If the folder is completely empty, always say ‘This folder is empty’, so
we don’t suggest that you can click around and find other things.
If the current view is filtered, but there are templates available in
other filters, say ‘There are no text message templates in this folder’
to make it clear why you can’t see anything.
Currently if there’s nothing in a folder you just get an empty page.
This looks a bit broken, or like the page hasn’t finished loading.
This commit adds a message to the page to show that it’s intentionally
blank.
The message is contextual based on type of template, because there might
be templates in the current folder, even if you can’t see them at the
moment (because you’re filtering).
It’s weird that this page changes when you click delete – it looks like
you’re going to a different page.
It should feel like you’re on the same page, just with the confirmation
message.
The problem we had before is that the rename form would `POST` to
`…/delete`, which would then delete the template instead of updating
its name.
We can fix this by explicitly setting the `action` attribute on the
rename form to always post to `…/manage`, even if the user is currently
looking at the `…/delete` page.
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).
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.
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
