# Cross-App Interactions — VisoAdmin ## How VisoAdmin Connects to the Rest of OOTBO VisoAdmin is **not isolated**. It writes into the same database that powers the public-facing Client and Vendor apps, and it pushes notifications through the same socket bridge. This document maps every cross-app touch-point so you can predict the blast radius of any change. --- ## Interaction Diagram ``` ┌──────────────────────────────────────────────────────────────────────────────┐ │ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Client App │ │ Vendor App │ │ │ │ (Ionic/Angular)│ │ (Ionic/Angular)│ │ │ └────────┬────────┘ └────────┬────────┘ │ │ │ │ │ │ └────────────┬───────────────────────────────┘ │ │ │ HTTPS │ │ ▼ │ │ ┌───────────────────────────────┐ │ │ │ OotboAPI │ │ │ │ (Laravel — OotboAPI/VisoAPI) │ │ │ │ Stateless, sanctum tokens │ │ │ └───────────────┬───────────────┘ │ │ │ │ │ │ SQL (shared) │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ ootbomvp (MySQL) │ │ │ │ │ │ │ │ ┌──────────┐ ┌────────────┐ ┌──────────────────────┐ │ │ │ │ │ users │ │ events │ │ client_rm_requests │ │ │ │ │ └──────────┘ └────────────┘ └──────────────────────┘ │ │ │ │ ┌──────────────────┐ ┌────────────────────┐ │ │ │ │ │ event_services │ │ event_services_ │ │ │ │ │ │ │ │ vendor_quote │ │ │ │ │ └──────────────────┘ └────────────────────┘ │ │ │ │ ┌─────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ │ │ chat │ │ chat_service │ │ conversation │ │ │ │ │ └─────────┘ └──────────────┘ └──────────────────┘ │ │ │ │ ┌─────────────────┐ ┌────────────────┐ ┌─────────┐ │ │ │ │ │ notifications │ │ user_reports │ │ admins │ │ │ │ │ └─────────────────┘ └────────────────┘ └─────────┘ │ │ │ └───────────────────────▲─────────────────────────────────┘ │ │ │ │ │ │ direct SQL (no API hop) │ │ │ │ │ ┌───────────┴─────────────┐ │ │ │ VisoAdmin │ │ │ │ (Laravel — this repo) │ │ │ └───────────┬─────────────┘ │ │ │ │ │ │ HTTP POST /notification │ │ ▼ │ │ ┌─────────────────────────┐ │ │ │ Viso-Chat │ │ │ │ (Socket server) │ │ │ │ ws:// to client/vendor│ │ │ └─────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────────────────────┘ ``` --- ## Interaction Channels VisoAdmin has **three** outbound interaction channels and **one** inbound channel. | Direction | Channel | Used For | Code | |-----------|---------|----------|------| | **Outbound** | **Direct SQL writes** to shared MySQL | RM-creates-event, vendor delete cascade, master-data CRUD, notification rows | All controllers | | **Outbound** | **HTTP POST** to `Viso-Chat` (SOCKET_URL) | Realtime "Event created" push when RM creates an event | `RmController::storeEvent()` | | **Outbound** | **Email** via SMTP | None implemented (settings tables exist but no controller dispatches mail) | — | | **Inbound** | None (no webhook / API endpoint) | — | `api.php` is empty except sanctum scaffold | --- ## Cross-App Action Matrix ### VisoAdmin Action → Effect on Client App | # | Admin Action | DB / Side-effect | What the Client App Sees | |---|--------------|-------------------|-------------------------| | 1 | **RM creates event** (`POST /rm/store-event`) | INSERT `events`, INSERT `event_services`, UPDATE `client_rm_requests`, INSERT `notifications`, POST to socket `/notification` | New event appears on client dashboard. In-app notification badge increments. | | 2 | **Admin updates event** (`PUT /event/update-event/{id}`) | UPDATE `events` (name, date, time, area, description, guest_count) | Client sees revised event detail next time the app fetches it. | | 3 | **Admin updates a service in an event** (`POST /event/updateservices`) | UPDATE `event_services` (description, expected_event_date, expected_start_time) | Client sees updated expected date/time for that service. | | 4 | **Admin updates `app_settings`** (`POST /updateSetting`) | UPDATE `app_settings` rows | Client app reads contact emails/phones from API → reflects new values. | | 5 | **Admin updates app-store links** (`POST /updateAppLinkSetting`) | UPDATE `app_settings` (host-appstore-link, host-playstore-link) | Client/vendor "rate us" / "update app" CTAs deep-link to new store URLs. | | 6 | **Admin disables a service** (`POST /service`) | UPDATE `services.status = 0` | Service stops appearing in catalogue dropdowns on both apps. | | 7 | **Admin disables a city/state/country** (`POST /location/*`) | UPDATE `cities/states/countries.status` | Location stops appearing in dropdowns. | ### VisoAdmin Action → Effect on Vendor App | # | Admin Action | DB / Side-effect | What the Vendor App Sees | |---|--------------|-------------------|-------------------------| | 1 | **RM creates event** | INSERT `events` linked via `event_services` to vendor's `services` | Matched vendors get a new lead (via OotboAPI lead-matching). | | 2 | **Admin deletes vendor** (`GET /user/deleteVendor/{id}`) | DELETE cascade across `vendor_services`, `vendor_services_locations`, `conversation`, `chat`, `chat_service`, `user_reports`, `event_services_vendor_quote`, `event_vendor_discount`, `favorite_vendors`, `vendor_feedbacks`, `fcm_tokens`, `notification_setting`, `call_verification`, `users` | Vendor permanently disappears from search/results. All their quotes, chats, and feedback are gone. | | 3 | **Admin updates vendor profile** (`POST /user/update-vendor/{id}`) | UPDATE `users` (name, email_id, alternet_number, company_name, display_name, status) | Vendor profile shows new fields on next refresh. | | 4 | **Admin adds a service to a vendor** (`POST /user/add-vendor-service`) | INSERT `vendor_services`, INSERT N×`vendor_services_locations` | Vendor becomes discoverable for that service in those cities. | | 5 | **Admin creates vendor** (`POST /user/create-vendor`) | INSERT `users` (`user_type='vendor'`, password = bcrypt(phone)) | New vendor can log in via phone-as-default-password — note: needs reset flow. | ### Client / Vendor App Action → Effect on VisoAdmin | # | App Action | DB Side-effect | What VisoAdmin Sees | |---|------------|----------------|---------------------| | 1 | **Client creates RM request** (mobile app) | INSERT `client_rm_requests` | New row appears on RM dashboard (`/rm/rm-requests`). | | 2 | **Client cancels event** | UPDATE `events.is_cancelled = 1` | Event Oversight list flags as "Cancelled Event"; Critical Events list excludes it. | | 3 | **Vendor submits quote** | INSERT `event_services_vendor_quote` | Event details page in admin shows quotes per service; `quote_count` rises. | | 4 | **Client reports vendor** | INSERT `user_reports` | Reports list (`/reports`) shows the report. | | 5 | **End user submits suggestion** | INSERT `app_suggestions` | Suggestions list (`/suggestions`) shows it. | | 6 | **End user / vendor chats** | INSERT `chat`, `chat_service`, `conversation` | Admin can read all chats via "Event Details" coordinator view. | --- ## Shared DB Tables (Read by VisoAdmin) | Table | Owned by (writer) | VisoAdmin role | |-------|-------------------|----------------| | `users` | OotboAPI + VisoAdmin | R/W (clients + vendors) | | `admins` | VisoAdmin | R/W (admin team) | | `events` | OotboAPI + VisoAdmin (RM create event) | R/W | | `event_services` | OotboAPI + VisoAdmin | R/W | | `event_services_vendor_quote` | OotboAPI | Read | | `event_vendor_discount` | OotboAPI | Read | | `client_rm_requests` | OotboAPI (client app) + VisoAdmin (RM update) | R/W | | `services` | VisoAdmin (master data) | R/W | | `countries` / `states` / `cities` | VisoAdmin (master data) | R/W | | `categories` | OotboAPI | Read (used by RM dropdown) | | `vendor_services` | OotboAPI + VisoAdmin | R/W | | `vendor_services_locations` | OotboAPI + VisoAdmin | R/W | | `chat` / `chat_service` / `conversation` | Viso-Chat + OotboAPI | Read (and delete via vendor cascade) | | `notifications` | OotboAPI + Viso-Chat + VisoAdmin | R/W | | `notification_setting` | VisoAdmin | R/W | | `user_reports` | OotboAPI (client app reports) | Read | | `app_suggestions` | OotboAPI (end users) | Read | | `app_settings` | VisoAdmin | R/W (key/value) | | `faqs` | (manual seed) | Read | | `role_permissions` | VisoAdmin | R/W | | `viso_user_activity_log` | VisoAdmin | R/W | | `fcm_tokens` / `call_verification` / `vendor_feedbacks` / `favorite_vendors` | OotboAPI | Delete-on-cascade only | --- ## Outbound HTTP — Viso-Chat Socket Bridge **Used by:** `RmController::storeEvent()` (only invocation as of writing). ``` POST {SOCKET_URL (ws → http)} /notification Body: receiverId : title : "Event created" body : "Your event '{name}' has been created by your Relationship Manager" props : { event_id, event_name } ``` `SOCKET_URL` comes from `.env`. The controller converts `ws://` → `http://` (or `wss://` → `https://`) so the socket bridge receives an HTTP POST. **Watch for trailing-slash issues** — `rtrim($url, '/')` is applied in the controller. The socket bridge then emits a WebSocket event to whichever client device is connected with that `receiverId`. If the bridge is down, the call is wrapped in a try/catch and logged — event creation still succeeds. --- ## Outbound HTTP — None to OotboAPI VisoAdmin does **not** call OotboAPI HTTP endpoints. Despite `API_URL` being set in `.env` (`http://localhost:8000/mvp`), no controller code uses `Http::*` to OotboAPI. All cross-app effects flow via shared DB writes. This is significant because: any business logic that lives only inside OotboAPI controllers (e.g. lead-matching, FCM push triggers tied to `EventModel::created` hooks) **will not run** when VisoAdmin writes the same rows directly. --- ## Auth Realm Boundary | Realm | Table | Login Surface | Token Type | |-------|-------|---------------|------------| | End users (clients + vendors) | `users` | OotboAPI (`/auth/login`, OTP) | Sanctum personal access tokens | | Ops team | `admins` | VisoAdmin (`/login`) | Laravel session cookies | These realms **do not share credentials**. An admin cannot log into the app and vice versa. There is no SSO between them. --- ## Migration / Schema Coordination - **Migrations** for shared tables (`users`, `events`, etc.) live in **`OotboAPI/VisoAPI/database/migrations`**, not here. VisoAdmin's own `database/migrations` only owns: - `admins` schema patches (`dor` column add) - `roles` table create - `role_permissions` table edit - `services.status` column type alter - `user_reports.event_id` column add - When OotboAPI changes the shape of `users`, `events`, `client_rm_requests`, etc., VisoAdmin will silently break (column-not-found errors, wrong defaults) unless its controllers are reviewed. --- ## Realtime / Push Channels | Channel | Producer | Consumer | Today? | |---------|----------|----------|--------| | Viso-Chat socket `/notification` | VisoAdmin (`RmController`) | Client app | Yes — RM event-created push | | FCM push | OotboAPI | Client + Vendor app | OotboAPI only — VisoAdmin does not push FCM | | Notification DB rows (`notifications` table) | VisoAdmin + OotboAPI + Viso-Chat | All apps + VisoAdmin badge poll | Yes | --- ## Configuration Touchpoints | Setting | Where | What Breaks If Wrong | |---------|-------|----------------------| | `SOCKET_URL` in `.env` | `RmController::storeEvent()` | RM event-created realtime push is silently lost | | `app_settings` key-value rows | All apps + VisoAdmin | Contact emails / phones / app-store links show stale values | | `viso.clientfaq` / `viso.vendorfaq` (`config/viso.php`) | `FaqController` | FAQ image URLs 404 | | AWS S3 creds | `.env` | Vendor image uploads from app fail (VisoAdmin reads these images for display) |