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
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.
During the migration from the model inhereting from a `dict` to being a
plain object it was useful to have these exceptions raised for quicker
debugging.
Now that all the code which relied on these methods has gone it’s OK
to remove them (attempts to call them will fall through to Python’s
native exception handling).
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.
The API should always return something in the JSON for a property, even
if it’s just `None`.
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).
This commit is the first step to disentangling the models from the API
clients. With the models in the same folder as the API clients it makes
it hard to import the API clients within the model without getting a
circular import.
After this commit the user API clients still has this problem, but at
least the service API client doesn’t.
