The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 23, 2026 6:39pm

PR Summary

Low Risk
Low risk UI-only change that repositions an existing success message; no auth flow, data handling, or API behavior is modified.

Overview
Moves the "password reset successful" banner (resetSuccessMessage) from above the login form to inside the form, placing it near other form-level messages (e.g., captcha/login errors) directly above the submit button.

^{Written by Cursor Bugbot for commit 81bf7f4. Configure here.}

Greptile Summary

This PR fixes a UI placement bug where the "Password reset successful" message appeared above the email/password form (between the header and the email field) instead of near the submit button where contextual form feedback belongs.

• Removes the resetSuccessMessage block that was rendered outside the <form> element, above the email/password section.
• Re-adds the same message block inside the <form>, just above the existing formError message and the submit button — consistent with how other form-level feedback (captcha errors, etc.) is displayed.
• Minor class simplification: the outer div no longer carries mt-1 space-y-1, which were redundant for a single <p> child; space-y-8 on the form handles spacing naturally.
• Edge case to be aware of: the success message is now gated behind the !isFalsy(getEnv('NEXT_PUBLIC_EMAIL_PASSWORD_SIGNUP_ENABLED')) check that wraps the entire <form>. If email/password auth is disabled, the message will never render. In practice this is not a real concern because password reset requires email auth to be enabled, but it is a behavioral change worth noting.

Confidence Score: 5/5

• This PR is safe to merge — it is a focused, low-risk UI placement fix with no logic changes.
• The change is minimal (12 lines removed, 6 lines added) and only affects where a success message is rendered. No logic, state, or API behavior is modified. The edge case where the message is now gated behind the email-auth feature flag is not a realistic concern because password reset inherently requires email auth to be enabled.
• No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[LoginPage renders] --> B{resetSuccessMessage set?}
    B -- Yes (Old) --> C["Render success msg ABOVE form\n(between header and email field)"]
    B -- Yes (New) --> D{Email/password form enabled?}
    B -- No --> D
    D -- Yes --> E[Render email/password form]
    E --> F["Render success msg INSIDE form\n(above submit button)"]
    F --> G[Render Submit Button]
    D -- No --> H[Form hidden — success msg also hidden]

_{Reviews (1): Last reviewed commit: "fix(login): move password reset success ..." | Re-trigger Greptile}