Prevent future dates for Date of Birth in registration and user profile forms - #10558
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughChangesThe pull request adds strict Date of Birth validation
Suggested reviewers: 🚥 Pre-merge checks | ✅ 6✅ Passed checks (6 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@identity-apps-core/react-ui-core/src/components/adapters/date-field-adapter.js`:
- Around line 32-33: Update the DOB validation messages represented by
DOB_FORMAT_ERROR and DOB_FUTURE_DATE_ERROR to use the existing translation path
used by other user-facing text in the date-field adapter. Preserve their current
meanings and validation behavior while ensuring both messages are localized for
the active locale.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: c1d50149-45db-4f95-b02d-0d54bc686133
📒 Files selected for processing (7)
.changeset/tidy-months-tell.mdfeatures/admin.users.v1/components/user-profile/fields/form-field-renderer.tsxfeatures/admin.users.v1/components/user-profile/legacy-user-profile-form.tsxfeatures/admin.users.v1/components/wizard/steps/legacy-add-user-basic.tsxidentity-apps-core/apps/recovery-portal/src/main/resources/org/wso2/carbon/identity/mgt/recovery/endpoint/i18n/Resources.propertiesidentity-apps-core/apps/recovery-portal/src/main/webapp/self-registration-username-request.jspidentity-apps-core/react-ui-core/src/components/adapters/date-field-adapter.js
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #10558 +/- ##
==========================================
+ Coverage 72.85% 73.46% +0.61%
==========================================
Files 470 471 +1
Lines 71238 71449 +211
Branches 240 266 +26
==========================================
+ Hits 51902 52492 +590
+ Misses 19225 18850 -375
+ Partials 111 107 -4 🚀 New features to boost your workflow:
|
The date field adapter special-cased the DOB claim URI to add format and future-date checks, so any other date claim configured with the same rules would get no validation at all, and the DOB check couldn't be reused or reconfigured without editing this component again. Move the rule interpretation into the shared field-validation hook as a generic DateValidator case (real-date + disallow.future conditions), and have the adapter derive its calendar constraints (max date, date format) from whatever DateValidator rule the field was actually given, rather than from a hardcoded claim URI check. The adapter now activates automatically for any date field the server attaches a DateValidator rule to (see the companion carbon-identity-framework change that authors this rule from claim metadata).
admin.users.v1 changes are bundled into the console app, so console needs a version bump too, per review feedback on PR wso2#10558.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@identity-apps-core/react-ui-core/src/utils/validation-utils.js`:
- Around line 44-47: Update parseIsoDate’s date construction to preserve
four-digit years below 0100: create the date without relying on the
multi-argument constructor’s 1900 offset, then apply the parsed year with
setFullYear(). Keep the existing component validation unchanged so inputs such
as 0099-01-01 are accepted only when valid.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro Plus
Run ID: 7fcf40ef-ae35-4716-b965-d1a5db21cea3
📒 Files selected for processing (5)
.changeset/tidy-months-tell.mdidentity-apps-core/react-ui-core/src/components/adapters/date-field-adapter.jsidentity-apps-core/react-ui-core/src/components/validation-criteria.jsidentity-apps-core/react-ui-core/src/hooks/use-field-validations.jsidentity-apps-core/react-ui-core/src/utils/validation-utils.js
🚧 Files skipped from review as they are similar to previous changes (1)
- .changeset/tidy-months-tell.md
new Date(year, month, day) maps a 2-digit year (0-99) to 1900+year, so a valid string like "0099-01-01" would round-trip to 1999 and get rejected as invalid. Build the date with setFullYear() instead, which does not apply that offset. Addresses a CodeRabbit review comment on PR wso2#10558.
Purpose
The Date of Birth (
http://wso2.org/claims/dob) attribute accepts a future date during self-registration and during admin user creation/editing, but the My Account profile page rejects future dates. This inconsistency lets invalid DOB values (for example2027-04-20) be stored, while the same value is blocked when the user later edits their profile in My Account.This PR makes the Date of Birth validation consistent across all end-user and admin UIs by rejecting:
YYYY-MM-DDpattern but are not real calendar dates (for example2025-02-30).Changes
Classic self-registration page —
identity-apps-core/apps/recovery-portal/.../self-registration-username-request.jspshowDateOfBirthValidationStatus()now checks, after the existing format regex, that the value is an existing calendar date and is not in the future.dob.cannot.be.future.dateto the base resource bundle.Dynamic registration flow date field —
identity-apps-core/react-ui-coreuse-field-validations.jsgained a genericDateValidatorrule case (real-date +disallow.futureconditions), with a matching label invalidation-criteria.jsand shared date helpers invalidation-utils.js.date-field-adapter.jsno longer knows about DOB at all — it derivesmaxDateanddateFormatfrom whicheverDateValidatorrule the field'svalidationsconfig carries, so the calendar and inline error activate for any date claim configured this way, not just DOB.DateValidatorrule to the field, which is what the companion carbon-identity-framework change does for the DOB claim (see Related PRs).Console user management —
features/admin.users.v1/...form-field-renderer.tsx: added a dedicated DOB validator (required → regex → strict date parse → future check) used by both the text and date-picker branches. The DOB branch previously used the generic validator despite a comment claiming a special one.legacy-user-profile-form.tsxandwizard/steps/legacy-add-user-basic.tsx: extended the DOB validation callbacks with the strict-parse and future-date checks.dayjs/plugin/customParseFormatplugin so impossible dates are rejected.Related PRs
Testing
2027-04-20, tomorrow, today (allowed), valid/invalid leap days, impossible dates, and wrong-order formats — all behave as expected.