DEVAGENT ADMIN WORKSPACE DOCS

DevAgent Admin Workspace Documentation

Install, configure and operate DevAgent Admin Workspace 1.0.0. This guide covers roles and permissions, workspace dashboards, quick actions, administrative menus, assignments, effective menu verification, recovery, privacy and troubleshooting.

Plugin version 1.0.0 · Updated July 2026

Requires WordPress 6.8+ and PHP 8.1+. No external account, license or runtime service is required.

Quick start

Use this sequence to prepare a role, create a workspace and validate the result before assigning it to production users.

Install and activate

Upload the plugin ZIP, activate DevAgent Admin Workspace and review the local Diagnostics screen.

Prepare a role

Create or duplicate a custom role, then grant only the capabilities required for the user’s responsibilities.

Build a workspace

Configure the start page, dashboard blocks, quick actions and administrative menu, then publish the workspace.

Assign and verify

Assign the published workspace to a role, test with a real non-administrator user and review the browser-rendered menu result.

1. Requirements

Before installing DevAgent Admin Workspace, confirm that the site meets these requirements.

WordPress6.8 or higher
PHP8.1 or higher
PluginDevAgent Admin Workspace 1.0.0
Administrative accessAn account allowed to install and activate plugins and manage the plugin configuration
External account or licenseNot required
Third-party dependencyNone
Multisite: Each site stores its own workspaces, assignments, settings and logs. Network activation initializes sites, but version 1.0.0 does not provide network-wide workspace management or synchronization. 2. Installation and activation

2. Installation

1

Log in to WordPress with an account that can install and activate plugins.

2

Go to Plugins > Add New Plugin > Upload Plugin.

3

Select the DevAgent Admin Workspace ZIP file and choose Install Now.

4

When installation finishes, choose Activate Plugin.

5

Open Admin Workspace in the WordPress administration menu.

6

Confirm that WorkspacesRoles and permissionsAssign workspacesRecoveryDiagnostics and Settings are available.

7

Open Admin Workspace > Diagnostics and confirm that PHP version, WordPress version, workspace storage, data schema and administrator recovery capabilities do not report an error.

3. Core concepts and security model

Add Your Heading Text Here

A WordPress role determines what a user is allowed to do. DevAgent Admin Workspace can create and edit custom roles, but the final authorization decision remains with WordPress and the plugin that owns each screen or action.

Workspaces control presentation

A workspace organizes the user’s administration experience: its start page, dashboard blocks, quick actions and administrative menu. A workspace does not grant permissions.

Security rule: Hiding a menu item changes navigation only. It does not remove the underlying capability and does not block a direct URL when WordPress or another plugin still authorizes the user. Showing an item cannot grant access when the role lacks the required capability.

Draft and published workspaces

  • Draft workspaces can be configured and previewed, but they cannot be assigned to users.
  • Published workspaces can be assigned to roles or individual users.
  • Deactivating a published workspace returns it to draft status and prevents it from being applied.

One configuration, role-specific result

Several roles can share one workspace. The configured menu is shared, but each role may see a different effective result because WordPress capabilities and plugin-specific conditions differ. Create separate workspaces when roles need genuinely different menu structures.

Runtime behavior

  • After login, an eligible user is redirected to the workspace start page after the plugin resolves the applicable workspace.
  • The native Dashboard entry is replaced by the workspace entry for users who receive a workspace.
  • An invalid or unavailable start page falls back to the workspace dashboard.
  • Emergency mode can disable workspace application without deactivating the plugin.
1

Define the target user’s responsibilities and identify the WordPress capabilities required for them.

2

Create or duplicate a custom role under Admin Workspace > Roles and permissions, or start from a template.

3

Create a workspace under Admin Workspace > Add workspace.

4

Configure its start page and dashboard.

5

Publish the workspace.

6

Assign it to the target role under Admin Workspace > Assign workspaces.

7

Return to the workspace editor and configure the Administrative menu using the assigned role as the preview context.

8

Log in with a real non-administrator test user who has the assigned role and open a normal wp-admin screen.

9

Return as an administrator and review the browser-rendered verification result.

10

