Issue #801: Added regex pattern to Name & UniqueName fields and custo…

[ahungerford-unicon]

…m error checking for those fields

Edit: Changed it to a Draft as this requires #810 to be completed first.

[ahungerford-unicon]

Left this in but commented as I originally had this checking as the field was edited, but wasn't really satisfied with the result since it would replace any onSave reported errors as soon as you started to correct one of them. I believe we could get inline checking done without this if we updated the Dialog to an actual form, since that is how the pattern attribute usually works, but my quick tests with it caused other issues to crop up for Dialog that didn't make it worth it.

[bjagg]

Hey @ahungerford-unicon — took a look at this while reviewing open PRs. The implementation approach is clean (validating on submit, patternErr for custom messages, whiteSpace: pre-line for multi-line errors). Nice call avoiding the inline validation — that's the right tradeoff for a dialog.

One concern with the regex ^[A-Za-z][A-Za-z0-9_]*$: it would be too restrictive for the existing UniqueName conventions in the MDR data. Looking at the seed data in V1.1__metadata_repository_init.sql, UniqueName values routinely use dots as path separators:

• Common.Contact.Address.informationSourceId
• Assessment.shortName
• achievement.achievementType

There are hundreds of entries following this dotted-path pattern. Even after #810 removes spaces, dots would still be needed for UniqueName. The current regex would prevent creating or editing any entries that follow the existing convention.

A few thoughts:

1. Name vs UniqueName may need different regexes. Name fields (firstName, Identifier) tend to be simple identifiers, but UniqueName fields (Common.Contact.Address.informationSourceId) use dotted paths. Something like ^[A-Za-z][A-Za-z0-9_.]*$ for UniqueName might work better.

2. Worth aligning with #811 (API validation) before finalizing the regex here — the frontend and backend should enforce the same rules.

3. Value Names (the last field updated in CreateOptFields.tsx) may have different conventions than entity/attribute names — worth checking if those need dots too.

Happy to help dig into the data further if useful.