This is the first step of replacing the `domains.yml` file.
In order to replicate the same functionality we get from the
`domains.yml` file and its associated code this commit adds a
`Organisation` model. This model copies a lot of methods from the
`AgreementInfo` class which wrapped the `domains.yml` file.
It factors out some stuff that would otherwise be duplicated between the
`Organisation` and `Service` model, in such a way that could be reused
for making other models in the future.
This commit doesn’t change other parts of the code to make use of this
new model yet – that will come in subsequent commits.
Shows a count of how many folders that user can see - this doesn't do
anything smart with parent folder stuff, it's just "how many checkboxes
are ticked on the edit page".
* doesn't show if service has no folders
* doesn't show if service hasn't got folder permissions enabled
Since we're calling `User.has_template_folder_permission` directly
in a few places (notably the `folder_path` template macro), we need
to check that the service has the feature flag enabled first. This is
usually done by the caller, but template macro doesn't have access to
`current_service`. To avoid passing it in each time the macro is called
we're adding a temporary check inside the method itself.
This commit can be reverted completely when we remove the service
feature flag.
User model is the most natural place for a permission check method,
however this means that we need to pass the full user object to
service model methods and TemplateList instead of user_id.
We were already invitializing InvitedUser with folder_permissions
(defaulting to None), but this removes the default and adds
folder_permissions to the serialize method. Folder permissions should
now always be returned from api, either as an empty list or a list of
UUIDs.
The `folder_permissions` property has no effect and is not used yet, but
it needs to be added before we add a `folder_permissions` column to the
`InvitedUser` model in notifications-api. This is because we initialize
the InvitedUser class with the response from notifications-api.
This can happen if you click a link for a service you don’t have access
to. We shouldn’t show the back to service link in this case because:
- you shouldn’t be able to find out the service’s name from just knowing
the link
- if you click the link you only get a `403` anyway
We already have a pattern for navigation folders and searching for
templates – let’s use it for the copy page too. And I reckon we can
represent services as folders if the user has multiple services they
could copy a template 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.
