If the new folder has a parent folder, it inherits user permissions
from its parent. Else if the new folder is at root level, all users
will have a permission to view it.
It was initialy called "rename" which does not comply with
RESTful CRUD (create, update, read, delete) naming practice.
We remove the 'rename' operation in favour of template folder
resource update endpoint as it allows us to extend it with other
attributes.
new endpoints:
/services/<service_id>/move-to-folder
/services/<service_id>/move-to-folder/<target_template_folder_id>
* takes in a dict containing lists of `templates` and `folders` uuids.
* sets parent of templates and folders to the folder specified in the
URL. Or None, if there was no id specified.
* if any template or folder has a differen service id, then the whole
update fails
* if any folder is an ancestor of the target folder, then the whole
update fails (as that would cause a cyclical folder structure).
* the whole function is wrapped in a single `transactional` decorator,
so in case of error nothing will be saved.
Currently there aren't any permission checks based on folder IDs in
the admin app or the API, so it's possible for a user to modify the
folder ID to perform operations on folders outside their service.
Our usual way to avoid this is to always use service_id filter when
fetching objects from the database.
Since template folders are only linked by ID to their parent we need
to check that the parent folder belongs to the same service as the
one being created. Otherwise, admin users could modify parent ID to
create a folder outside their service.
Ideally, this check would be performed by a DB constraint, but since
parent_id can be nullable this is only possible to express using DB
triggers.
Instead, we perform the check in the API endpoint code.
* create template folder
* rename template folder
* get list of template folders for service (not nested/presented in any
particular way)
* delete template folder
Also removed `lazy=dynamic` from the `template_folder.templates`
relationship. lazy=dynamic returns a query object (which you can then
filter further). We just want to return the entire fetched list, at
least for now.
