Story
"As a content author, I want to update the tags applied to my content."
This is a follow-up to the generic version of #82
Description
- Implement a REST API in Studio that allows users to update the list of tags applied to a given object.
Add automated tests which check that this works and which check that these permissions are enforced:
- A user can only view the tags of objects (courses, blocks, units) that they can view in Studio. (And of those tags, they can only see the tags of enabled taxonomies, unless they're a taxonomy admin.)
- If a user does not have permission to view an object (course, block, or unit) in Studio, they will not be able to view the tags that are applied to that object. (Neither using the Studio "content tag" API nor the base oel_tagging API, if they are different)
- A user can only create/update/delete the tags of objects (courses, blocks, units) that they can view in Studio. (And of those tags, they can only edit the tags of enabled taxonomies, unless they're a taxonomy admin.)
- If a user does not have permission to edit an object (course, block, or unit) in Studio, they will not be able to edit the tags that are applied to that object. (Neither using the Studio "content tag" API nor the base oel_tagging API, if they are different)
Implementation Notes
When the views/rules enforce permissions, they should use general checks like has_studio_write_access - do not check for specific roles like "staff" or "instructor" or "TA" in the course, because the roles may change at any time. However, it is OK for the test code to use such roles when provisioning test users to try accessing the content.
Story
"As a content author, I want to update the tags applied to my content."
This is a follow-up to the generic version of #82
Description
Add automated tests which check that this works and which check that these permissions are enforced:
Implementation Notes
When the views/rules enforce permissions, they should use general checks like
has_studio_write_access- do not check for specific roles like "staff" or "instructor" or "TA" in the course, because the roles may change at any time. However, it is OK for the test code to use such roles when provisioning test users to try accessing the content.