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.
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
We reckon it’s jarring to have the search box appear and disappear as
you navigate through the folders.
Instead it should appear whenever your service has more things
(templates or folders) than you can easily keep in your head (let’s go
with 7 for now).
This keeps the bahviour the same for current services that don’t have
any folders.
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.
The search box should only be shown if there are too many items to
quickly scan on the page. This number is judged to be 7; see the
original PR for more context:
https://github.com/alphagov/notifications-admin/pull/1195
This commit makes that logic work in the world of folders, by explicitly
counting the templates shown on the screen, not all the templates a
service has (which may be spread across multiple folders).
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.
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.
In multiple user research sessions we’ve noticed people edit the
auto-generated template name to put something at the end of it.
This is fiddly because of the quotes we put around the name:
> Copy of ‘Exiting template’
It also means that if they keep our prefix then the template doesn’t
sort alongside the one it’s replacing.
This commit changes the name of copied templates to better match the
behaviour our users are showing.
Also adds a bit of auto numbering, just as a nice detail.
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
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
When adding a new folder it is created inside the currently active
one. The user is returned to the previously active folder page,
which shows the added folder.
This adds a new route to the add template/folder views. Thankfully,
`url_for` recognizes when `template_folder_id` is `None` and will use
the URL without `/folders/...`, so users without folder permissions
should be unaffected by this change.
Clicking on template folder navigates to a page that displays that
folder's contents.
This reuses the existing choose template view by adding a filter
based on optional `template_folder_id` argument.
Service model methods are rewritten to match `all_templates` and
`get_template`. New `get_template_folder_path` method returns a
list of folders (from root to the current one) that the selected
folder is nested inside.
With the addition of template folders we need to filter templates
based on a combination of type and parent folder ID.
This replaces the existing `templates_by_type` method with
`get_templates`, which supports both type and parent folder filters,
avoiding a need to create specific methods for each use case.
We still need the templates property to exist in some way in order
to cache it, but it needs to be clear that it's different from
`.get_templates`. One option was to make it "private" (i.e. `_templates`),
and always use `.get_templates` in the rest of the code, but this requires
adding "include all folders" to `.get_templates`, which doesn't have an
obvious interface since `parent_folder_id=None` already means "top-level
only".
This will probably come up again when we need to look into adding
templates from nested folders into the page for live search, but
for now renaming `Service.templates` to `.all_templates` makes it
clear what the property contains.
The add new templates page now has option to add template folders.
Tweaked wording of other options and h1 to clarify options since it's
not all about templates any more.
Added api client and stuff for it
The view here is rebuilding a pseudo-service object. Now that service
objects have templates it’s cleaner to use the actual service object.
Requires a small change to the `templates_by_type` method so that it can
filter by one or many template types (a user should be able to copy any
template whose type is enabled for their service, and the service
they’re copying from).
Making people use a property is a sure way to make sure they’re spelling
the name of the property correctly, and allows us to easily swap out
properties that call through to the underlying JSON, and properties
which are implemented as methods.
We do a lot of logic around choosing which templates to show. This logic
is all inside one view method.
It makes it cleaner to break this logic up into functions. But this
would mean passing around variables from one function to another.
Putting these methods onto a class (the service model) means that
there’s a place to store this data (rather than having to pass it around
a lot).
Making this code more manageable is important so that when we have
templates and folders it’s easy to encapsulate the logic around
combining the two.
If you skip past the templates page (because you don’t have the edit
permission) but then click back you end up in a loop which redirects you
to the page you’re already on.
This commit makes sure that you’re sent back a step further, so you
don’t get stuck in that loop.
We were taking letters away from basic view because there’s no one-off
sending of letters.
But now that basic view isn’t an opt-in thing but something we’re
rolling out to all users who only have the ‘send’ permission it feels
like too drastic a change to remove letters.
It’s too jarring to go straight from the list of templates to the upload
addresses page. So while we don’t have sending a one-off letter as a
thing, let’s keep the template page.
We’re going to make it possible for some users to be members of a
service, but not have any permissions (not even `view_activity`).
There are some pages that these users should still be able to see
These are the pages that a user with ‘basic view’ would have been able
to see, excluding those that let them send messages.
If you only send messages then there’s no longer much point in the
template page. It now, for you, only has one action – ‘Send’.
This commit changes the journey for these users so they go straight from
clicking the name of the template to the page where you enter the phone
number or email address.
This is better because it reduces the number of steps a user has to
click through to send a message.
This journey is what we were previously calling ‘basic view’. But this
changes makes it automatically available to anyone who would benefit
from it. It removes the complexity of:
- having to opt in to basic view at a service level
- having to choose on a per-user basis who has basic view
- understanding the nuance between basic view and only choosing the
‘Send messages’ permission
Users who will still see the template page are:
- those who can edit templates – they need the ‘edit’ link
- users with the manage API keys permission – they need a place to get
the template ID
This is better than just keying into the JSON because it means you get
an exception straight away when looking up a key that doesn’t exist
(which via mocking you could ordinarily miss).
