docs: define organization account model

This commit is contained in:
2026-05-04 15:45:12 -04:00
parent 9bdef978bd
commit cd6f402d9e
15 changed files with 555 additions and 21 deletions

View File

@@ -0,0 +1,65 @@
# Task: Organization domain foundation
## Feature
`docs/FEATURES/organizations.md`
## Goal
Add the backend foundation for organizations as the SaaS account boundary and make workspaces belong to an organization.
## Context
Current docs and code treat `Workspace` as the top-level boundary. The product model now requires `Organization` above workspace for billing, subscriptions, connectors, limits, and workspace ownership.
Existing local data does not need to be preserved.
## Scope
- Add an `Organizations` backend module or follow the existing ownership pattern if organization code belongs with `Workspaces`.
- Add an organization persistence model with name, slug/display identity, timestamps, and basic audit fields matching local conventions.
- Require every workspace to belong to exactly one organization.
- Update workspace create/list/detail APIs to include organization ownership.
- Add APIs for current user organization list and organization detail.
- Add backend validation that users cannot access organizations they have no relationship with.
- Seed or development bootstrap data should create at least one organization and owned workspace.
- Update OpenAPI after backend contracts change.
## Constraints
- Keep backend code under `backend/src/Socialize.Api`.
- Preserve FastEndpoints module structure.
- Do not implement billing provider integration in this task.
- Do not implement connector storage in this task.
- Do not implement full organization membership override behavior in this task.
- Existing development data may be wiped; do not spend scope on compatibility migration behavior.
## Likely Files
- `backend/src/Socialize.Api/Data/AppDbContext.cs`
- `backend/src/Socialize.Api/Modules/Organizations/**`
- `backend/src/Socialize.Api/Modules/Workspaces/**`
- `backend/src/Socialize.Api/Migrations/**`
- `backend/tests/Socialize.Tests/**`
- `shared/openapi/openapi.json`
- `frontend/src/api/schema.d.ts`
## Done When
- [ ] Organization entity is persisted.
- [ ] Workspace requires `OrganizationId`.
- [ ] Workspace APIs expose organization ownership.
- [ ] Current user can list accessible organizations.
- [ ] Current user can get accessible organization details.
- [ ] Unauthorized organization access is rejected.
- [ ] Development seed data creates an organization with owned workspaces.
- [ ] Backend build and tests pass.
- [ ] OpenAPI and generated frontend schema are updated.
## Validation Commands
```bash
dotnet build backend/Socialize.slnx
dotnet test backend/Socialize.slnx
./scripts/update-openapi.sh
```

View File

@@ -0,0 +1,62 @@
# Task: Organization membership and inherited permissions
## Feature
`docs/FEATURES/organizations.md`
## Goal
Model organization-level memberships and inherited workspace permissions with workspace-level overrides.
## Context
Users have global accounts. A user can have rights in multiple organizations and direct access to individual workspaces. Organization membership grants company-level access and inherited workspace permissions. Workspace membership can grant direct access or override workspace-specific inherited permissions.
## Scope
- Add organization membership persistence.
- Add organization-level roles or permissions for:
- organization owner/admin
- organization member management
- workspace creation/administration
- billing manager
- connector manager
- Define how organization permissions map to inherited workspace permissions.
- Preserve workspace participant relationship categories: `Organization Member` and `External Collaborator`.
- Allow workspace memberships to override applicable inherited workspace permissions.
- Ensure billing and connector permissions remain organization-level only.
- Update access checks used by workspace APIs to consider inherited organization permissions.
- Add tests for inherited access, direct workspace access, external collaborator access, and override behavior.
## Constraints
- Do not implement billing pages or billing provider integration in this task.
- Do not implement connector APIs in this task.
- Do not remove direct workspace membership support.
- External collaborators must not become organization members automatically.
- Keep permission names explicit; avoid magic strings where local patterns provide constants.
## Likely Files
- `backend/src/Socialize.Api/Modules/Organizations/**`
- `backend/src/Socialize.Api/Modules/Workspaces/**`
- `backend/src/Socialize.Api/Modules/Identity/**`
- `backend/src/Socialize.Api/Data/AppDbContext.cs`
- `backend/tests/Socialize.Tests/**`
## Done When
- [ ] Organization memberships are persisted.
- [ ] Organization roles/permissions include billing manager.
- [ ] Organization-level access can grant inherited access to owned workspaces.
- [ ] Direct workspace-only external collaborators remain supported.
- [ ] Workspace-level overrides apply to workspace-specific permissions.
- [ ] Billing and connector permissions cannot be granted through workspace overrides.
- [ ] Backend tests cover inherited, direct, external collaborator, and override access paths.
## Validation Commands
```bash
dotnet build backend/Socialize.slnx
dotnet test backend/Socialize.slnx
```

