How Joomla Group Inheritance Affects QCSB Workspace Permissions

This article explains how effective Joomla group membership can contribute multiple rules, why administrators should test inherited groups, and how QCSB resolves the resulting permissions rather than assuming a single direct group.

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.

How to test inherited membership

Identify every Joomla group the affected account belongs to, including inherited group relationships.
In the Workspace editor, review every Allowed user group/profile that can apply to that account.
Resolve the resulting role/custom permissions and any connection-specific override. Remember that explicit deny wins and no applicable allow means denied.
Save the Workspace and test with that exact normal account—not Super User—because Super User behavior can hide a missing group rule.
If access is unexpected, change one group/profile/override at a time and repeat the same operation so the responsible rule is clear.

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.