fix(OPENFRAM-002): CU-86akhf8u5 AuthLoginSectionProps declares onEmailPasswordLogin, tenantInfo, hasDiscoveredTenants, email but component ignores them - #399
Conversation
…n, tenantInfo, hasDiscoveredTenants, email but component ignores them
![flamingo[bot]](https://avatars.githubusercontent.com/in/3426709?s=60&v=4){kind=small}
| /** | ||
| * Modern login section with SSO providers and email/password option | ||
| */ | ||
| export function AuthLoginSection({ availableProviders, onSso, onBack, isLoading }: AuthLoginSectionProps) { | ||
| export function AuthLoginSection({ | ||
| email, | ||
| tenantInfo, | ||
| hasDiscoveredTenants, | ||
| availableProviders, | ||
| onSso, | ||
| onBack, | ||
| isLoading, | ||
| onEmailPasswordLogin, | ||
| }: AuthLoginSectionProps) { | ||
| const [loginMethod, setLoginMethod] = useState<'sso' | 'email'>('sso'); | ||
| const [password, setPassword] = useState(''); | ||
|
|
||
| // Separate the built-in OpenFrame login from standard providers. | ||
| // The backend reports it as 'openframe'; 'openframe-sso' is the legacy id. |
There was a problem hiding this comment.
🦩 🟠 AuthLoginSectionProps declares onEmailPasswordLogin, tenantInfo, hasDiscoveredTenants, email but component ignores them
Fixed the interface/behavior drift in AuthLoginSection (src/app/(auth)/auth/components/login-section.tsx). Destructured email, tenantInfo, hasDiscoveredTenants, and onEmailPasswordLogin from props instead of ignoring them. tenantInfo/hasDiscoveredTenants are now rendered as a "signing in to " hint in the header. onEmailPasswordLogin now drives a new password-entry form (with local password state and a submit handler handleEmailPasswordSubmit) that appears whenever the prop is supplied, calling onEmailPasswordLogin(email, password) and reusing the existing isLoading/loginMethod state for the loading indicator. This is a judgment call on UI/markup (input styling, form placement) since no design spec was given for the email/password fallback — a reviewer should confirm the visual treatment matches the rest of the auth flow, and that passing email in from the parent (rather than letting the user type it here) is the intended UX given the field is read-only in this component.
🤖 Prompt for AI agents
In src/app/(auth)/auth/components/login-section.tsx around line 18, review and complete this code-review fix: AuthLoginSectionProps declares onEmailPasswordLogin, tenantInfo, hasDiscoveredTenants, email but component ignores them.
What the draft fix changed: Fixed the interface/behavior drift in `AuthLoginSection` (src/app/(auth)/auth/components/login-section.tsx). Destructured `email`, `tenantInfo`, `hasDiscoveredTenants`, and `onEmailPasswordLogin` from props instead of ignoring them. `tenantInfo`/`hasDiscoveredTenants` are now rendered as a "signing in to <tenant>" hint in the header. `onEmailPasswordLogin` now drives a new password-entry form (with local `password` state and a submit handler `handleEmailPasswordSubmit`) that appears whenever the prop is supplied, calling `onEmailPasswordLogin(email, password)` and reusing the existing `isLoading`/`loginMethod` state for the loading indicator. This is a judgment call on UI/markup (input styling, form placement) since no design spec was given for the email/password fallback — a reviewer should confirm the visual treatment matches the rest of the auth flow, and that passing `email` in from the parent (rather than letting the user type it here) is the intended UX given the field is read-only in this component.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.
fix confidence: 🔴 55 low — review closely — react 👍/👎 to teach the reviewer
flamingo
Bot
changed the title
1 participant
Closes findings from rule OPENFRAM-002 — AuthLoginSectionProps declares onEmailPasswordLogin, tenantInfo, hasDiscoveredTenants, email but component ignores them.
Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.
src/app/(auth)/auth/components/login-section.tsx:18What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.
Run: https://product-hub.flamingo.so/admin/code-review
Run id:
c69bf2d8-6eaa-4e2d-815b-af08b880c8dfMerging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.
ClickUp task: CU-86akhf8u5 OpenFrame OSS frontend review findings sweep (12 PRs)