groombook/app
Archived
13
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feature: client disable/deletion #67

New Issue
Closed
opened 2026-03-19 13:00:34 +00:00 by cpfarhood · 2 comments
cpfarhood commented 2026-03-19 13:00:34 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Deleting clients should require extra explicit confirmation and the default should be to disable a client profile/login instead. Disabled clients should still show up in reporting outside of the churn risk but should be hidden from the client list by default, exposable in a convenient way by staff.

Deleting clients should require extra explicit confirmation and the default should be to disable a client profile/login instead. Disabled clients should still show up in reporting outside of the churn risk but should be hidden from the client list by default, exposable in a convenient way by staff.
ghost commented 2026-03-19 13:09:36 +00:00 (Migrated from github.com)
Copy Link
Copy Source

CTO Triage

Good feature request. Here's the technical approach:

Schema changes (packages/db):

  • Add status column to clients table: enum('active', 'disabled') defaulting to 'active'
  • Add disabledAt timestamp (nullable)

API changes (apps/api):

  • PATCH /api/clients/:id — accept status: 'disabled' | 'active' to toggle
  • GET /api/clients — default filter to status = 'active', accept ?includeDisabled=true query param
  • No hard delete endpoint — disable is the default, delete requires explicit confirmation via a separate DELETE /api/clients/:id with a confirmation body param
  • Disabled clients excluded from booking flow lookups

Frontend changes (apps/web):

  • Clients list defaults to showing active only, with a toggle/filter to show disabled
  • Disable action with confirmation dialog (not delete)
  • Delete action behind a second explicit confirmation ("Type client name to confirm")
  • Disabled clients still appear in reports (excluding churn metrics as noted)

Priority: medium — no blocking dependencies, can be picked up when bandwidth allows.

## CTO Triage Good feature request. Here's the technical approach: **Schema changes** (`packages/db`): - Add `status` column to `clients` table: `enum('active', 'disabled')` defaulting to `'active'` - Add `disabledAt` timestamp (nullable) **API changes** (`apps/api`): - `PATCH /api/clients/:id` — accept `status: 'disabled' | 'active'` to toggle - `GET /api/clients` — default filter to `status = 'active'`, accept `?includeDisabled=true` query param - No hard delete endpoint — disable is the default, delete requires explicit confirmation via a separate `DELETE /api/clients/:id` with a confirmation body param - Disabled clients excluded from booking flow lookups **Frontend changes** (`apps/web`): - Clients list defaults to showing active only, with a toggle/filter to show disabled - Disable action with confirmation dialog (not delete) - Delete action behind a second explicit confirmation ("Type client name to confirm") - Disabled clients still appear in reports (excluding churn metrics as noted) **Priority**: medium — no blocking dependencies, can be picked up when bandwidth allows.
ghost commented 2026-03-19 17:15:49 +00:00 (Migrated from github.com)
Copy Link
Copy Source

PR opened: #69

Implementation follows the triage plan:

  • client_status enum (active/disabled) + disabled_at timestamp added to clients table
  • API defaults to active-only listing, supports ?includeDisabled=true
  • Disable is the default action; permanent delete requires typing client name to confirm
  • Booking flow excludes disabled clients
  • Frontend has show/hide disabled toggle, disable/enable buttons, and type-to-confirm delete modal
PR opened: #69 Implementation follows the triage plan: - `client_status` enum (active/disabled) + `disabled_at` timestamp added to clients table - API defaults to active-only listing, supports `?includeDisabled=true` - Disable is the default action; permanent delete requires typing client name to confirm - Booking flow excludes disabled clients - Frontend has show/hide disabled toggle, disable/enable buttons, and type-to-confirm delete modal
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 feature
New feature
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ai-review (AI Review) gb_barkley (Barkley Trimsworth) cpfarhood (Chris Farhood) ci (Continuous Integration [bot]) gb_flea (Flea Flicker) flux (Flux CD) admin (Gitea Admin) gb_lint (Lint Roller) renovate (Mend Renovate) gb_pawla (Pawla Abdul) gb_scrubs (Scrubs McBarkley) gb_shedward (Shedward Scissorhands) gb_dogfather (The Dogfather)
No Assignees
1 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: groombook/app#67
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?