Create Screen Options Control Plugin (Post Type + Role Based)

[vishal4669]

Summary

Build a WordPress plugin that allows administrators to define default Screen Options (list table columns) per post type and user role. These settings are saved globally and enforced consistently for users, with an optional lock to prevent users from changing column visibility via native Screen Options.

This ticket incorporates the approved concept flow from Miro and aligns implementation with that UX.

---

Problem / Why

WordPress stores Screen Options per user, resulting in inconsistent admin list views across roles and users. There is no native way to centrally manage or enforce defaults. This plugin introduces a global, role-based screen defaults manager to standardize admin workflows.

---

Goals

• Define default visible columns by:
  • Post Type (Posts, Pages, CPTs)
  • User Role
• Enforce these defaults globally.
• Provide a clean configuration wizard aligned with the Miro concept flow.
• Optionally lock column visibility so users cannot override defaults.

---

Concept Flow (Based on Miro)

Entry Point

Settings → Screen Defaults

---

Screen 1: Screen Options Manager (List View)

• Displays a table of configured views.
• Each row represents a saved configuration:
  • Post Type
  • Role
  • Columns shown
  • Status (Locked / Unlocked)
• Actions:
  • Configure View (create new)
  • Edit View
• Table supports:
  • Filters
  • Sorting
• Implementation note:
  • Prefer Gutenberg components
  • If not feasible, use WordPress Data Tables for performance

---

Screen 2: Configure View – Select Post Type

• User selects a Post Type (Posts, Pages, Media, CPTs).
• Available columns for the selected post type are fetched dynamically.
• Technical note:
  • Columns can be derived using list table headers (get_column_headers() or equivalent).

---

Screen 3: Configure View – Select Role

• User selects a User Role.
• Rules:
  • Only one view per role per post type is allowed.
  • Special role option:
    • All Users → Applies WordPress defaults
• Validation prevents duplicate role + post type combinations.

---

Screen 4: Configure View – Configure Columns

• Displays available columns as a selectable list.
• User can:
  • Enable / disable columns
  • Reorder columns (if feasible in v1)
• Option:
  • Lock Configuration
    • If enabled, users cannot change columns via native Screen Options.
• Action:
  • Create View / Save Changes

---

Screen 5: Edit View

• Edit screen shows only the configuration wizard, not the list table.
• Allows updating:
  • Columns
  • Lock status
• Save updates globally.

---

Non-Goals

• Managing pagination, sorting preferences, or filters (v1).
• Supporting non-list-table admin screens.

---

Requirements / Acceptance Criteria

Functional

1. Admin can create exactly one configuration per:
   • Post Type + Role
2. Defaults apply automatically when user visits the listing pages
3. Fallback logic:

• Role-specific config
• Post-type default (if implemented)
• WordPress default

4. Column configuration is stored globally, not per-user.
5. Unknown or removed columns are ignored safely.

---

Locking Behavior

6. If Lock Configuration is enabled:

• User changes via “Screen Options” are ignored or reverted.

7. If unlocked:

• User may temporarily adjust columns, but defaults still apply initially.

---

Permissions & Security

8. Only users with manage_options (or equivalent) can manage views.
9. Nonces and capability checks are mandatory.

[AishwarryaPande]

QA findings are as follows -

• 1. Author is not visible even when its enabled

Evidence -

• 2. UI has become cluttered. - as discussed with @milindmore22 we need some mechanism to overide the user preference by default screen option settings (considering this as primary)

Evidence -

I have observed this at quite a place when we select many things at that time UI gets disturbed

• 3. For "resources" I have selected like below from admin role but I observed that editor/marketops role was able to see the options from screen option in resources section.

Admin

Editor view

• 4. When we have "all users" we should not allow multiple selections.

Evidence -

[AishwarryaPande]

JFYI -
@vishal4669 - as discussed @milindmore22 will be sharing the updated zip and plugin is updated. So I am cross checking above reported issues as requested.

@milindmore22 share the zip here as well.
Thanks.

[milindmore22]

Updated zip

screen-options.zip

I have also raised public relations for one press site.

[AishwarryaPande]

@milindmore22 - I can see above issue in one-press 1 and also latest zip.
Please can you check at your end ?

[milindmore22]

screen-options.zip

1. Author is not visible even when its enabled

I am still debugging the issue.

2. UI has become cluttered. - as discussed with @milindmore22 we need some mechanism to overide the user preference by default screen option settings (considering this as primary)

Currently, user preferences take precedence over default screen options once a user has interacted with the column checkboxes. Since the mechanism to force-apply default options (overriding user history) was not implemented in this version, we must defer the resolution of this issue to the next release.

3. For "resources" I have selected like below from admin role but I observed that editor/marketops role was able to see the options from screen option in resources section.

Only the user role that is selected will have the selected columns from the screen options plugin applied. These settings will not apply to users with other roles. Therefore, we need to create a different configuration for editors and maketops, etc.

4. When we have "all users" we should not allow multiple selections.

Fixed in #49 disabled other roles when All users is selected.

[AishwarryaPande]

@milindmore22

Feedback on latest zip -

Case which needs to be handled ->
When all checkboxes are ticked we should assume it as all users and mark it as checked and disable the rest
-QA done in above zip

[milindmore22]

When all checkboxes are ticked we should assume it as all users and mark it as checked and disable the rest

Selecting "All Users" when every role is checked doesn't cover case when new role is introduced with third-party plugin or theme

There is a logic gap in how we handle role selection. If I manually check every single role box, I clearly intend for the configuration to apply to those specific roles. However, if I later install a plugin like WooCommerce, the new 'Shop Manager' role is left out because the system locked in my original list.

We shouldn't force all roles to use the specific 'All Users' toggle to achieve this; if specific roles are checked, instead of "All Users" then system should not interpret it as "All Users" configuration to any new roles added in the future.

[AishwarryaPande]

@milindmore22 - while re-verifying the fixes I have observed issue (sharing here as well) as discussed over slack.

I have updated the settings for "All users" type -> Handbook
I can see its not reflecting - please check

Also please add validation for add title field.