Restrict by WordPress Role or User
Role mode matches any selected role on the current signed-in user. User mode matches exact WordPress user IDs.
Role restriction checks the WordPress roles attached to the signed-in account and allows a match against any selected role. User restriction compares the exact WordPress user ID against the saved list. Roles scale better when membership changes; individual users are useful for a very small temporary pilot but the chooser intentionally loads only a limited number of accounts.
The practical starting point is to choose roles or users. Continue through the workflow until you retest after user role changes and cache purges, then use the field notes below to understand which choices affected AI output and which only changed delivery, access, or presentation.
What this feature does and when to use it
Section titled “What this feature does and when to use it”Use roles for stable groups and individual users for small, temporary pilots.
Use this feature in the following situations:
- An internal assistant should be available to a stable staff group represented by a WordPress role.
- A small named set of users needs temporary access during acceptance testing.
- You need to verify allowed, denied, and logged-out behavior after a role or account change.
Where to find it
Section titled “Where to find it”Before you begin
Section titled “Before you begin”- SmartSite Assistant is installed and activated.
- You are signed in with an account that can manage WordPress options.
Set it up step by step
Section titled “Set it up step by step”- Choose Roles or Users.
- Select at least one role or account.
- Save.
- Sign in as a permitted account and confirm the widget loads.
- Sign in as a different account and confirm it does not.
- Sign out and confirm anonymous visitors do not receive it.
- Retest after user role changes and cache purges.
Fields, controls, and important values
Section titled “Fields, controls, and important values”Role and user restrictions are useful when the assistant should support a known WordPress audience rather than every visitor. They determine whether the widget is available after login, not whether the AI can safely reveal a particular answer. Test allowed and denied accounts, and keep sensitive tool data protected by server-side permission checks as well.
| Field, control, or status | What SmartSite Assistant does with it | How to use it and why it matters |
|---|---|---|
| Role checkboxes | Match WordPress roles attached to the current user. | The choice in “Role checkboxes” decides where this feature is available. It may affect who can ask the AI or which profile sees a tool, but it does not make the resulting answer safer unless the underlying operation also checks access. |
| User selection | Exact IDs selected from a list capped at 200 users. | “User selection” defines an audience or assistant scope, not permission to disclose sensitive information. Keep the scope as narrow as practical, test one allowed and one denied case, and enforce real authorization inside every data-returning tool. |
| Login requirement | Both restricted modes return false for anonymous visitors. | The access consequence of “Login requirement” is: Both restricted modes return false for anonymous visitors. Test an allowed and denied session after saving; the setting controls widget availability rather than the accuracy or authorization of individual answers. |
How to confirm it is working
Section titled “How to confirm it is working”Judge Restrict by WordPress Role or User where its effect is actually consumed—by the administrator, visitor, model, or connected service. The expected result above is more useful than a green badge because it describes the behavior the configuration was meant to produce.
Practical example
Section titled “Practical example”Use a dedicated “Assistant Pilot” role instead of maintaining a long list of individual users.
Recommended practice
Section titled “Recommended practice”- Change one part of Restrict by WordPress Role or User at a time and keep a short record of the previous value and test result.
- Verify the saved result in the screen, visitor session, or connected service that actually consumes the setting.
Important warnings
Section titled “Important warnings”Common problems and focused checks
Section titled “Common problems and focused checks”| Problem | What to check and what to do next |
|---|---|
| A selected user is not in the chooser. | The view loads at most 200 users. Prefer a dedicated role or obtain owner/developer review before changing implementation. |
| Restrict by WordPress Role or User is missing or does not match this guide. | Confirm the plugin is active and the account can manage WordPress options. Use separate signed-out, allowed, and denied sessions so an existing login does not hide the access result. |
| A change on Restrict by WordPress Role or User does not produce the expected result. | Keep the exact notice and test case, then review the browser console and WordPress/PHP log. Use separate signed-out, allowed, and denied sessions so an existing login does not hide the access result. |
Screen reference
Section titled “Screen reference”- Capture
- Show Access in Users mode with two fictional accounts selected and the account count visible.
- Show
- Users mode, user search/list, selected accounts, Save
- Viewport
- Desktop, 1440 × 900
- Annotate
- Use numbered callouts only for controls referenced in the procedure.
- Redact
- OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text