Public Workspace Management Permission Fix

Public Workspace Management Permission Fix

Fixed in version: 0.229.014

Issue Description

When the "Require Membership to Create Public Workspaces" setting was enabled in admin settings, users without the CreatePublicWorkspaces role were incorrectly shown "Forbidden" errors when trying to access the "Manage" functionality for public workspaces they were already members of (as Owner, Admin, or DocumentManager).

Root Cause Analysis

The manage_public_workspace frontend route in route_frontend_public_workspaces.py was incorrectly decorated with @create_public_workspace_role_required. This decorator should only apply to workspace creation operations, not management operations.

Key Findings:

1. Incorrect Permission Logic: The manage route was checking for the global CreatePublicWorkspaces role instead of workspace-specific membership
2. Overly Restrictive Access: Users who had legitimate access to manage workspaces (as Owner/Admin/DocumentManager) were being blocked
3. Role Confusion: Creation permissions were being conflated with management permissions

Technical Details

Files Modified:

• application/single_app/route_frontend_public_workspaces.py
• application/single_app/config.py (version update)

Changes Made:

1. Removed Incorrect Permission Decorator

File: route_frontend_public_workspaces.py

Before:

@app.route("/public_workspaces/<workspace_id>", methods=["GET"])
@login_required
@user_required
@enabled_required("enable_public_workspaces")
@create_public_workspace_role_required  # <-- REMOVED
def manage_public_workspace(workspace_id):

After:

@app.route("/public_workspaces/<workspace_id>", methods=["GET"])
@login_required
@user_required
@enabled_required("enable_public_workspaces")
def manage_public_workspace(workspace_id):

Permission Logic Explanation

Correct Behavior:

• Creation Operations (POST /api/public_workspaces): Require CreatePublicWorkspaces role when require_member_of_create_public_workspace is enabled
• Management Operations (/public_workspaces/<id>): Based on workspace-specific membership (Owner/Admin/DocumentManager)

Management Permissions are determined by:

1. Owner: Full access to all management functions
2. Admin: Can manage members, view requests, moderate content
3. DocumentManager: Can manage documents within the workspace

Impact Analysis

Before Fix:

• Users without CreatePublicWorkspaces role could not access management UI for workspaces they legitimately owned or administered
• "Forbidden" errors appeared even for workspace owners
• Management functionality was unnecessarily restricted

After Fix:

• Workspace management access is properly based on membership roles
• Users can manage workspaces they have legitimate access to
• Creation and management permissions are properly separated

Testing and Validation

Validation Scenarios:

1. Owner Access: Workspace owners can access management interface regardless of CreatePublicWorkspaces role
2. Admin Access: Workspace admins can access management interface regardless of CreatePublicWorkspaces role
3. DocumentManager Access: Document managers can access management interface regardless of CreatePublicWorkspaces role
4. Non-Member Access: Users without any role in the workspace are properly denied access
5. Creation Still Protected: Workspace creation still requires CreatePublicWorkspaces role when setting is enabled

Test Results:

• ✅ Management interface accessible to legitimate workspace members
• ✅ Creation operations still properly protected by CreatePublicWorkspaces role
• ✅ Non-members appropriately denied access to management interface
• ✅ Role-based UI functionality works correctly (Owner/Admin/DocumentManager specific features)

User Experience Improvements

Improved Workflows:

1. Workspace Owners can manage their workspaces without needing global creation permissions
2. Workspace Admins can perform administrative tasks regardless of creation role status
3. Document Managers can access workspace management for document-related tasks
4. Clear Separation between creation privileges and management privileges

Error Reduction:

• Eliminated confusing "Forbidden" errors for legitimate workspace managers
• Reduced support requests related to permission confusion
• Improved overall user satisfaction with workspace management

Implementation Notes

Decorator Usage Clarification:

• @create_public_workspace_role_required should only be used on:
  • POST /api/public_workspaces (workspace creation endpoint)
  • Other creation-related operations if added in the future

Security Considerations:

• Management permissions are still properly enforced at the API level
• Each management operation verifies workspace membership before allowing access
• No security regressions introduced by this change

Related Documentation

• Feature Documentation: ../features/PUBLIC_WORKSPACES.md
• Previous Fix: CREATE_PUBLIC_WORKSPACE_PERMISSION_DISPLAY_FIX.md (related but different issue)

Configuration Impact

This fix works with all existing admin settings:

• enable_public_workspaces: Must be true for public workspace functionality
• require_member_of_create_public_workspace: Still properly enforces creation restrictions
• No new configuration options required

Backward Compatibility

• ✅ Fully backward compatible
• ✅ No database schema changes required
• ✅ No API contract changes
• ✅ Existing workspaces and permissions unaffected