Give staff the minimum access

Purpose

Create individual staff accounts, apply the four Staff Access permissions, and verify every required screen with the actual role.

Access and dependencies

For: Site administrator<br> Capability: manage_options for Staff Access; WordPress create_users/promote_users for accounts and roles<br> Menu: GymCore Admin > GymCore Settings > Staff Access

Have a written task list for the staff member and a separate test account for the target role. Do not change the only working administrator account.

Assign and verify access

1. Open Users > Add New, create one account for the staff member, and assign the closest current role: gym_head_coach, gym_coach, gym_finance, or gym_sales. Select Add New User. Expected: The user appears once under Users with the intended role and receives only the approved account notification.
2. Open GymCore Admin > GymCore Settings > Staff Access. Review the row for that role and the four columns: Manage Members, Manage Billing, View Reports, and Manage Staff. Expected: The matrix shows the current saved map. Administrator checkboxes are disabled because administrators always receive all four.
3. Change only the permissions required by the written task list. A preset button prompts for a role slug and changes checkboxes only; it does not save them. Expected: The intended boxes change, with no access committed yet.
4. Select Save Role Permissions. Expected: WordPress reports that role permissions were saved and the matrix persists after reload.
5. Sign in as the target test user and open every required and prohibited task screen. Expected: Required work succeeds and prohibited work is denied. Record the exact capability used by any screen that does not follow the four-column matrix.

Factory defaults

Current product limit

Staff Access edits only four gymcore_* RBAC capabilities. Current GymCore menus and actions also check legacy gym_*, WordPress, and WooCommerce capabilities such as gym_check_in_member, gym_manage_leads, gym_process_sale, gym_promote_student, edit_posts, manage_woocommerce, and manage_options. Saving this matrix is not proof that a role can—or cannot—perform every task.

Changes are reversible by restoring the previous matrix and selecting Save Role Permissions. Removing a WordPress role or deleting a user is a different, more destructive action; do not use it to troubleshoot access.

Privacy and troubleshooting

Use individual accounts and multifactor authentication where your identity provider supports it. Never ask staff to share passwords or borrow an administrator session.

• If a menu is absent, identify the exact screen capability in current source or with an approved capability audit; do not keep granting all four boxes.
• If a preset appears to do nothing, enter the exact role slug at its prompt, inspect the boxes, then save explicitly.
• If access remains after a box is cleared, check the user’s other roles and WordPress/WooCommerce capabilities. Administrators always have full access.

Verify in the source system

Reopen Users and Staff Access, then repeat the task with the target test account. The effective role test—not the checkbox matrix—is final evidence.

Related guides

• Verify the site before launch
• Read the staff dashboard
• Know which system owns the change

Source-verified: src/Admin/RolesPage.php, src/RBAC/RoleManager.php, and src/Capabilities.php for access, labels, four capabilities, presets, and defaults.