Libraries Roles and Permissions Migration Plan
Libraries' roles and permission system
Base
The explicit libraries' permissions are stored in the model ContentLibraryPermission (id, library_id, user_id, groups_id, access_level)
Access levels:
ADMIN_LEVEL — Full admin permissions on the library.
AUTHOR_LEVEL — Authoring permissions (can edit/add content).
READ_LEVEL — Read-only access to the library.
NO_ACCESS — No access.
Permissions that the bridgekeeper checks:
CAN_CREATE_CONTENT_LIBRARY — Permission to create a new content library.
CAN_DELETE_THIS_CONTENT_LIBRARY — Permission to delete a specific content library.
CAN_EDIT_THIS_CONTENT_LIBRARY — Permission to edit a specific content library.
CAN_EDIT_THIS_CONTENT_LIBRARY_TEAM — Permission to edit the team (users/groups) of a specific library.
CAN_LEARN_FROM_THIS_CONTENT_LIBRARY — Permission to use library items for learning.
CAN_VIEW_THIS_CONTENT_LIBRARY — Permission to view a specific content library (including its raw assets).
CAN_VIEW_THIS_CONTENT_LIBRARY_TEAM — Permission to view the users/groups who have access to a specific content library.
References:
New roles and permissions
Library Roles and Permissions | Table of Roles and Permissions
Migration
Roles
Pre Ulmo | Post Ulmo | Notes |
|---|---|---|
ADMIN_LEVEL | Library Admin | It will maintain the same behavior. |
AUTHOR_LEVEL | Library Author | It will maintain the same behavior. |
READ_LEVEL | Library User | It will maintain the same behavior. |
NO_ACCESS | None | They won't be transformed in the new system. |
Notes:
We'll have a new role: Library Collaborator. With the MVP, you could assign this role, but it won't be migrated from the previous system.
Permissions and validations
Pre Ulmo | Post Ulmo | Notes |
|---|---|---|
Conditions: global_staff or course_creator. | The map will be create_library. | We need to add a trigger when creating a library, then assign the user the Library Admin role. Add another event when modifying course_creator… assign/revoke them to the new role Library Creator. Priority: low (we can use the current CAN_CREATE_CONTENT_LIBRARY) |
CAN_DELETE_THIS_CONTENT_LIBRARY Conditions: global staff or library admin. | The map will be delete_library. (This is used only for rest api) | We should verify whether we will use the same endpoint or utilize the authorization. Priority: medium (we can use the current CAN_DELETE_THIS_CONTENT_LIBRARY) |
Condition: global staff or library author or admin. | This will be mapped as edit_library_content (but this won't take into account collections as CAN_EDIT_THIS_CONTENT_LIBRARY) | In the old system, editing allows publishing; we are going to decouple it. Priority: high |
Conditions: global staff, attribute 'allow_public_read', explicit read permissions (admin, author, read). | Map: view_library + check the attribute in the library. | Priority: high |
CAN_LEARN_FROM_THIS_CONTENT_LIBRARY Conditions: global staff, 'allow_public_learning', 'allow_public_read', explicit read permissions (admin, author, read). | Maintain the current flow (we won't touch this) | Priority: none. |
CAN_EDIT_THIS_CONTENT_LIBRARY_TEAM Conditions: global staff or library admin. | Map: manage_library_team | Priority: high |
CAN_VIEW_THIS_CONTENT_LIBRARY_TEAM Conditions: Having CAN_EDIT_THIS_CONTENT_LIBRARY. | Map: view_library_team | We decouple the permission; editing won't imply viewing team members. Priority: high |
"“Allow public read"” | We can decide to maintain the same attribute, but in the meaning, it will be public reuse (which implies view) | Priority: high |
"“Allow public learning"” | Won't touch it. | That option lives in django admin (<domain>/admin/content_libraries/contentlibrary/<id>/change/) |
New permissions | Post Ulmo | Notes |
|---|---|---|
Manage_library_tags | By role, this permission will be the same. | Priority: high |
Manage_taxonomies | Don't touch, out of MVP. | None. |
Publish_library_content | Currently, this is managed by the CAN_EDIT_THIS_CONTENT_LIBRARY, we will have it decouple. | Priority: high |
Reuse_library_content | This controls the list that is displayed when you want to insert content from a Content Library v2 into a course. The current code for that is the LibraryRootView rest_api get method (similar to view) | Action: If someone has explicit read permissions, we should give them explicit reusability permissions. We should create a different endpoint in edx-platform to have a different filter for use libraries. Priority: high |
Create_library_collection | Previously, this was part of the can_edit_this_content_library; now, we are decoupling it. Action: Modify the rest_api/collections to add our enforcer and use the new schema (not edit_library but create_collections, edit_collections, delete_collections) | Priority: high |
Edit_library_collection | Previously, this was part of the can_edit_this_content_library; now, we are decoupling it. Action: Modify the rest_api/collections to add our enforcer and use the new schema (not edit_library but create_collections, edit_collections, delete_collections) | Priority: high |
Delete_library_collection | Previously, this was part of the can_edit_this_content_library; now, we are decoupling it. Action: Modify the rest_api/collections to add our enforcer and use the new schema (not edit_library but create_collections, edit_collections, delete_collections) | Priority: high |
Notes:
X
Y
References:
Q&A (Migration plan)
After the script migrates the existing permissions, what'll be the use of the old permission tables? would the data just stay there unused for historical reasons? or will there still be code paths that may access it?
For a transitional phase (Ulmo release), I was thinking of checking: 'you have permission in the new system' or 'you have permissions in the old one' in the enforcement points. If we do that, we'll still use the table for checking the old permissions. And then, after the transitional phase, we should remove the old permission table, as we won't need it since we'll modify all the code paths that may access it.
What happens if someone edits the old permissions? will there be a live sync process? or will these changes be just ignored?
We are not going to sync the old and new roles; only the migration process will occur.
For cases as "Library Creator", we won't sync them with course_creator roles, only verify the conditions with the new system.
And for other roles, the user interface available will be the one that uses the new system (the only place where we could edit the roles for the previous system is the Django Admin, and we won't perform the sync).
What happens if there are cases where the new authz approach doesn't map 1:1 to the old one? will both permission validations coexist for a while? (like check_new_authz() or check_old_authz())
Yes, the idea is that both permissions coexist for a while.
The roles map almost 1:1 (we have a new role), but for permissions, we have more granularity.