ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
b6343d5c3a
TenantAtlas/specs/073-unified-managed-tenant-onboarding-wizard/contracts/onboarding-actions.md
ahmido b6343d5c3a feat: unified managed tenant onboarding wizard (#88) 
Implements workspace-scoped managed tenant onboarding wizard (Filament v5 / Livewire v4) with strict RBAC (404/403 semantics), resumable sessions, provider connection selection/creation, verification OperationRun, and optional bootstrap. Removes legacy onboarding entrypoints and adds Pest coverage + spec artifacts (073).

## Summary
<!-- Kurz: Was ändert sich und warum? -->

## Spec-Driven Development (SDD)
- [ ] Es gibt eine Spec unter `specs/<NNN>-<feature>/`
- [ ] Enthaltene Dateien: `plan.md`, `tasks.md`, `spec.md`
- [ ] Spec beschreibt Verhalten/Acceptance Criteria (nicht nur Implementation)
- [ ] Wenn sich Anforderungen während der Umsetzung geändert haben: Spec/Plan/Tasks wurden aktualisiert

## Implementation
- [ ] Implementierung entspricht der Spec
- [ ] Edge cases / Fehlerfälle berücksichtigt
- [ ] Keine unbeabsichtigten Änderungen außerhalb des Scopes

## Tests
- [ ] Tests ergänzt/aktualisiert (Pest/PHPUnit)
- [ ] Relevante Tests lokal ausgeführt (`./vendor/bin/sail artisan test` oder `php artisan test`)

## Migration / Config / Ops (falls relevant)
- [ ] Migration(en) enthalten und getestet
- [ ] Rollback bedacht (rückwärts kompatibel, sichere Migration)
- [ ] Neue Env Vars dokumentiert (`.env.example` / Doku)
- [ ] Queue/cron/storage Auswirkungen geprüft

## UI (Filament/Livewire) (falls relevant)
- [ ] UI-Flows geprüft
- [ ] Screenshots/Notizen hinzugefügt

## Notes
<!-- Links, Screenshots, Follow-ups, offene Punkte -->

Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.fritz.box>
Reviewed-on: #88
2026-02-03 17:30:15 +00:00

1.9 KiB
Raw Blame History

Onboarding Wizard — Action Contracts (073)

These are conceptual contracts for the wizard’s server-side actions (Livewire/Filament). They define inputs/outputs and authorization semantics.

Identify tenant

  • Purpose: Upsert or resume a tenant onboarding session and ensure a single tenant record exists per (workspace_id, entra_tenant_id).
  • Inputs:
    • entra_tenant_id (string)
    • name (string)
    • domain (string|null)
  • Outputs:
    • tenant_id (internal DB id)
    • onboarding_session_id
    • current_step
  • Errors:
    • 404: workspace not found or actor not a workspace member
    • 403: actor is a workspace member but lacks onboarding capability

Select or create Provider Connection

  • Purpose: Attach an existing default connection (if present) or create/select another connection for the tenant.
  • Inputs:
    • provider_connection_id (int|null)
    • (optional) connection creation fields (non-secret identifiers only)
  • Outputs:
    • provider_connection_id
    • is_default
  • Errors:
    • 404: connection/tenant not in workspace scope
    • 403: member missing capability

Start verification

  • Purpose: Start provider connection verification asynchronously.
  • Mechanism: Create/reuse OperationRun of type provider.connection.check, enqueue ProviderConnectionHealthCheckJob.
  • Inputs: none (uses selected connection)
  • Outputs:
    • operation_run_id
    • status (queued/running/succeeded/failed)
  • Errors:
    • 404: tenant/connection not in workspace scope
    • 403: member missing capability

Optional bootstrap actions

  • Purpose: Start selected post-verify operations as separate runs.
  • Inputs: list of operation types (must exist in registry)
  • Outputs: list of operation_run_id
  • Errors:
    • 403/404 semantics as above

Security & data minimization

  • Stored secrets must never be returned.
  • Failures are stored as stable reason codes + sanitized messages.