# Onboarding / Auth — UI Screens & States

## Screen inventory

| Demo screen | Demo file | Our view | Status |
|---|---|---|---|
| Login | `portals/onboarding/Login.tsx` | `frontend/views/sign-in/login.php` | present |
| Sign-up | `portals/onboarding/SignUp.tsx` | `frontend/views/sign-in/signup.php` (830 lines) | present |
| OTP entry | `portals/onboarding/OtpEntry.tsx` | `frontend/modules/user/views/sign-in/verify-activation-otp.php` (630 lines) | present |
| Set password | `portals/onboarding/SetPassword.tsx` | **none** | MISSING |
| Activate-email | `portals/onboarding/ActivateEmail.tsx` | emailed token link (no on-screen email) | MISSING (different model) |
| Activation status (rejected/pending) | demo `'inactive'` route | `frontend/controllers/SiteController.php:155 actionActivationStatus` | present (ours) |

## 1. Login
**Demo**: centered card, brand icon tile, title + subtitle, email + password fields,
full-width primary button (disabled until both non-empty), "no account? Sign up" link.
On bad creds -> warning toast.

**Ours**: `login.php` form with username/email + password + remember-me. Aurora-reskinned.
Adds **brute-force lockout messaging** and activation errors as field errors (not toasts).
Gaps vs demo: demo's exact icon-tile header + the simple "no account" inline link;
ours uses Yii flash/Growl alerts instead of the demo toast pattern. Functionally complete.

## 2. Sign-up
**Demo**: two sections — **Store Details** (marketing name + hint, store-type select
men/women/all, service-category **multi-select chips**) and **Account Manager Details**
(full name, mobile with sticky **+966** adornment and digit-only input, email, password
with **live strength meter**, confirm password with inline mismatch error, accept-terms
checkbox, accept-privacy checkbox). Submit disabled until all gates pass. On submit ->
toast + **ConfirmationPanel** ("submitted, pending review", link to sign-in). No redirect.

**Ours**: `signup.php` collects equivalent fields: `commercial_name`, `gender` (store
type), `category_ids` via **Select2 multi-select** (not chips), `fullname`, `owner_mobile`
with +966 prefix label, `email`, `password` via **kartik PasswordInput (has its own
strength meter)**, `password_confirm`, terms checkbox, privacy checkbox.

Concrete UI gaps:
- **No in-page confirmation panel** — ours redirects home with a flash and **auto-logs in**.
  Demo stays on the form and swaps to a success panel.
- Service categories are a **Select2 dropdown**, not the demo's pill/chip toggles.
- Strength meter exists (kartik widget) but the **thresholds/labels differ** from the
  demo's 30/60/80 weak/fair/good/strong scoring (`SignUp.tsx:18-43`).
- Privacy checkbox is rendered but **not server-validated** (not in `SignupForm::rules`,
  only `terms_conditions` is required) — demo gates submit on **both** boxes.
- Store-type select: demo `men/women/all`; ours maps to `GENDER_MALE/FEMALE/ALL`.

## 3. OTP entry
**Demo**: icon tile + title/subtitle, **demo-hint chip showing the actual 4-digit code**,
single numeric input (`maxLength 4`, centered, wide letter-spacing), inline red error on
invalid, submit disabled until 4 digits.

**Ours**: `verify-activation-otp.php` — full custom OTP screen with **6-digit** entry,
error state, **resend OTP** button with cooldown, and an empty/no-token state
(`user=null`). Richer than the demo. The demo hint chip is intentionally absent (prod
security). Empty/error/RTL all handled (Arabic copy throughout).

## 4. Set password — **MISSING**
**Demo** `SetPassword.tsx`: icon tile, title/subtitle, password + strength meter, confirm
with mismatch error, submit -> `/login`. There is **no equivalent owner-facing screen** in
our app because owners always set a password at signup. Closest analog is
`resetPassword.php` (token-driven, different entry point) and `account.php` (logged-in
edit). If the demo's admin-creates-owner-without-password path is adopted, this screen must
be built.

## 5. Activate-email — MISSING as a screen
**Demo** `ActivateEmail.tsx` renders a faux email card (from/subject/body + shop name) with
an "Authenticate" button, plus a guard state ("nothing to activate" + back-to-login). Ours
sends a **real email with a signed activation link** (`SignInController.php:419-491`); the
"screen" is the user's inbox, and clicking the link lands directly on the OTP screen. So
the visual screen has no parity, but the underlying step is covered more securely.

## RTL / i18n
- Demo uses `useT()` keys under `onboarding.*` and logical CSS props (`border-e`,
  `text-start`) for RTL.
- Ours: bilingual via `Yii::t('frontend'|'backend', ...)`, Arabic-first copy hard-baked in
  several places (e.g. activation success flash `SignInController.php:457`). RTL handled by
  the aurora layout. Several strings are **Arabic-only literals** rather than translated
  keys (e.g. signup cancel-terms blob `SignupForm.php:159-174`), which is acceptable for
  fixed legal text but is not bilingual-symmetric.