[Tagging] Permissions for Taxonomies List Page and Taxonomy Detail Page

[bradenmacdonald]

Acceptance Criteria

1. Make sure that the tagging system enforces all of the following permissions. Make changes to openedx_tagging and content_tagging as needed if some of these permissions aren't yet implemented correctly.
2. Write tests to cover these if they are not yet tested. As much as possible the tests should use these same strings (see example below).

Who can view taxonomies:

includes seeing all tags and metadata. Does not necessarily allow the user to view ObjectTags using the taxonomy though.

1. Users who are global staff can see all taxonomies (enabled and disabled)
2. Users who are org-level admins (OrgStaffRole) can see all taxonomies that are linked to their organization (enabled and disabled).
3. Any user with access to Studio can see enabled taxonomies that are part of “all orgs”.
4. Only global staff ("instance-level admins") can see non-system taxonomies that are not linked to any organization yet.
5. Users who are not global staff ("instance-level admins") or org-level staff ("org-level admins") cannot see any disabled taxonomies.
6. Users with other org-level roles (OrgInstructorRole, OrgContentCreatorRole, or OrgLibraryUserRole) can see any of that org's enabled taxonomies.
7. Users who are instructors for any course (via CourseStaffRole or CourseInstructorRole) belonging to an org can see that org’s enabled taxonomies.
8. Users who can view any v2 content libraries belonging to an org (CAN_VIEW_THIS_CONTENT_LIBRARY) can view that org's enabled taxonomies.

This applies to the Taxonomies List Page as well as the Taxonomy Detail Page, though it must be implemented on the backend, not the frontend.

Who can export taxonomies

11. Any user who can view a taxonomy can export it.
12. Users who cannot view a taxonomy cannot export it.

Who can edit taxonomies:

13. For MVP, only global staff ("instance-level superusers") can do the following in general. As well, org-level admins (OrgStaffRole) can do the following for taxonomies that are linked to their org:
    • import a taxonomy
    • enable/disable a taxonomy
    • edit a taxonomy's metadata
    • edit a taxonomy's tags
    • upload a new version of a taxonomy with different tags
    • delete a taxonomy
    • assign a taxonomy to organizations (global staff only)
14. If an org-level admin imports or creates a taxonomy, it is automatically linked to their org.
15. No users are allowed to edit system-defined taxonomies.

Who can view ObjectTags

16. Any user who can view a content object (unit, component, or library component) in Studio can view that content object's tags.
17. Any user who can not view a content object (unit, component, or library component) in Studio can not view that content object's tags.

Because of how the taxonomy permissions are defined, we don't really need to check if the user has permission to view the Taxonomy. Generally if the user can see the object, they'll be able to see the associated taxonomies. In the future we may extend these permissions to say that you can only view an ObjectTag if you can view the content object and you can view the taxonomy, but for now we only need to check the content object.

Who can edit ObjectTags

18. Any user who can edit a content object (unit, component, or library component) in Studio can edit that content object's tags.
19. Any user who can not edit a content object (unit, component, or library component) in Studio can not edit that content object's tags.

Developer Notes

• These should all be implemented as separate permissions ("can view this taxonomy", "can import a new taxonomy", "can enable/disable this taxonomy") and then use rules to define who has that permission. Do not directly check "roles" in the API - check permissions which are defined by rules which in turn check roles.
• The can_export_taxonomy permission should be defined as equal to the can_view_taxonomy permission.
• As much as possible, permission tests in edx-platform should be clearly written using docstrings that are identical to the acceptance criteria above. e.g.

  def test_global_staff_see_all(self):
      """
      Users who are global staff can see all taxonomies (enabled and disabled)
      """
      ... # test the "list taxonomies" API and the "get taxonomy details" API

[ali-hugo]

@jmakowski1123 Would you review this ticket's description when you get the chance please? I think you and Jill discussed permissions in some depth.

[ali-hugo]

@bradenmacdonald I've asked Jenna to review this ticket as she is more up to speed on the permissions as I am. For what it's worth, everything outlined in "Acceptance Criteria" matches my understanding.

Question for product: Is everything here correct? In particular: can anyone who can view a taxonomy export it, or only global staff can export?

I agree with your point on #105 i.e. that if a user can view a taxonomy, they should be able to export/download it.

[jmakowski1123]

1. Editing permissions:
   For MVP, only global staff ("instance-level superusers") can:
   import a taxonomy
   enable/disable a taxonomy
   edit a taxonomy's metadata
   edit a taxonomy's tags
   upload a new version of a taxonomy with different tags
   delete a taxonomy
   assign a taxonomy to organizations

Does this cover the use case of: I'm an org-level administrator for HarvardX on edX.org and I want to import a taxonomy for HarvardX. Because I'm just part of HarvardX and not edX.org staff, I only have access to HarvardX on the edX.org platform. ...? In other words, are instance-level superusers/global staff equal to org-level admins?

In the context of the new R&P framework edX is working on, the "Org Admin" should also have all editing permissions for taxonomies, right @bryan-kersten? However this role doesn't exist yet, so how does the HarvardX use case above work in practice in the interim? https://docs.google.com/spreadsheets/d/1htsV0eWq5-y96DZ5A245ukfZ4_qeH0KjHVaOyfqD8OA/edit#gid=908503896

2. Import/export: For MVP, I'm inclined to say the permissions for exporting equal the permissions for importing, since the main/only reason a taxonomy will be exported will be to update it, which is a process limited to admins. We don't want course authors doing that.

[bradenmacdonald]

@jmakowski1123 My understanding was that for MVP only global admins (not org admins) would be editing.

In other words, for MVP, if a HarvardX admin wanted to import a new taxonomy, they'd have to ask an edx.org admin to import it for them and link it to HarvardX.

If we need to include org-level admins as editors though it's no problem - but that's not what's shown in the mockups.

However this role doesn't exist yet

I'm surprised it says that because the existing OrgStaffRole is an org-level admin role as far as I know - it lets you view and edit all courses and enrollments and learner activity for the whole org.

[bradenmacdonald]

@jmakowski1123 For (2) I think there are other reasons an instructor may wish to download (export) a taxonomy besides editing it and re-uploading it. For example, they may wish to upload the taxonomy to a sandbox or another Open edX instance where they are an admin, or write some scripts that use the taxonomy to tag their content automatically, or train some machine learning models, or other advanced usage like that. However, for MVP we can certainly just say "you can export if you can import" if you want, instead of "you can export if you can view". Either way is just as simple from a technical perspective.

The only thing is I think we talked about letting users export system-defined taxonomies, for advanced use cases like I mentioned, and it doesn't make sense to allow that in this case, since they cannot be imported.

[bradenmacdonald]

After discussing this with @jmakowski1123 I have updated it: org-level admins will have broad editing abilities just like global staff, but within their own org. And export perms will be the same as view perms, for the benefit of power users that want to use scripts to manipulate taxonomies or content.