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.
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.
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.
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.
This means we can have a method on the service model which hits the API
(or Redis) but can be called multiple times (within the context of a
request) without making multiple network requests.
It does this by storing the results of the method on the object’s
internal `__dict__` the first time the method is called.
Inheriting from `dict` has some unexpected side effects that don’t
happen with plain object. The one we want to avoid right now is that
a dict doesn’t seem to implement `__dict__` in a normal way, which
is required by `werkzeug.utils.cached_property`.