Test login redirect, dashboard blocks, quick actions, direct screen access, content permissions, menu behavior and a new login session.

11

Deploy the assignment to production users only after the real-user test is complete.

Recommended practice
Use a dedicated test user for each role. Protected preview is useful for design and diagnosis, but it does not replace a real session with the assigned role.

5. Roles and permissions

Guided questions for practical role-permission configuration.

Advanced capabilities view with exact WordPress capability identifiers.

Open the role manager

Go to Admin Workspace > Roles and permissions. The list shows each role’s display name, technical slug, user count, capability count and origin. Roles created by WordPress or another plugin remain visible, but only roles created by DevAgent Admin Workspace can be deleted from this interface.

Create a role

1

Choose Add role.

2

Choose Start from scratch or select a suggested template.

3

Enter a human-readable Role name.

4

Enter a Technical slug using lowercase letters, numbers, underscores and hyphens. The slug cannot be changed later.

5

Choose Guided questions or Advanced capabilities.

6

Review the permission summary and any sensitive-capability warning.

7

Choose Create role or Save permissions.

Base capability
Use a dedicated test user for each role. Protected preview is useful for design and diagnosis, but it does not replace a real session with the assigned role.

Guided questions

The guided assistant converts practical yes/no answers into WordPress capabilities and includes prerequisites when one responsibility depends on another. It covers posts, pages, media, comments, categories, users, privacy tools, theme options and site settings. Capabilities added by other plugins and not managed by the assistant are preserved when an existing role is edited.

manage_options consequence
Answering Yes to “Can this role modify site-wide WordPress settings?” grants manage_options. A user with that capability is excluded from workspace application.

Advanced capabilities

Use the advanced view when an extension requires capabilities that are not covered by the guided assistant. Known WordPress capabilities include descriptions and security classification. Extension capabilities may appear only by technical identifier and are not automatically classified as safe. The plugin does not scan third-party source code or guarantee discovery of AJAX, REST, background-action or dynamically calculated permissions.

Sensitive capabilities

Newly granting sensitive capabilities requires explicit confirmation. Examples include user creation or deletion, role promotion, privacy tools, manage_options, theme or plugin management, core updates, unfiltered uploads or HTML and the plugin’s own configuration capabilities.

Edit, duplicate and delete roles

  • Edit: change the display name and capabilities; the technical slug remains fixed.
  • Duplicate: create a new editable role based on the selected role.
  • Delete: available only for roles created by DevAgent Admin Workspace when no users are assigned and the role is not protected.
  • Administrator: visible for reference but cannot be modified or deleted by the Lite interface.

6. Templates

Templates create an editable custom role or a draft workspace. They never overwrite an existing role or workspace, and every capability, block, quick action and menu choice remains editable.

Template Purpose Starter menu
Content manager Manage posts, pages, media, categories and comments without site configuration Dashboard, Posts, Pages, Media, Comments
Restricted editor Create and edit personal drafts while publication remains under review Dashboard, Posts, Media, Profile
Media manager Upload and organize media with restricted editorial and settings access Dashboard, Media, Profile
Content reviewer Review colleagues’ content and moderate comments without broad administration access Dashboard, Posts, Comments, Profile
Site client Provide a simple read-oriented console with support information Dashboard, Profile
Non-technical administrator Broad content and user oversight without manage_options, plugins, themes or update permissions Dashboard, Posts, Pages, Media, Comments, Users, Profile

To use a template, open Admin Workspace > Templates, review its suggested capabilities and workspace content, create a uniquely named role or draft workspace, then adapt it before publishing or assigning it.

7. Creating and editing a workspace

Workspace editor with status, identity, start page and configuration choices.

1

Go to Admin Workspace > Add workspace.

2

Choose Empty workspace or a suggested starting layout.

3

Enter a recognizable Name.

4

Enter an Internal slug using lowercase letters, numbers and hyphens, or leave it empty to generate it from the name.

5

Add a Description explaining the audience and responsibilities.

6

Choose a Dashicon.

7

Select the Start page type and enter its value when required.

8

Configure the Dashboard and Administrative menu tabs.

9

