Feature: Organization Workspaces, Sharing, and Role-Based Document Access

[hoangsonww]

Summary

Add organization workspaces that let users invite collaborators, share document sets, and control document access with explicit roles instead of relying only on per-user document ownership.

Problem / Opportunity

DocuThinker already supports authenticated uploads, document history, chat, summaries, web/mobile access, and cloud imports. That works for individual use, but many real document analysis workflows are team workflows: legal review, research groups, operations teams, and classroom/cohort analysis all need shared documents with clear permission boundaries.

Without a workspace and permissions model, teams either duplicate uploads across accounts or share credentials. That limits adoption for professional workflows and makes future audit, billing, and governance features harder to model.

Proposed Feature

Introduce a workspace model across the backend, web frontend, and mobile client:

• Workspaces with owner/admin/member/viewer roles.
• Invite flow by email with pending, accepted, revoked, and expired states.
• Document ownership tied to both user and workspace context.
• Share controls for individual documents and document collections.
• Permission checks for read, upload, rename, delete, analyze, chat, and export actions.
• Workspace switcher in web and mobile clients.
• API and GraphQL shape for workspace documents and membership.

Scope

• Backend data model for workspaces, memberships, invitations, and document ACLs.
• Auth middleware changes that resolve both user identity and workspace permissions.
• Web UI for workspace switching, invitation management, and document sharing.
• Mobile parity for viewing shared workspace documents and switching active workspace.
• Tests for role enforcement and regression coverage around private documents.

Acceptance Criteria

• A user can create a workspace, invite another user by email, and revoke that invite before acceptance.
• Workspace admins can manage members; non-admin members cannot change membership.
• Documents uploaded into a workspace are visible only to users with access to that workspace.
• Viewer users can read summaries and chats but cannot upload, delete, rename, or re-run paid/expensive analysis actions.
• Existing personal documents remain private and continue to work without migration breakage.
• Backend endpoints and GraphQL resolvers enforce authorization server-side, not only in the UI.
• Web and mobile clients show the active workspace and prevent accidental actions in the wrong workspace.
• Tests cover owner/admin/member/viewer authorization for document list, upload, detail, rename, delete, and chat flows.

Non-Goals

• Real-time multi-user co-editing of the same document.
• Enterprise SSO or SCIM provisioning.
• Billing plans or seat management.
• Public unauthenticated document links.

Dependencies / Risks

• Requires careful migration from current user-scoped document history to user-plus-workspace scoping.
• Must avoid leaking document metadata across workspaces through search, GraphQL, or mobile APIs.
• Permission checks should be centralized enough that future RAG/search features inherit the same access model.

Open Questions

• Should personal space be modeled as a hidden default workspace or kept as a separate document scope?
• Should invitations require an existing DocuThinker account before acceptance, or allow account creation during invite acceptance?
• Which roles should be allowed to trigger AI jobs that may incur provider cost?