How Private QCDS Workspaces Are Provisioned for Joomla Users

In current QCDS 2.0.7 Private / Organization Mode, normal users are not given separate private workspaces. QCDS maintains one primary organization workspace and provisions eligible Joomla users as members of that workspace with the appropriate role.

Provisioning happens automatically through user events and synchronous first access, so administrators normally manage eligibility and roles rather than manually creating a workspace for every user.

The Current Private-Mode Model

QCDS 2.0.7 defaults to Private / Organization Mode. The provisioning service creates or locates one primary organization workspace for the Joomla site. That workspace remains the shared QCDS container for the authorized organization users.

This is different from older documentation that described one isolated workspace per Joomla user. Do not use that older per-user model to troubleshoot current Private Mode.

Who Can Be Provisioned

For the primary organization workspace, QCDS keeps the workspace owner membership active. A Joomla user can also qualify through platform-management permission or an active QCDS user-group mapping.

When no active QCDS group mappings exist, current Private Mode has a first-access fallback: an authenticated user who is permitted by Joomla to open the published QCDS Workspace Dashboard menu item can be provisioned into the primary workspace as a sender. When group mappings are configured, the mappings become the authoritative qualification rule for ordinary users.

Roles Assigned During Provisioning

  • The workspace owner receives the owner role.
  • An eligible QCDS/platform manager receives the manager role.
  • Other eligible organization users are provisioned as sender members.

Those memberships control what the user may do inside the same organization workspace. Private Mode should therefore be thought of as shared organizational work with role-based access, not as one unrelated data silo per user.

When Provisioning Runs

The QCDS User plugin listens for Joomla user saves and reconciles workspace access automatically. Frontend first access also resolves provisioning synchronously. A user should not have to wait for a scheduled task before an otherwise valid first workspace visit can succeed.

The scheduled workspace-provisioning task remains useful for repair/reconciliation, but the current frontend path deliberately does not depend on cron to create the membership needed for first access.

What Happens When a User Opens QCDS

  1. QCDS requires an authenticated Joomla user.
  2. It looks for an active workspace membership matching that user.
  3. If no membership exists, the provisioning service reconciles the user's current eligibility.
  4. If the user qualifies, QCDS creates/repairs the appropriate membership and returns the active workspace.
  5. If provisioning cannot complete, QCDS returns a user-facing status such as configuration incomplete, unqualified, suspended, or failed instead of silently creating an unrelated workspace.

What the Administrator Should Manage

For normal Private Mode use, manage the published Workspace Dashboard menu, Joomla access levels, QCDS group mappings when you use them, and the Joomla users/groups themselves. Do not manually create a separate workspace for every ordinary sender just because older documentation described per-user workspaces.

If Provisioning Fails

If QCDS says the workspace could not be prepared, preserve the reference included in the message. Check the user's Joomla account/block state, menu access, configured group mappings, and QCDS provisioning/task health before changing workspace data manually.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDS feature? Visit the QC Digital Signature Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.