PSA/ee/docs/plans/2026-03-15-client-portal-board-visibility-groups-design.md
Hermes 284313f908
Some checks are pending
Bidi Control Character Guard / bidi-control-guard (push) Waiting to run
Circular Dependency Check / Check for new circular dependencies (push) Waiting to run
Citus Migration Smoke / Combined migrations on single-node Citus (push) Waiting to run
E2E Fresh Install Tests / fresh-install-e2e (push) Waiting to run
ext-v2 guardrails / Run ext-v2 guard and ESLint (push) Waiting to run
Integration Tests / Check for relevant changes (push) Waiting to run
Integration Tests / ${{ (github.event_name == 'schedule' || github.event.inputs.suite == 'full') && 'Full integration suite' || 'Tier-1 integration subset' }} (push) Blocked by required conditions
Mobile checks / Mobile lint + typecheck (push) Waiting to run
Mobile checks / Mobile unit tests (push) Waiting to run
Mobile checks / Mobile dependency audit (report) (push) Waiting to run
Mobile checks / Mobile reproducibility checks (push) Waiting to run
Secrets guard (env backups) / Ensure no tracked env backup files (push) Waiting to run
Temporal Readiness / fast-readiness (push) Waiting to run
Temporal Readiness / docker-parity (push) Waiting to run
TypeScript Type Check / Nx affected typecheck (push) Waiting to run
Unit Tests / Skipped-test budget (push) Waiting to run
Unit Tests / Nx affected unit tests (push) Waiting to run
Unit Tests / Server unit coverage (informational) (push) Waiting to run
Validate Tenant Management Schema / Check for relevant changes (push) Waiting to run
Validate Tenant Management Schema / Validate Tenant Management Schema (push) Blocked by required conditions
EE Workflows Build Guard / ee-workflows-build-guard (push) Waiting to run
Initial import of AlgaPSA codebase from PSA server
Excluded: .git, node_modules, secrets/, compose.env, assemblyscript tgz

Source: /opt/alga-psa on psa.joliet.tech
2026-06-22 16:12:17 -05:00

1.9 KiB

Client Portal Board Visibility Groups Design

  • Date: 2026-03-15
  • Status: Approved for planning

Summary

Introduce per-client board visibility groups for client portal access. Groups contain allowed boards. Each contact can have zero or one assigned group in v1. If no group is assigned, the contact keeps legacy full access to all of the client's boards. MSP staff and client portal admins can both manage groups and replace assignments.

Use reusable groups rather than direct per-user board grants.

Why:

  1. Per-user board checklists do not scale once a client has many portal users and many boards.
  2. A group-based model supports common access bundles such as "Standard Employees" and "HR Contacts".
  3. One group per contact is enough for v1 and keeps both the schema and UI simpler than a multi-group system.
  4. Storing the assignment on the contact works with the existing portal architecture because portal ticket access already resolves through users.contact_id.

Core Rules

  1. Groups are scoped per client.
  2. Contacts can have zero or one assigned group in v1.
  3. No assigned group means full access.
  4. MSP changes are not locked. Client admins may replace them later.
  5. Ticket visibility must be enforced server-side, not only in the UI.

Enforcement Scope

The implementation must cover:

  1. Client portal ticket list filtering.
  2. Client portal ticket details access.
  3. Client portal ticket creation options and submit validation.
  4. Ticket-backed dashboard summaries that should reflect only visible boards.

UI Surfaces

  1. Client portal admin surface for group CRUD and contact assignment.
  2. PSA contact portal tab extension for MSP-side group CRUD and assignment.
  3. Localized client portal copy in every supported client portal locale file.

Not In Scope

  1. Multiple groups per contact.
  2. Tenant-wide shared groups.
  3. Locked MSP overrides.
  4. Non-ticket visibility domains.