fix(ui): UserProfile should show attributes enabled for sign in#8042
fix(ui): UserProfile should show attributes enabled for sign in#8042dmoerner wants to merge 10 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: af31b7f The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
…ributes-enabled-for-sign-in
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Repository UI (inherited) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThis PR modifies UserProfile components to display disabled user attributes when they are configured as first or second factor authentication requirements, by introducing an ChangesDisplay disabled attributes used for sign-in
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
Comment |
| const showUsername = attributes.username?.enabled; | ||
| const showEmail = attributes.email_address?.enabled; | ||
| const showPhone = attributes.phone_number?.enabled; | ||
| const showUsername = isAttributeAvailable(attributes.username); |
There was a problem hiding this comment.
What do you think about moving this availability logic to a computed property on AttributeData objects rather than a standalone utility function. UserSettings already has getters for pre-computed properties so it's an established pattern and it keeps the responsibility close to the data object
There was a problem hiding this comment.
Reasonable suggestion. I did this in 8f1e53b :). Thanks!
There was a problem hiding this comment.
Coming back to this after a closer look, I have to walk back my suggestion: your original version was right, and moving it onto UserSettings creates a cross-bundle hazard I missed. ui.browser.js and clerk.browser.js load independently (both float on their major tags, and apps can pin clerkJSVersion), so a new ui can run against a clerk-js that doesn't have the getter yet. In that pairing userSettings.availableAttributes is undefined, the .includes() calls throw on first render, and since all components share one React root, the whole Clerk UI unmounts. The attribute data is safe to read across bundles (it comes from FAPI and older clerk-js copies it as-is); prototype getters are not.
To keep this moving I pushed af31b7f, which reverts 8f1e53b and the prettier follow-up, restoring your isAttributeAvailable helper. All tests pass unchanged and the changeset is right as-is (so disregard my comment there too). Your JSDoc on the helper also answered "available for what?" better than a getter on the public UserSettings contract could, and it keeps password off that surface, which USER-4904 explicitly warns about.
I filed SDK-115 to track the skew problem generally, since this pattern turned out to be very easy to fall into. Sorry for the round trip!
|
Deployment failed with the following error: View Documentation: https://vercel.com/docs/two-factor-authentication |
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/expo
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
…ributes-enabled-for-sign-in
|
Hello 👋 We currently close PRs after 60 days of inactivity. It's been 50 days since the last update here. If we missed this PR, please reply here. Otherwise, we'll close this PR in 10 days. Thanks for being a part of the Clerk community! 🙏 |
…ributes-enabled-for-sign-in
API Changes Report
Summary
No API Changes DetectedAll packages have stable APIs with no detected changes. Report generated by Break Check Last ran on |
…ings getter Reverts 8f1e53b and e848ffc, restoring the original isAttributeAvailable helper in the UserProfile utils. ui.browser.js and clerk.browser.js are loaded independently (floating major tags, pinnable clerkJSVersion), so @clerk/ui can run against a clerk-js that does not have the availableAttributes getter; the unguarded .includes() calls would then crash every mounted Clerk component. The attribute data itself is FAPI-provided and safe to read across bundle versions. See SDK-115.
Description
Our Dashboard supports instance configurations with email, phone, or username used for sign in, but not used for sign up. This can be useful in cases where accounts are pre-provisioned by the backend, or where users can only add identifiers after sign up. Internally, we represent this as
{"enabled": false, "used_for_first_factor": true}.The UserProfile currently guards the display of these identifiers behind
enabled, which actually maps on to "enabled for sign up". Correct these guards to check for whether the attribute is used for first or second factor sign in as well.This allows users to both add and also verify these identifications. Email link verification has an additional guard which also requires adjustment.
Fixes USER-4904.
This is an instance with username, email, and phone enabled only for sign in. The user can still add and change them.
Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change
Summary by CodeRabbit