# Workflow — Vendor Lifecycle

From admin-create / app-onboarding through service binding to permanent delete cascade.

---

## Sequence

```
                                  ┌─────────────────────┐
                                  │ Path A: App         │
                                  │ Vendor self-onboards│
                                  │ via Vendor App      │
                                  └──────────┬──────────┘
                                             │
                                             ▼
                          ┌─────────────────────────────────┐
                          │ OotboAPI writes `users` row     │
                          │ (user_type='vendor')            │
                          └─────────────────────────────────┘

┌─────────────────────────┐
│ Path B: Admin-created   │
│ /user/add-vendor        │
└──────────┬──────────────┘
           │ POST /user/check-vendor (phone exists?)
           ▼
┌─────────────────────────┐
│ POST /user/create-vendor│
│  bcrypt(phone) password │
└──────────┬──────────────┘
           │
           ▼
   ┌─────────────────────────────────────┐
   │ /user/vendorDetails/{id}            │
   │ View profile, edit, add services    │
   └──────┬──────────────────────────────┘
          │
          ├── Edit profile ───▶ POST /user/update-vendor/{id}
          │
          ├── Add service ────▶ POST /user/add-vendor-service
          │                     INSERT vendor_services + vendor_services_locations[]
          │
          └── Delete ─────────▶ GET /user/deleteVendor/{id}  (transactional cascade)
                                  │
                                  ▼
                       ┌──────────────────────────────────────────────────────┐
                       │ 14-statement DELETE cascade (transactional)          │
                       │                                                      │
                       │  vendor_services + vendor_services_locations         │
                       │  conversation + chat_service + chat                  │
                       │  user_reports                                        │
                       │  event_services_vendor_quote                         │
                       │  event_vendor_discount                               │
                       │  favorite_vendors                                    │
                       │  vendor_feedbacks                                    │
                       │  fcm_tokens                                          │
                       │  notification_setting                                │
                       │  call_verification                                   │
                       │  users (FINAL)                                       │
                       └──────────────────────────────────────────────────────┘
```

---

## Step-by-Step

| # | Step | Feature(s) | Endpoint / Action |
|---|------|------------|------------------|
| 1A | Vendor onboards via the public Vendor App | (OotboApps vendor + OotboAPI) | — |
| 1B | Ops creates vendor manually | [05 Vendor Mgmt](../05-vendor-management/spec.md) | `POST /user/check-vendor` → `POST /user/create-vendor` |
| 2 | Vendor profile visible in admin list with service + city filters | [05 Vendor Mgmt](../05-vendor-management/spec.md) | `GET /user/vendorlist` → DataTable AJAX |
| 3 | Admin opens detail page; sees event counts, services-with-cities | [05 Vendor Mgmt](../05-vendor-management/spec.md) | `GET /user/vendorDetails/{id}` |
| 4 | Admin adds a service (with city bindings) | [05 Vendor Mgmt](../05-vendor-management/spec.md) | `POST /user/add-vendor-service` |
| 5 | Vendor becomes discoverable in coordinator candidate dropdown | [07 Coordinator Console](../07-coordinator-console/spec.md) | `GET /coordinator/vendors/{service}/{location}/{eventid}` |
| 6 | Admin edits profile (name, email, status…) | [05 Vendor Mgmt](../05-vendor-management/spec.md) | `POST /user/update-vendor/{id}` |
| 7 | Admin deletes vendor (one click, irreversible) | [05 Vendor Mgmt](../05-vendor-management/spec.md) | `GET /user/deleteVendor/{id}` |
| 8 | Cascade purges 14 related tables in one transaction | [05 Vendor Mgmt](../05-vendor-management/spec.md) | DB transaction |

---

## Touched Tables

`users`, `vendor_services`, `vendor_services_locations`, `conversation`, `chat`, `chat_service`, `event_services_vendor_quote`, `event_vendor_discount`, `favorite_vendors`, `vendor_feedbacks`, `fcm_tokens`, `notification_setting`, `call_verification`, `user_reports`, `services`, `cities`.

---

## Failure Modes

- **Step 1B succeeds even if phone is duplicated** unless `checkVendor` was called first. The Add Vendor JS is responsible for that gate.
- **Step 7 rolls back atomically** on any single delete failure. If the schema drifts in OotboAPI (e.g. a table is renamed), the cascade silently fails on that one statement and rolls back the whole delete.
- **Step 4 has no upper bound on cities** — selecting 100 cities creates 100 rows.
- **Step 5 candidate query excludes vendors WHO ALREADY QUOTED for this event.** After Step 7 deletes a vendor's quotes, they re-appear in candidate lists.