Enable, Disable, or Delete a Workspace Safely

This article explains how to temporarily disable a Workspace without deleting it, understand what frontend users see, and delete the Workspace definition without deleting provider files or the underlying shared connections.

How to do it

  1. Open Workspaces.
  2. Use Disable to make a Workspace unavailable from the frontend while preserving its configuration.
  3. Use Enable after the Workspace’s connections and permissions are ready again.
  4. Use Delete only when the publication itself is no longer needed. Deleting a Workspace does not delete its Storage Connections or provider files.
  5. Review Joomla menu items that point to a deleted Workspace so users are not left with a menu route that has no usable Workspace.

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

  • Do not bypass failed recovery protection to force a destructive action. The block is intentional safety behavior.
  • 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.
  • If a file action fails, retry with one small test item and read Transfer Details or the operation toast before changing global settings.

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.