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.
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
When you land on the page it’s good to be able to quickly see what the
currently-set value is, before you change it.
This is unnecessarily hard if the selected item is buried half way down
the page. This commit moves it to the top.
Currently the brandings have non-deterministic sorting, which means
the order changes from page load to page load. This makes it hard to
find the item you’re looking for.
This commit sorts them by the name of the branding, same as for email
brandings.
WTForms lets you pre-populate a form’s value by passing it in as an
argument to the constructor.
This will be good for us because it will let us access that value in
the constructor later on.
These helper functions for modifying a service permission were just
floating around loose in the view code.
A much better home for them is on the model. This will also make it
easy to reuse them in other views if we ever need to.
We have a lot of places in settings where we update something by passing
in the `service_id`. `current_service` already knows about `service_id`,
so it’s cleaner to encapsulate these updates inside the model.
