(fix) O3-5272:Add validation for contact details address fields by praneeth622 · Pull Request #2180 · openmrs/openmrs-esm-patient-management

praneeth622 · 2025-12-23T17:38:34Z

Requirements

This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
My work is based on designs, which are linked or shown either in the Jira ticket or the description below.
My work includes tests or is validated by existing tests.

Summary

This PR adds proper validation for address fields in the patient registration form's Contact Details section to fix O3-5272.

Problem: Previously, the Contact Details address fields (City/Village, State/Province, Country, Postal Code) accepted invalid input without any validation. Users could enter numeric-only values like 12345 for State, special characters like india123#$ for City, or invalid characters in Postal Code like 503144ferge#$, and the form would save successfully.

Solution: Implemented comprehensive validation rules for address fields:

Validation Rules Added:

City/Village, State/Province, Country, County/District:

✅ Accepts: Letters (including international Unicode characters like Khmer, Arabic, Chinese), spaces, hyphens, apostrophes, periods, parentheses
❌ Rejects: Numeric-only values (e.g., 12345), special characters (e.g., city#$%)
Examples of valid input: New York, São Paulo, O'Brien, Saint-Denis, កំពង់ចាម, Guinea-Bissau

Postal Code:

✅ Accepts: Alphanumeric characters, spaces, hyphens to support international postal code formats
❌ Rejects: Invalid special characters
Examples of valid input: 12345, 12345-6789 (US), SW1A 1AA (UK), K1A 0B1 (Canada)

Key Features:

All address fields remain optional (no change to existing behavior)
Validation only triggers when user enters data
Inline validation messages guide users to correct errors
Form submission prevented until validation errors are resolved
International character support using Unicode property escapes (\p{L})

Test Coverage:

Added 25+ comprehensive test cases in patient-registration-validation.test.ts
Tests cover:
- Valid inputs (letters, international characters, proper punctuation)
- Invalid inputs (numeric-only, special characters)
- Edge cases (hyphens, apostrophes, periods, spaces, parentheses)
- International postal code formats
- Empty/optional field handling
- Multiple validation errors
✅ All tests passing (136 tests total in patient-registration suite)

Screenshots

Before:

Form accepted invalid input without validation:

After:

Validation errors displayed for invalid input:

Test Case 1: Numeric-only State

Input: State = 12345
Result: ❌ Validation error: "State must contain only letters"

Test Case 2: Special characters in City

Input: City = india123#$
Result: ❌ Validation error: "City must contain only letters"

Test Case 3: Invalid Postal Code

Input: Postal Code = 503144ferge#$
Result: ❌ Validation error: "Postal code can only contain letters, numbers, spaces, and hyphens"

Test Case 4: Valid International Input

Input: City = កំពង់ចាម (Khmer), State = São Paulo (Portuguese), Postal Code = SW1A 1AA (UK format)
Result: ✅ All fields accepted

Related Issue

Fixes : #O3-5272

https://openmrs.atlassian.net/browse/O3-5272

Part of Epic: https://openmrs.atlassian.net/browse/O3-4257 (React Form Engine v4)

- Add validation for city/village, state/province, and country fields to reject numeric-only input and special characters - Add validation for postal code to support international formats (alphanumeric with spaces and hyphens) - Reject invalid characters while supporting international Unicode characters (Khmer, Arabic, etc.) - Add 25+ comprehensive test cases covering valid/invalid inputs - All address fields remain optional but validate when data is entered - Support common punctuation (hyphens, apostrophes, periods, parentheses) Fixes: https://openmrs.atlassian.net/browse/O3-5272

Copilot

Pull request overview

This PR adds comprehensive validation for address fields in the patient registration form's Contact Details section to prevent invalid input. The implementation adds Yup validation rules for city/village, state/province, country, county/district, and postal code fields.

Key changes include:

Validation rules for geographic address fields (city, state, country, county/district) that allow Unicode letters, spaces, hyphens, apostrophes, periods, and parentheses
Postal code validation supporting international formats (alphanumeric, spaces, hyphens)
25+ test cases covering valid inputs, invalid inputs, edge cases, and international formats

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 12 comments.

File	Description
`packages/esm-patient-registration-app/src/patient-registration/validation/patient-registration-validation.ts`	Adds Yup validation schema for address fields with regex patterns to validate city, state, country, county/district, and postal code inputs
`packages/esm-patient-registration-app/src/patient-registration/validation/patient-registration-validation.test.ts`	Adds comprehensive test suite with 25+ test cases covering valid/invalid inputs, international characters, and edge cases for all address fields

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

...registration-app/src/patient-registration/validation/patient-registration-validation.test.ts

...ient-registration-app/src/patient-registration/validation/patient-registration-validation.ts

...registration-app/src/patient-registration/validation/patient-registration-validation.test.ts

...ient-registration-app/src/patient-registration/validation/patient-registration-validation.ts

- Update validation error messages to accurately reflect allowed characters (periods and parentheses) - Remove redundant Khmer Unicode range (\u1780-\u17FF) from regex patterns as \p{L} already covers all Unicode letters - Simplify regex patterns to /^[\p{L}\s\-'.()]+$/u for better maintainability - Add missing test cases: * City/village with parentheses * State/province with parentheses * Country with periods (e.g., U.S.A.) * Country with parentheses * County/district with periods, apostrophes, and parentheses (e.g., St. Mary's County) - Update all test expectations to match new error messages - Total test cases now: 30+ covering all edge cases All suggestions from GitHub Copilot review have been addressed.

- Add \p{M} (Unicode combining marks) to all address field regex patterns - This fixes validation for scripts that use combining characters like: * Khmer (e.g., កម្ពុជា uses combining marks like ្, ុ, ា) * Arabic (diacritical marks) * Hebrew (vowel points and cantillation marks) - Pattern now: /^[\p{L}\p{M}\s\-'.()]+$/u - Ensures international address validation works properly - All tests passing (48 validation tests + 3 integration tests)

gitcliff · 2025-12-24T06:59:55Z

...ient-registration-app/src/patient-registration/validation/patient-registration-validation.ts

+          (value) => {
+            if (!value) return true; // Allow empty values since field is optional
+            // Allow alphanumeric characters, spaces, and hyphens to support international postal codes
+            return /^[A-Za-z0-9\s\-]+$/.test(value);


@praneeth622 Do we want postal codes to support international alphanumeric formats, or should this be numeric-only as per the PR requirement ? Current validation supports the former.

gitcliff · 2025-12-24T07:13:06Z

...ient-registration-app/src/patient-registration/validation/patient-registration-validation.ts

+          },
+        ),
+      country: Yup.string()
+        .optional()


@praneeth622 The fields being optional only allows them to be empty. If a value is entered, invalid formats should still trigger validation and prevent saving, which doesn’t seem to be enforced currently

praneeth622 · 2025-12-24T09:21:28Z

Thanks for the review, @gitcliff 👍

Postal code format
The current implementation supports international alphanumeric postal codes. I chose this since OpenMRS is used globally, but I agree we should align strictly with the expectation for this issue.
Please confirm whether the desired behavior is:

numeric-only postal codes, or
international alphanumeric formats.

I’m happy to update the validation accordingly.

Optional field validation
You’re right — optional should only allow empty values. If a value is provided, invalid formats must block saving.
I’ll tighten the validation logic to ensure that:

empty values pass, and
any non-empty but invalid input correctly triggers a validation error and prevents submission.

I’ll push an update once the expected postal code format is confirmed. Thanks!

WorrierKhushal · 2026-02-01T21:08:07Z

Hello, I’ve reviewed this issue and understood the validation requirements for the address fields (City, State, Country, and Postal Code).

I plan to handle this by applying proper regex-based validation for international characters, allowing optional fields while blocking invalid inputs, and ensuring the form does not submit when values are incorrect.

I’d be happy to work on this — could you please assign the issue to me?
Thank you!

WorrierKhushal · 2026-02-02T05:34:38Z

Hi, just following up on this. I’ve already prepared the fix and tests locally and I’m ready to submit as soon as
I’m assigned.Thank you!

jayasanka-sack

Thanks for the PR, @praneeth622. really appreciate you digging into this!

Just to share a bit more context: the address fields in OpenMRS are configurable. That means they’re dynamically loaded based on something called Address Templates. Ex: one implementation might include a “Postal Code” field, while another might not. It all depends on how the template is defined.

The good news is that validation rules can also be defined within the same template. (However the default template we’re currently using doesn’t include any regex-based validation rules, but it can be configured openmrs/openmrs-core@12b454b/api/src/main/java/org/openmrs/util/OpenmrsConstants.java#L380).

Read more on Address Templates:
openmrs.atlassian.net/wiki/spaces/docs/pages/25471961/Administering+Address+Templates

As a next step for this PR, we’ll want to confirm whether the frontend currently supports dynamic validation rules for address fields. If it doesn’t we’ll need to add support for that so it aligns with how address templates are configured.

Keep up the good work. You are doing great! 💛

praneeth622 · 2026-02-12T11:41:44Z

Thanks for the clarification @jayasanka-sack . I now understand that address fields are template-driven and validation rules may be defined in elementRegex. I’ll investigate whether frontend supports dynamic validation from address templates and propose an aligned solution.

Copilot AI review requested due to automatic review settings December 23, 2025 17:38

Copilot started reviewing on behalf of praneeth622 December 23, 2025 17:38 View session

Copilot AI reviewed Dec 23, 2025

View reviewed changes

praneeth622 added 2 commits December 23, 2025 23:27

gitcliff changed the title ~~O3-5272 : Add validation for contact details address fields~~ (fix) O3-5272:Add validation for contact details address fields Dec 24, 2025

gitcliff reviewed Dec 24, 2025

View reviewed changes

Merge branch 'main' into fix/o3-1521-patient-details-triple-render

bb44418

praneeth622 added 2 commits February 2, 2026 16:20

Merge branch 'main' into fix/o3-1521-patient-details-triple-render

ba6daf6

Merge branch 'main' into fix/o3-1521-patient-details-triple-render

a290c6b

jayasanka-sack requested changes Feb 12, 2026

View reviewed changes

Merge branch 'main' into fix/o3-1521-patient-details-triple-render

9c36c57

Conversation

praneeth622 commented Dec 23, 2025 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Requirements

Summary

Validation Rules Added:

Test Coverage:

Screenshots

Before:

After:

Related Issue

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gitcliff Dec 24, 2025

Choose a reason for hiding this comment

Uh oh!

gitcliff Dec 24, 2025

Choose a reason for hiding this comment

Uh oh!

praneeth622 commented Dec 24, 2025

Uh oh!

WorrierKhushal commented Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WorrierKhushal commented Feb 2, 2026

Uh oh!

jayasanka-sack left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

praneeth622 commented Feb 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

praneeth622 commented Dec 23, 2025 •

edited by atlassian bot

Loading

WorrierKhushal commented Feb 1, 2026 •

edited

Loading

jayasanka-sack left a comment •

edited

Loading