v4.4.5 - Shield gating for ThemeManager admin actions
Summary
Patch release. Closes a Shield-gating gap on the ThemeManager page where five installation-wide actions (delete, upload, license activate / deactivate / refresh) were available to any user with `View:ThemeManager` permission — including site_owner roles who legitimately need that permission to switch their own site's active theme.
Same pattern as v4.4.4's RegistrationSettings fix and tallcms/pro v1.8.2's ProSettings fix, but at the action level rather than the page level: `HasPageShield` correctly gates page access, but the destructive actions on the page had no per-action authorization.
Actions gated to super_admin
| Action | Was | Now |
|---|---|---|
| `delete` | Open to anyone with view permission | super_admin only |
| `upload` | Gated only on `theme.allow_uploads` config flag | super_admin AND `theme.allow_uploads` |
| `activateLicense` | Open to anyone with view permission | super_admin only |
| `deactivateLicense` | Open to anyone with view permission | super_admin only |
| `refreshAllLicenses` | Open to anyone with view permission | super_admin only |
Each gate has three layers:
- `->visible(...)` — UI hide
- `->authorize(...)` — backend block for direct AJAX invocation
- Defensive role check + `Notification` fallback inside the action body
All gates use `auth()->user()->hasRole('super_admin')`. Single-site installs continue to work because tallcms's install command marks the first user as super_admin.
Impact for site owners
No regression. Site owners on multisite installs (and any non-super-admin role with `View:ThemeManager`) lose access to actions they shouldn't have had in the first place. They can still:
- See the list of installed themes
- Switch their own site's active theme
- View theme details
Pull request
- #80 — Gate ThemeManager destructive + license actions to super_admin
Pattern note
This is the same kind of gap as v4.4.4 RegistrationSettings (page level). The broader pattern — page-level Shield being insufficient once any role with valid view permission exists — is worth a once-over across the rest of the admin panel. Likely candidates are pages that mix editor-facing content with installation-admin actions. Worth a focused audit follow-up.
Upgrading
Standard `composer update`. No DB migration. Audit role assignments after deploy if you have non-super-admin roles with `View:ThemeManager` — they'll lose the destructive action buttons but keep their view + activate-on-own-site capabilities.