Choose Save draft or Publish workspace.

Field Use
Name Human-readable administrative name
Internal slug Stable internal identifier
Description Internal explanation of audience and responsibilities
Icon Dashicon used to identify the workspace
Start page Destination applied after workspace resolution
Dashboard Blocks, quick actions, instructions, links and information
Administrative menu Intended visibility, labels, order, groups, links and role-aware verification
Menu configuration prerequisite
Publish and assign the workspace to at least one eligible role before relying on role-specific menu verification. The editor needs a role context to compare configured and effective navigation.

8. Start page behavior

The start page is used after the plugin resolves an eligible user’s workspace. Invalid or unavailable destinations fall back to the workspace dashboard.

Start page type Configuration
Workspace dashboard No value is required
Administrative screen ID Enter a valid WordPress administration screen identifier
Internal administration URL Enter a relative wp-admin path such as edit.php?post_type=page; external URLs are not accepted

Confirm that the destination is internal, available, authorized for the assigned role and registered by its owning plugin. Always test it with a real user after publishing and assigning the workspace.

9. Dashboard builder and quick actions

Dashboard builder with blocks, visibility, ordering controls and publishing actions.

Dashboard blocks

The workspace dashboard is server-rendered and capability-aware. A block is shown only when the user has the normal WordPress permission and any optional extra restriction configured by the administrator.

Use Add a block, configure the fields, control visibility, move the block up or down and remove it when unnecessary. Extra permission restriction can make visibility more restrictive; it never grants permission. A workspace can contain up to 50 blocks.

Available blocks are: Welcome, Instructions, Quick actions, Useful links, Recent posts, Recent pages, Drafts, Scheduled content, Pending comments, Recent files, Recent users, Site information and Contact and support. Item-list blocks accept a count from 1 to 20. Useful links accept one Label | URL entry per line. The starter layout restores Welcome, Quick actions, Recent posts and Contact and support.

Quick actions

Quick actions open permitted administrative tasks and resources. Each action checks its normal WordPress permission when the dashboard is rendered. An optional extra capability can only make it more restrictive.

1

In the Dashboard tab, open Quick actions and choose Add action.

2

Select an action type.

3

Enter the label and optional description.

4

Choose a Dashicon.

5

Complete the destination field when required.

6

Keep No extra restriction unless a specific additional capability is necessary.

7

Keep the action active, arrange its order and save or publish the workspace.

Action types include Create a post, Create a page, Open media library, Edit specific content, Internal administration screen, Plugin screen and External URL. A workspace can contain up to 50 actions.

Do not use quick actions as permission controls
A button may be hidden when a permission is missing, but WordPress capabilities remain the real access control.

10. Administrative menu and effective verification

Establish a role context

Publish the workspace, assign it to an eligible role, return to Edit workspace > Administrative menu and select the role whose effective menu you want to review.

Configure navigation

For native WordPress or plugin items, you can show or hide the item, rename its label, change its order, choose a Dashicon for a top-level item, keep it in its original location or place it inside an active custom section. Advanced details show slug, parent, screen ID and declared capability.

Custom menu sections group related screens under one top-level heading. Additional links can open a validated internal administration path or a complete http:// or https:// URL. New screens detected after adding a plugin are not enabled automatically. Stored screens that are no longer registered remain in the configuration and are reported as unavailable.

The reset control removes custom labels, hidden states, sections, links and ordering. Review the result before saving or publishing.
Access versus navigation
Remove or change a role capability when access itself must be removed. Hide a menu item only when the user is authorized but the screen is unnecessary or confusing.

Refresh effective menu verification

1

Save or publish the menu configuration.

2

Log in with a real user who has the selected role and assigned workspace.

3

Open a normal wp-admin screen and wait until the menu finishes loading.

4

Return as an administrator.

5

Open the workspace editor and select Administrative menu.

6

Review the result for each item and menu family.

Status Meaning
Visible to this role Configured to show and confirmed in the rendered menu
Hidden by workspace Intentionally disabled by the workspace
Pending verification No compatible browser result exists for the current setting
Configured, not shown Configured to show, but absent in the last browser check
Not available to this role The role lacks the declared capability
Not currently registered The stored item is absent from the currently captured menu
Partially shown A family contains confirmed visible and absent child items
Partially verified Some items are current while others still need verification

