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.
- 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.
Original content: 'Notify complies with the Data Protection Act.'
This should be updated to take account of GDPR – for example, 'Notify complies with data protection law' (which covers both DPA and GDPR).
This change is consistent with the Service Manual.
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.
When a folder is selected the full path is displayed in page title
and header (for example `Templates / Folder1 / Folder2`). Elements
of the path link to the corresponding folder. Current folder is not
linked.
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
This replicates how we let large spreadsheets scroll horizontally.
Pro: this looks nicer and is more usable
Con: the code for this feels a bit fragile, especially the calling of
`.maintainWidth` twice, ie as many times as a it takes to get stuff to
render properly.
In trial mode you can’t send letters. But it’s still useful to be able
to build up a letter to see how it work.
Best place to put this error is before someone tries to send a letter
for real.
We didn’t used to allow this because it wasn’t really possible with the
old DVLA set up and we didn’t think there’s a need.
We think it’s possible now because, even though it’s cumbersome, it’s
better than the manual process.
There’s a lot of code in service settings which:
- talks to the API directly through the clients
- passes that information through to the Jinja template
By encapsulating this logic in the service model:
- the Jinja template can access the data directly
- the logic can be reused across multiple methods
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.
