How Explicit Deny Wins in QCSB Permission Resolution
This article explains QCSB deny precedence so administrators can predict effective access when Joomla group rules, Workspace roles, and connection-specific overrides overlap.
What you need to know
- An explicit deny wins over allow, and no applicable allow means denied.
- Frontend button visibility is only guidance. QCSB rechecks authorization server-side and rejects forged Workspace/location/item references.
Permission precedence
- QCSB gathers the current user’s applicable Joomla group memberships and the Workspace access profiles that apply.
- The Workspace role/preset supplies the ordinary allowed operation set.
- Custom permission settings and connection-specific overrides can narrow that effective set.
- An explicit deny wins over an allow for the same effective decision; if no applicable rule allows an action, the action is denied.
- The resolved permission is checked again server-side for the requested connection/source/destination rather than relying on whether a button was visible.
Verify the result
- An allowed normal account can open the intended Workspace.
- An account outside the allowed rules cannot use the Workspace/action.
- Connection overrides and source/destination permissions behave exactly as configured.
Important limits and mistakes to avoid
- A successful Super User test does not prove a normal Joomla group has correct Workspace access. Test with the real role.
Troubleshooting
- If an action is missing/denied, check Joomla menu access, Workspace allowed group, Workspace role, custom denies, connection override, and plan gate separately.
Community Discussion
For practical QCSB workflows and discussion with other Joomla site owners, visit the QC Storage Bridge Community. For private support, bug reports, account-specific entitlement issues, or feature requests, use the QuantaCade support system.