mirror of
https://github.com/Hestia-Homes/assessment-model.git
synced 2026-07-27 22:45:03 +00:00
35f45837be
The screen at /projects/[projectId]/setup/contractors — the wireframe's 06-contractors-permissions.html, one table row per contractor organisation with its assigned workstreams and the two permission switches. Revisitable, like the setup steps before it: step 5 of the first-run wizard and the screen the hub (#444) links to afterwards, with ?from=hub the only difference (it swaps Continue for a return to the hub). Assignments are read back from the database on every visit, and every change persists immediately. - Add contractor: searches *existing* organisations (creating one belongs to the invite-company flow), multi-selects workstreams, sets both permissions. - Edit and remove per contractor, reacting to the API's 409s — a warning the user may confirm, or a refusal they cannot. - Continue leads to the work-order import (#414), the wizard's terminal step, with the readiness helper — not a re-derived rule — rendering what is still outstanding rather than a disabled button that can't say why. No useEffect: the form dialog is keyed and mounted only while open, so its useState initialisers are the load step. router.refresh() alongside the query invalidation keeps the readiness panel honest as the last gap is filled. ADR-0021 records why permissions are per-assignment but shown per-contractor (with a mixed state), and why a removal never cascades through work orders. |
||
|---|---|---|
| .. | ||
| adr | ||
| backend-asks | ||
| design | ||
| runbooks | ||
| wip | ||
| wireframes/ara-projects | ||