A third-party plugin may conditionally register or remove a screen, require additional permissions, depend on a parent menu or hide an item later with CSS or JavaScript. The workspace can report the difference but cannot override the plugin’s access logic.

11. Assigning workspaces

Role assignments connecting eligible WordPress roles to published workspaces.

Role assignments

Go to Admin Workspace > Assign workspaces, choose one published workspace for each eligible role or No workspace, save the assignments and test with a real user.

 

One role can use only one workspace. One workspace can be shared by several roles. Every user with the role receives the workspace unless an individual exception exists. Roles that grant manage_options keep the normal WordPress administrator.

Users requiring review

When a user has multiple roles that point to different workspaces, the screen lists the user under Users requiring review. WordPress role order determines the current result, but an individual exception is recommended to make the intended workspace explicit.

Individual user exceptions

Search for the user, select an individual published workspace or choose Use role assignment to remove the exception, then save and test the account. Exceptions change presentation only; they do not change roles or permissions.

12. Previewing, testing and production deployment

Protected workspace preview with simulated role, menu and dashboard results.

Protected workspace preview

Choose Preview workspace, select a simulated role and review the workspace status, capability count, start page, sensitive capabilities, dashboard and menu simulation. Preview does not switch users, grant capabilities, modify the workspace or change the administrator’s menu.

Real-user test

Use a non-administrator account with exactly the intended role combination. Test the login redirect, start page, dashboard blocks, quick actions, native and custom menu items, permitted direct URLs, denied direct URLs, content actions, menu verification refresh and behavior after logout and login.

Do not test with an administrator
Because manage_options excludes the user from workspace application, an administrator account cannot represent the production experience.

Production checklist

Before deployment, confirm requirements, Diagnostics, role capabilities, sensitive-capability approval, published assignment, start-page access, dashboard actions, rendered menu verification, direct URL behavior, multi-role users, recovery snapshot, emergency procedure and uninstall data policy.

13. Workspace lifecycle, recovery and diagnostics

Recovery snapshots and recent configuration changes.

Local Diagnostics checks for requirements, storage, privacy and external services.

Lifecycle and updates

The Workspaces list supports Edit, Preview workspace, View dashboard, Duplicate, Deactivate and Delete to Trash. Updating a published workspace stores the last valid configuration as a recovery snapshot. For a major redesign, duplicate the workspace, keep the copy in draft, test it and change assignments only when the replacement is ready.

Restore a previous configuration

Go to Admin Workspace > Recovery, locate a stored snapshot, confirm the replacement, choose Restore previous configuration, then review and test the result. Restoring is reversible: the previously current configuration becomes the next recovery snapshot.

 

The Recovery screen retains the 50 most recent configuration changes with UTC time, workspace ID, action, user ID and result. It does not record IP addresses.

Diagnostics

Diagnostics runs locally and reports emergency mode, PHP and WordPress versions, workspace storage, data schema, administrator recovery capabilities, workspace records, role assignments, log entries, privacy integration, uninstall policy and external-service status.

Emergency mode

To disable all workspace application without deactivating the plugin, add this line to wp-config.php:

define( ‘DEVAWORKSPACE_DISABLE_WORKSPACES’, true );

Eligible users return to the normal WordPress administration experience. Recovery, Settings and Diagnostics remain available to authorized administrators. Remove the constant or set it to false after correcting the configuration and completing a test.

14. Settings, privacy and multisite

Uninstall behavior

The option Permanently remove this plugin’s data when the plugin is deleted is disabled by default. When disabled, deleting the plugin preserves its data. When enabled, uninstall removes workspaces, assignments, plugin options, user assignment metadata, logs and internal plugin capabilities. Custom roles are preserved to avoid leaving users without a valid role.

Irreversible operation
Deleting the plugin while permanent data removal is enabled cannot be undone. Export or document the required configuration first. Deactivation stops the plugin without running the uninstall policy; deletion runs it.

Privacy and local data

