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

114 lines
6.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# PRD — Dashboard Onboarding Checklist: Sub-steps + Updated Portal/Email Items
- Slug: `2026-01-07-dashboard-onboarding-checklist-substeps`
- Date: `2026-01-07`
- Status: Draft
## Summary
Update the MSP dashboard onboarding checklist to support sub-steps within a step card. Two existing steps will be re-framed (Customer Portal setup and Email configuration) to show multiple sub-items that must all be completed before the parent step is considered complete. Also fix the Secure Identity & SSO “Connect SSO” link.
## Problem
Today, each onboarding step is treated as a single boolean-ish completion state. Some setup areas require multiple distinct actions (e.g., portal domain + portal branding + inviting a portal user). Without sub-steps, the checklist can report “complete” too early or lacks guidance for whats still missing, reducing its usefulness.
## Goals
- Support rendering and tracking sub-steps inside a checklist step card.
- Consider a step complete **only when all of its sub-steps are complete**.
- Update checklist content:
- Replace “Client Portal Domain” with a broader “Set Up Customer Portal” step that includes:
- Portal custom domain
- Portal color and logo customizations
- Invite your first contact to the portal
- Replace “Managed Email Domain” with “Configure Email” that includes:
- Configure inbound email
- Configure outbound custom email domain
- Fix the Secure Identity & SSO “Connect SSO” link to `/msp/profile?tab=Single+Sign-On`.
## Non-goals
- Adding new backend configuration workflows beyond surfacing existing state.
- Changing the overall number of top-level onboarding panels (keep the existing set of top-level steps stable unless required for UX).
- Adding new analytics/metrics beyond what already exists for step completion and CTA clicks (unless requested).
## Users and Primary Flows
- **MSP admin** opens the dashboard and sees onboarding cards and/or the onboarding drawer.
- Admin clicks CTAs to complete setup tasks.
- Progress updates automatically as configuration is completed, with sub-step checkmarks reflecting whats done and what remains.
## UX / UI Notes
- Sub-steps should be displayed within the relevant onboarding step card as a short list with completion checkmarks.
- Parent step status rules:
- **complete**: all sub-steps complete
- **blocked**: any sub-step blocked (surface the most relevant blocker message)
- **in_progress**: at least one sub-step started/complete but not all complete
- **not_started**: all sub-steps not started
- If a step has no sub-steps, behavior remains unchanged.
- Parent “progressValue” may be derived from sub-steps (e.g., 1/3, 2/3 → 33%, 67%) to keep existing progress visuals meaningful.
## Requirements
### Functional Requirements
1. The onboarding progress payload supports an optional list of sub-steps per step.
2. The dashboard checklist UI renders sub-steps with a checked/unchecked affordance.
3. The parent step status is derived from its sub-steps (or legacy single-step status when no sub-steps exist).
4. “Set Up Customer Portal” sub-steps resolve from existing system signals:
- Portal custom domain: reuse current portal domain status signal.
- Portal color/logo customization: infer from tenant branding settings.
- Invite first contact: infer from portal invitation / client portal user existence.
5. “Configure Email” sub-steps resolve from existing system signals:
- Inbound email: infer from inbound email provider configuration.
- Outbound custom email domain: reuse managed email domain verification status.
6. The Secure Identity & SSO card CTA route is corrected to `/msp/profile?tab=Single+Sign-On`.
### Non-functional Requirements
- Keep the implementation lightweight and consistent with the existing `getOnboardingProgressAction` aggregation pattern.
- Ensure the UI gracefully handles missing `substeps` (backward-compatible rendering).
## Data / API / Integrations
- Extend `OnboardingStepServerState` to include `substeps?: OnboardingSubstepServerState[]`.
- Add/extend a small helper to derive parent step status + progress from sub-steps.
- Reuse existing actions/services where possible:
- Portal domain: `getPortalDomainStatusAction`
- Tenant branding: `tenant_settings.settings.branding` (via an existing action or direct query)
- Portal invite/user: query `portal_invitations` and/or `users` (`user_type = 'client'`)
- Inbound email: query `email_providers` (and/or vendor configs as needed)
- Outbound domain: `@ee/lib/actions/email-actions/managedDomainActions.ts`
## Security / Permissions
- No new permissions surfaces; onboarding progress continues to require an authenticated MSP session.
- Data derived should not leak sensitive secret material; only counts/statuses and non-sensitive metadata are included.
## Observability
- Keep existing `onboarding_step_completed` event semantics (fires when the parent step transitions to `complete`).
- (Optional) Decide whether to add sub-step completion events later; not required for this scope.
## Rollout / Migration
- No data migrations expected.
- Roll out as a UI + server aggregation update; ensure older clients tolerate missing `substeps` and newer clients tolerate empty lists.
## Open Questions
Resolved (2026-01-07):
1. “Portal color and logo customizations” is complete when **any** customer portal configuration exists (any configuration at all).
2. “Invite your first contact to the portal” is complete when **a portal invite exists**.
3. “Configure inbound email” is complete when **any provider row exists**.
## Acceptance Criteria (Definition of Done)
- The onboarding checklist shows sub-steps for the Customer Portal and Email cards.
- Each sub-step has an accurate checked/unchecked state based on system signals.
- Parent card only shows “Complete” when all of its sub-steps are complete.
- The Secure Identity & SSO CTA navigates to `/msp/profile?tab=Single+Sign-On`.
- Existing steps without sub-steps behave exactly as they do today.