Repository navigation
Conversation
…d logout URL Adds workos_get_valid_access_token(), workos_send_password_reset() and workos_get_logout_url(), so sites no longer call the WorkOS API themselves to refresh tokens, send resets or build the logout URL. - workos_get_valid_access_token() (User::get_valid_access_token()) returns the stored token while it has more than 60 seconds left, otherwise refreshes it through Api\Client::refresh_session() and stores the new pair with Login::store_tokens(). workos_get_access_token() keeps returning the token as stored. - workos_send_password_reset() calls the new PasswordResetAdmin\RestApi::send_for_user(), the code behind the admin reset route, so the rate limits, RedirectValidator check and activity log row are shared. The route now calls it after its capability check. - workos_get_logout_url() (User::get_logout_url()) returns the WorkOS sessions/logout URL for the stored session, or wp_logout_url() when there is none. - workos_get_user_id() already existed; it is documented with the rest in docs/php-helpers.md. Closes #63
Add workos_view_users, workos_send_password_reset, workos_change_email and workos_manage_lockouts, resolved through map_meta_cap. Each maps to the core capability its check used before (manage_options, edit_user, edit_user, edit_users), so default roles keep exactly the access they had, including self-service password reset and email change. A role granted a capability directly gets that action; false denies it. Switch the password-reset and change-email checks and the WorkOS Users screen to the new capabilities. Settings stay on manage_options, and the immediate admin email change still needs edit_users.
…lity GET /workos/v1/admin/users now checks workos_view_users (still manage_options by default). Each row carries can_send_password_reset and can_change_email for the caller, and the React screen shows only the buttons the caller can use.
Add docs/capabilities.md with the mapping table, what stays on core capabilities, and how to grant them to a custom role. Point the password-reset and change-email docs, README and AGENTS.md at the new capabilities. Closes #65
bordoni
added
enhancement
…orkos-capabilities # Conflicts: # AGENTS.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The plugin's user-management actions check
manage_options,edit_usersoredit_userdirectly. A site that wants a support role that can look up WorkOS users or send a password reset, without full user-editing rights, has no way to grant just that.Changes
WorkOS\Capabilitiesadds four capabilities throughmap_meta_cap. Each resolves to the core capability its check used before, with the same arguments:workos_view_usersmanage_optionsworkos_send_password_resetedit_user(per user, so self-service keeps working)workos_change_emailedit_user(per user)workos_manage_lockoutsedit_userstrueallows the action for any user,falsetakes it away. On multisite a direct grant still can't target a super admin.GET /admin/users.manage_options. The user-edit WorkOS panel and sync/re-sync stay onedit_users. An email change for another account still commits immediately only withedit_users, so a role with justworkos_change_emailgets the verified flow.can_send_password_resetandcan_change_email, and the screen shows only the buttons the caller can use.workos_manage_lockoutsis defined for the lockouts endpoint (Look up and clear sign-in lockouts from the admin and WP-CLI #61) to adopt. Nothing checks it yet.docs/capabilities.mdwith the table and a custom-role example. The password-reset and change-email docs, README and AGENTS.md point to it.Verified
CapabilitiesTest: for administrator, editor, author and subscriber, acting on themselves, another subscriber and another admin, every plugin capability gives the same answer as the core check it replaced, and matches an explicit expected table. Logged out gets nothing. It also covers a role with onlyworkos_send_password_reset, each capability granted alone,falsedenying, a grant on one user, and the row actions, panels, shortcodes and submenu following their capability.workos_send_password_resetsends a reset for another user and gets 403 from the settings routes. A role withworkos_change_emailgets the verified flow for another user and can cancel it. A role withworkos_view_userslists users. Editors still get 403 on all three.workos_view_userskeeps the WorkOS menu with just Users in it, can open Users, and can't open Settings.bun run buildandtsc --noEmitpass.Closes #65