View File

@@ -0,0 +1,65 @@
# Task: Organization settings UI shell
## Feature
`docs/FEATURES/organizations.md`
## Goal
Add an organization-level settings page with sections for profile, members, billing access, connections, and owned workspaces.
## Context
Workspace screens remain the primary working context. Organization SaaS account administration lives under one explicit settings route: `/app/organizations/:organizationId/settings`.
## Scope
- Add the organization settings route:
- `/app/organizations/:organizationId/settings`
- Add feature-owned frontend code under `frontend/src/features/organizations/`.
- Load organization details from the backend.
- Show a settings page with sections for:
- profile/settings
- members and their roles/permissions
- billing
- connections
- owned workspaces
- Show the billing section only to users with billing manager permission.
- Show the connections section only to users with connector manager permission.
- Show the owned workspaces section to users with organization workspace administration access.
- Add English and French locale strings.
## Constraints
- Do not implement billing provider integration in this task.
- Do not implement real connection authorization flows in this task.
- Do not replace the existing workspace selector in this task.
- Frontend runtime config must flow through `frontend/src/config.js` if new runtime config is needed.
- Use the shared Axios API client in `frontend/src/plugins/api.js`.
## Likely Files
- `frontend/src/router/router.js`
- `frontend/src/features/organizations/**`
- `frontend/src/layouts/main/**`
- `frontend/src/locales/en.json`
- `frontend/src/locales/fr.json`
## Done When
- [ ] Organization settings route exists.
- [ ] Organization details load for accessible organizations.
- [ ] Organization settings page has sections for profile, members, billing, connections, and workspaces.
- [ ] Organization members are visible to permitted users.
- [ ] Billing section is permission-gated to billing managers.
- [ ] Connections section is permission-gated to connector managers.
- [ ] Owned workspaces section is visible to permitted organization users.
- [ ] UI strings exist in English and French.
- [ ] Frontend build passes.
## Validation Commands
```bash
cd frontend
npm run build
```

View File

@@ -0,0 +1,57 @@
# Task: Workspace selector organization switcher
## Feature
`docs/FEATURES/organizations.md`
## Goal
Keep the existing workspace selector as the primary context selector and add an organization switcher at the bottom.
## Context
The current workspace selector UX is good. The missing concept is that workspaces belong to organizations. Users may have access to multiple organizations and different workspaces under each one.
## Scope
- Load the current user's accessible organizations.
- Show the current organization at the bottom of the existing workspace selector.
- Allow users to switch organizations.
- Scope or group listed workspaces by the selected organization.
- Preserve current workspace selection behavior where possible.
- When switching organizations, select a sensible workspace for that organization or route to an organization/workspace selection state.
- Provide links from the organization switcher to organization settings routes when the user has access.
- Add English and French locale strings.
## Constraints
- Do not redesign the authenticated app shell.
- Do not turn the selector into a marketing or onboarding page.
- Preserve workspace as the primary day-to-day app context.
- Preserve route-level auth and role checks.
## Likely Files
- `frontend/src/layouts/main/**`
- `frontend/src/features/workspaces/**`
- `frontend/src/features/organizations/**`
- `frontend/src/stores/**`
- `frontend/src/locales/en.json`
- `frontend/src/locales/fr.json`
## Done When
- [ ] Workspace selector shows the active organization.
- [ ] Users can switch organizations from the selector.
- [ ] Workspace list reflects the selected organization.
- [ ] Organization settings links appear only when permitted.
- [ ] Existing workspace switching behavior remains usable.
- [ ] UI strings exist in English and French.
- [ ] Frontend build passes.
## Validation Commands
```bash
cd frontend
npm run build
```