fixed active workspace bug for users switching public workspaces

.gitignore

@@ -43,5 +43,5 @@ flask_session
 **/sample_pie.csv
 **/sample_stacked_column.csv
 tmp**cwd
-tmp_images
-nul
+/tmp_images
+nul

application/single_app/route_backend_public_workspaces.py

@@ -297,15 +297,8 @@ def api_set_active_public_workspace():
         if not ws:
             return jsonify({"error": "Workspace not found"}), 404
 
-        # verify membership
-        is_member = (
-            ws["owner"]["userId"] == user_id or
-            user_id in ws.get("admins", []) or
-            any(dm["userId"] == user_id for dm in ws.get("documentManagers", []))
-        )
-        if not is_member:
-            return jsonify({"error": "Not a member"}), 403
-
+        # Public workspaces are accessible to all authenticated users for chat.
+        # No membership check needed — any user can set a public workspace as active.
         update_active_public_workspace_for_user(user_id, ws_id)
         return jsonify({"message": f"Active set to {ws_id}"}), 200
 

docs/explanation/release_notes.md

@@ -6,6 +6,12 @@
 
 #### Bug Fixes
 
+*   **Public Workspace setActive 403 Fix**
+    *   Fixed issue where non-owner/admin/document-manager users received a 403 "Not a member" error when trying to activate a public workspace for chat.
+    *   Root cause was an overly restrictive membership check on the `/api/public_workspaces/setActive` endpoint that only allowed owners, admins, and document managers — even though public workspaces are intended to be accessible to all authenticated users for chatting.
+    *   Removed the membership verification from the `setActive` endpoint; the route still requires authentication (`@login_required`, `@user_required`) and the public workspaces feature flag (`@enabled_required`).
+    *   Other admin-level endpoints (listing members, viewing stats, ownership transfer) retain their membership checks.
+    *   (Ref: `route_backend_public_workspaces.py`, `api_set_active_public_workspace`)
 *   **Chats Page User Settings Hardening**
     *   Fixed a user-specific chats page failure where only one affected user could not load `/chats` due to malformed per-user settings data.
     *   **Root Cause**: The chats route assumed `user_settings["settings"]` was always a dictionary. If that field existed but had an invalid type (for example string, null, or list), the page could fail before rendering.