spikerj/spikersoft-issues
1
0
Fork 0
Code Issues 196 Pull Requests Actions Packages Projects Releases Wiki Activity

[Bug] Registration / Verify account: SMS code field stays disabled after email verified (mdc-text-field--disabled) #10

New Issue
Closed
opened 2026-04-26 18:37:21 +00:00 by spikerj · 2 comments
spikerj commented 2026-04-26 18:37:21 +00:00
Owner
Copy Link
Copy Source

Environment

  • URL: learn.spikersoft.com — Verify Your Account flow (registration stepper: Basic → SMS → Password → Verify).
  • Observed: Email shows Verified (green checkmarks, “Verified” on email action). SMS Verification Code* text field remains greyed out / not focusable.
  • DevTools: The Material field has class mdc-text-field--disabled on the host (disabled form control, not just styling).

Expected

After email is verified, the user can enter the SMS verification code in the SMS field (or the UI clearly explains a single required action, e.g. only “Send Code” first, without blocking data entry permanently).

Actual

  • Email verification appears complete in the UI.
  • SMS Verification Code* stays disabled, so the code cannot be typed.
  • Status copy can still imply SMS is waiting on email verification (inconsistent with email already verified).
  • Red banner: “Invalid data provided. Please check your information.”
  • Optional header chips: Client verified / Server verified (per screenshot).

Likely code area (for devs)

spikersoft-angular/projects/spikersoft/src/app/_components/registration-stepper/registration-stepper.component.ts

  • An effect() keeps the smsCode form control disabled when phoneVerified() || smsCodeExpired() || **!smsSent()** (see comments around the SMS / email verification effects).
  • If emailVerified() is true but smsSent() never becomes true (HTTP vs SignalR timing, conflict recovery, or failed resend), the input stays disabled — matches mat-form-field showing mdc-text-field--disabled.
  • Related comment in the same file: SignalR vs resendSmsCode() HTTP 400 can surface as “Invalid data provided” with SMS stuck; worth reproducing with network tab + SignalR connection state.

Suggested QA follow-up

  1. Reproduce on learn.spikersoft.com after clearing site data or using a fresh pending registration.
  2. Confirm whether Send Code was pressed and whether API returns success for SMS send.
  3. Capture Network + Console + whether SignalR connected for the pre-registration hub.

Labels: bug, frontend, registration (add in Gitea if available)

## Environment - **URL:** `learn.spikersoft.com` — **Verify Your Account** flow (registration stepper: Basic → SMS → Password → Verify). - **Observed:** Email shows **Verified** (green checkmarks, “Verified” on email action). **SMS Verification Code\*** text field remains **greyed out / not focusable**. - **DevTools:** The Material field has class **`mdc-text-field--disabled`** on the host (disabled form control, not just styling). ## Expected After email is verified, the user can **enter the SMS verification code** in the SMS field (or the UI clearly explains a single required action, e.g. only “Send Code” first, without blocking data entry permanently). ## Actual - Email verification appears complete in the UI. - **SMS Verification Code\*** stays **disabled**, so the code cannot be typed. - Status copy can still imply SMS is waiting on email verification (inconsistent with email already verified). - Red banner: **“Invalid data provided. Please check your information.”** - Optional header chips: **Client verified** / **Server verified** (per screenshot). ## Likely code area (for devs) `spikersoft-angular/projects/spikersoft/src/app/_components/registration-stepper/registration-stepper.component.ts` - An `effect()` keeps the **`smsCode` form control disabled** when `phoneVerified() || smsCodeExpired() || **!smsSent()**` (see comments around the SMS / email verification effects). - If **`emailVerified()` is true** but **`smsSent()` never becomes `true`** (HTTP vs SignalR timing, conflict recovery, or failed resend), the input stays disabled — matches `mat-form-field` showing `mdc-text-field--disabled`. - Related comment in the same file: SignalR vs `resendSmsCode()` **HTTP 400** can surface as **“Invalid data provided”** with SMS stuck; worth reproducing with network tab + SignalR connection state. ## Suggested QA follow-up 1. Reproduce on `learn.spikersoft.com` after clearing site data or using a fresh pending registration. 2. Confirm whether **Send Code** was pressed and whether API returns success for SMS send. 3. Capture **Network** + **Console** + whether **SignalR** connected for the pre-registration hub. --- **Labels:** `bug`, `frontend`, `registration` *(add in Gitea if available)*
issue-sms.png
202 KiB
issue-sms.png
spikerj commented 2026-05-05 04:04:04 +00:00
Author
Owner
Copy Link
Copy Source

Triage: Mostly fixed -- The registration flow's verify-email REST path has been reviewed. The core SMS/email verification logic appears functional. There may be a residual edge case in the REST verify-email path that needs live reproduction testing to confirm.

**Triage: Mostly fixed** -- The registration flow's `verify-email` REST path has been reviewed. The core SMS/email verification logic appears functional. There may be a residual edge case in the REST verify-email path that needs live reproduction testing to confirm.
spikerj commented 2026-06-15 16:51:59 +00:00
Author
Owner
Copy Link
Copy Source

Found and fixed the remaining REST-path stuck-disabled case in spikersoft-angular PR #58.

The SMS field's disable effect keys off !smsSent(). The SignalR email-verified path optimistically sets smsSent=true (the backend auto-dispatches the SMS when it marks email verified), but the REST verifyEmail handler only set it when response.smsSent was truthy — and the REST response doesn't always echo that flag, so the field stayed mdc-text-field--disabled with no way to type the code. PR #58 makes the REST path mirror the SignalR path (optimistic smsSent=true + start timer + latch signalREmailVerifiedHandled) when email is verified and phone isn't yet. The Resend button stays available as a fallback. Added a regression test. nx test spikersoft --filter=RegistrationStepperComponent → 58 pass. Will close once PR #58 merges.

Found and fixed the remaining REST-path stuck-disabled case in `spikersoft-angular` PR #58. The SMS field's disable effect keys off `!smsSent()`. The SignalR email-verified path optimistically sets `smsSent=true` (the backend auto-dispatches the SMS when it marks email verified), but the REST `verifyEmail` handler only set it when `response.smsSent` was truthy — and the REST response doesn't always echo that flag, so the field stayed `mdc-text-field--disabled` with no way to type the code. PR #58 makes the REST path mirror the SignalR path (optimistic `smsSent=true` + start timer + latch `signalREmailVerifiedHandled`) when email is verified and phone isn't yet. The Resend button stays available as a fallback. Added a regression test. `nx test spikersoft --filter=RegistrationStepperComponent` → 58 pass. Will close once PR #58 merges.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agentic
Actionable surfaced by the agentic architecture & security review
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 sonarqube
Code quality issue surfaced by SonarQube (bug / code smell)
 wontfix
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
spikerj (Joseph Spiker)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#10