There is some leftover endpoints from very early experiments with using the API for team components, but almost none of them are compatible with the default syntax for the REST API, which causes confusion, especially with the new landing page for the root endpoint (see #110).
We haven't considered this functionality recently, and there does seem to be strong use case for admins of existing installations to set up their teams with the API. So this should also implement a minimum viable product for such an operation.
For now, lets clean up the existing existing endpoints and implement the following:
[x] Read flavored (read, search) operations for teams that return all team elements except roles (resource, templates, users, assets, sites)
[x] Search for resources team-resources that will facilitate searching for all resources in teams and all teams that a resource belongs to
[x] Adding/removing a resource to a team
[ ] Adding/removing a template to a team
[ ] Adding/removing an asset to a team
This will exclude team users, team sites and roles as those are less likely to be bulk operations.
There is some leftover endpoints from very early experiments with using the API for team components, but almost none of them are compatible with the default syntax for the REST API, which causes confusion, especially with the new landing page for the root endpoint (see #110).
We haven't considered this functionality recently, and there does seem to be strong use case for admins of existing installations to set up their teams with the API. So this should also implement a minimum viable product for such an operation.
For now, lets clean up the existing existing endpoints and implement the following:
This will exclude team users, team sites and roles as those are less likely to be bulk operations.