The plugin stores its configuration locally in the WordPress database, does not transmit personal data to external services and does not record IP addresses. It may store workspace configuration, role or individual-user assignments, the workspace creator’s user ID, expiring role-specific menu snapshots and the user ID associated with a limited configuration log entry.

 

It registers suggested privacy-policy guidance, integrates with WordPress personal-data export and erasure tools and removes an individual workspace assignment when a user is deleted or removed from a site.

Multisite

Each site maintains its own workspaces, assignments, settings and logs. Network activation initializes existing sites, and new sites receive local defaults. Version 1.0.0 does not provide network-wide configuration, centralized assignment or cross-site synchronization. Repeat configuration and testing on every site unless you use an external deployment process.

15. Compatibility and current scope

Version 1.0.0 includes custom role management, guided and advanced capabilities, six editable templates, workspace lifecycle and recovery, capability-aware dashboard blocks and quick actions, administrative menu organization, three menu-observation layers, verification statuses, role and user assignments, start-page redirection, protected preview, emergency mode, local diagnostics, bounded logging, privacy integration and multisite lifecycle support.

 

The current scope deliberately excludes using menu visibility as security, granting access without the required capability, applying workspaces to users with manage_options, scanning all third-party source code, enabling new plugin screens automatically, network-wide multisite management, remote accounts, telemetry, cloud storage, CDN assets, license checks and automatic user impersonation during preview.

16. Troubleshooting

A workspace is not applied to a user

Confirm that it is published and assigned, the user does not have manage_options, multi-role conflicts are resolved, emergency mode is inactive and the user has logged out and back in.

The user lands on the dashboard instead of the selected start page

Confirm that the destination is valid, internal, available and authorized for the role. Confirm that the owning plugin or feature is active, then test with a real user.

A menu item is configured to show but is missing

Check the declared capability, role, parent menu and related plugin. Refresh the browser-rendered observation and check whether the owning plugin removes or hides the item conditionally.

A visible item returns an access-denied message

The workspace cannot grant permission. Grant only the appropriate role capability and review any additional authorization checks implemented by the owning plugin.

A hidden item still opens by direct URL

This is expected when the role retains the underlying capability. Remove or change the capability when access itself must be restricted.

The status remains Pending verification

Log in with a user who has the role and assigned workspace, open a normal wp-admin screen, then return as administrator and reopen the Administrative menu tab.

A stored screen is Not currently registered

Confirm that the related plugin or feature is active. Keep the setting if the screen may return, or remove it when it is no longer needed.

A dashboard block or quick action does not appear

Confirm that it is active, the user has the normal permission, any extra restriction is appropriate, the destination is valid and the workspace was saved or published.

A role cannot be deleted

Only roles created by DevAgent Admin Workspace can be deleted from this screen. Remove assigned users, avoid protected roles and move affected users to another valid role first.

The latest workspace change caused a problem

Restore the previous snapshot. If navigation is unusable, enable the emergency constant, review Diagnostics and the configuration log, test the correction and only then disable emergency mode.

Plugin data remains after deletion

This is the default behavior. Enable permanent data removal under Settings before deleting the plugin when complete removal is intended. Custom roles are still preserved.

17. Changelog preview

Before deployment, confirm requirements, Diagnostics, role capabilities, sensitive-capability approval, published assignment, start-page access, dashboard actions, rendered menu verification, direct URL behavior, multi-role users, recovery snapshot, emergency procedure and uninstall data policy.

Version 1.0.0

Initial public release of DevAgent Admin Workspace

The initial release includes workspace creation and lifecycle management, guided and advanced roles, templates, dashboard blocks, quick actions, administrative menu organization, effective menu verification, role and user assignments, protected preview, recovery, emergency mode, diagnostics, privacy integration and multisite lifecycle handling.

Related resources

Use these resources to review the product, install it and request support.

DevAgent Admin Workspace

Review the product purpose, main capabilities and security model.

WordPress.org plugin page

Download the free plugin and review its installation notes and release information.

Support forum

Ask a product-specific question in the official WordPress.org support forum.

Changelog

Review the user-facing changes included in the current release.

Scroll to Top