Create Public Workspace Permission Display Fix

Create Public Workspace Permission Display Fix

Version Implemented: 0.229.001

Issue Description

Similar to the group creation issue, when the "Require Membership to Create Public Workspaces" setting was enabled in the admin settings, users without the required CreatePublicWorkspaces role could still see the "Create New Public Workspace" button on the My Public Workspaces page. When they clicked on it, they would encounter an error because the backend API correctly enforced the permission, but the frontend UI was not respecting the permission setting.

Additionally, users without the CreatePublicWorkspaces role were completely blocked from accessing the My Public Workspaces page due to an overly restrictive decorator, preventing them from even viewing public workspaces they might have access to.

Root Cause Analysis

The issue was in multiple places:

1. Overly Restrictive Route Protection: The @create_public_workspace_role_required decorator was applied to the entire /my_public_workspaces route, blocking users without the CreatePublicWorkspaces role from viewing ANY public workspaces.

2. Frontend Template Issue: The "Create New Public Workspace" button was displayed unconditionally without checking if the user had the required permissions.

3. Missing Backend Context: The route handler was not passing the user's permission status to the template.

4. JavaScript Event Handlers: The JavaScript code was binding event handlers for create workspace functionality without checking permissions.

Technical Details

Files Modified

• route_frontend_public_workspaces.py - Added permission checking logic and removed overly restrictive decorator
• templates/my_public_workspaces.html - Added conditional display logic
• static/js/public/my_public_workspaces.js - Made modal initialization and event handlers conditional
• config.py - Updated version number

Code Changes Summary

Backend Route Changes (route_frontend_public_workspaces.py)

1. Removed Overly Restrictive Decorator:

   # REMOVED: @create_public_workspace_role_required from my_public_workspaces route
   # Users should be able to VIEW public workspaces even if they can't CREATE them
   

2. Added Permission Checking Logic:

   user = session.get('user', {})
   settings = get_settings()
   require_member_of_create_public_workspace = settings.get("require_member_of_create_public_workspace", False)
   
   # Check if user can create public workspaces
   can_create_public_workspaces = True
   if require_member_of_create_public_workspace:
       can_create_public_workspaces = 'roles' in user and 'CreatePublicWorkspaces' in user['roles']
   
   return render_template(
       "my_public_workspaces.html",
       settings=public_settings,
       app_settings=public_settings,
       can_create_public_workspaces=can_create_public_workspaces
   )
   

3. JavaScript Permission Variable:

   <script>
     window.canCreatePublicWorkspaces = {{ can_create_public_workspaces|tojson }};
   </script>
   

JavaScript Changes (my_public_workspaces.js)

1. Conditional Modal Initialization:

   const createModal = window.canCreatePublicWorkspaces ? new bootstrap.Modal(document.getElementById('createPublicWorkspaceModal')) : null;
   

2. Conditional Event Handler:

   if (window.canCreatePublicWorkspaces) {
     $("#createPublicWorkspaceForm").on("submit", handleCreateForm);
   }
   

3. Safe Modal Handling:

   success: function () {
     if (createModal) {
       createModal.hide();
     }
     // ... rest of success handler
   }
   

Testing Approach

Created functional test test_create_public_workspace_permission_fix.py that validates:

• Template correctly implements conditional display logic
• Route passes permission status to template without overly restrictive decorators
• JavaScript handles permissions appropriately
• Modal and event handlers are conditional

Impact Analysis

• User Experience:
  • Users without permission no longer see a button they cannot use
  • Users can now VIEW public workspaces even if they can't CREATE them
• Security: No impact on security as backend API was already protected
• Functionality: No loss of functionality for authorized users
• Access: Improved access for users who should be able to view but not create

Validation

• Before Fix:
  • Users without CreatePublicWorkspaces role were completely blocked from accessing the page
  • When accessible, they could see the button but got errors when clicking
• After Fix:
  • Users without CreatePublicWorkspaces role can view public workspaces but don't see the create button
  • Authorized users can still create public workspaces normally

Related Features

This fix works in conjunction with:

• Admin Settings page where "Require Membership to Create Public Workspaces" is configured
• Azure AD App Registration roles configuration
• Backend API protection via @create_public_workspace_role_required decorator (kept on API endpoints and manage routes)

Configuration

The fix automatically respects the existing admin setting:

• Setting: require_member_of_create_public_workspace
• Required Role: CreatePublicWorkspaces (defined in Azure AD App Registration)
• Location: Admin Settings > Public Workspaces section

Note on Decorator Usage

The @create_public_workspace_role_required decorator remains on:

• API endpoints (for backend protection)
• The manage_public_workspace route (for workspace management)

The decorator was only removed from the my_public_workspaces view route to allow users to see public workspaces they have access to, even if they can't create new ones.