Roles and permissions

Tangible LMS does not add its own WordPress roles. It layers a set of LMS capabilities on top of the roles already on the site, and grants them in two ways: by role default, and by per-user grant.

What administrators get

Any user with manage_options — administrators, by default — holds every LMS capability and every course post-type capability. There is no configuration to do and no way to partially restrict an administrator through this system.

What other roles get

Below administrator, only Editor is granted anything out of the box:

Capability	Administrator	Editor	Author	Contributor	Subscriber
Create courses	✅	✅	—	—	—
Edit courses	✅	✅	—	—	—
Preview courses	✅	✅	—	—	—
View courses	✅	✅	—	—	—
Publish courses	✅	—	—	—	—
Delete courses	✅	—	—	—	—
Manage enrollments	✅	—	—	—	—
Bypass progression	✅	—	—	—	—
Site settings	✅	—	—	—	—

Editors can build a course but not make it live

An editor can create a course, edit its outline, and preview it, but publishing a version and deleting a course stay with administrators. An editor who reports that the Publish Version button does nothing for them is running into this, not a bug.

Authors, contributors, and subscribers get no LMS capabilities from their role. They can still be learners. Enrollment and course-taking are granted per user, not by role.

The full capability list

Capability	Group	Covers
lms_create_course	Authoring	Creating new courses
lms_edit_course	Authoring	Editing courses, including others' courses
lms_publish_course	Authoring	Publishing a course version
lms_delete_course	Authoring	Deleting courses, including others' courses
lms_preview_course	Authoring	Previewing unpublished course content
lms_manage_enrollments	Administrative	Enrolling and un-enrolling users
lms_bypass_progression	Administrative	Moving through a course without meeting the gates
lms_view_course	Learner	Seeing that a course exists
lms_view_course_content	Learner	Opening step content
lms_take_course	Learner	Progressing and completing

Each authoring capability maps onto the corresponding WordPress post-type capabilities for the course post type, so the standard WP Admin list-table behaviour (which rows are editable, whether Add New appears) follows automatically.

Per-user grants

Capabilities are not limited to what a role provides. A user's effective set is the union of their role defaults and any grants recorded against them individually. That is how a single author can be given course-editing rights without promoting them to editor, and how learner capabilities reach users whose role grants nothing.

Changing the role defaults

The role → capability defaults are filterable. To let editors publish, for example:

add_filter('tangible_lms_role_capabilities', function (array $roles): array {
    $roles['editor'][] = 'lms_publish_course';

    return $roles;
});

The filter receives the full role-to-capability map and must return the same shape. It only affects users below administrator. Administrators are granted everything before the filter is consulted.

Adding a role rather than changing one

Because the map is keyed by role slug, a custom role works the same way. Register the role with WordPress as usual, then add an entry for its slug in this filter with the LMS capabilities it should carry.