# [Enhancement] Add dynamic State/Province selection or autocomplete in Profile configuration #278
Assignees
spikerj (Joseph Spiker)
Clear assignees
spikerj (Joseph Spiker)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: spikerj/spikersoft-issues#278
Reference in New Issue
Block a user
Summary
The State/Province field in the user profile configuration lacks a functional selection list or autocomplete feature, making it difficult for users to input valid location data accurately.
Description
While configuring user data in the Profile section, the State/Province placeholder currently displays a static “-- Select --” option without any available entries or suggestions. This prevents users from completing their address properly and may lead to inconsistent or incomplete data.
Proposed Enhancement
Implement a dynamic selection or autocomplete system for the State/Province field:
Expected Behavior
When the user selects a country or begins typing in the State/Province field:
Benefits
Environment
Steps to Reproduce
learn.spikersoft.com/profile.Expected Result
The field should provide dynamic suggestions or a dropdown list of valid states/provinces based on the selected country.
Actual Result
The field only displays “-- Select --” with no available options or autocomplete functionality.
Evidence
Impact
Frequency
Always
Reproducibility
100%
Severity
Low
Notes
Integrating a location API or static dataset for country-specific regions would resolve the issue and enhance overall user experience.
Investigated against current code and production. The dynamic, country-filtered State/Province dropdown described in this enhancement request already exists and is fully wired up:
app-address-sectionrenders amat-selectpopulated fromavailableStates(), whichProfileComponent.loadStatesForCountry()refreshes viaPostalCodeService.getStatesForCountry()whenever the Country field changes.GET /api/PostalCodes/states/{countryCode}(GetStatesForCountryQueryHandler) queries a Mongo-backedPostalCodescollection seeded from GeoNames at startup (PostalCodeSeederService, with retry/backoff and a/healthzcheck)./healthz"Postal Code Data" check is Healthy with 317,784 seeded records, andUS,CA, andMXall return correct, populated state/province lists right now.So I can't reproduce an empty dropdown for any of the common countries I tested. It's possible the country selected when this was filed has sparse/no admin1 (state-level) data in GeoNames — some smaller countries genuinely don't have state subdivisions in that dataset. Could you confirm which country you had selected when you saw the empty list? If it's a real GeoNames coverage gap for that country, the fix would be a narrower data-coverage ticket rather than the full autocomplete rebuild proposed here. The one piece of the original ask that's genuinely missing is type-ahead/autocomplete (today it's a standard dropdown, not filter-as-you-type) — happy to scope that separately as a smaller enhancement if still wanted.
Investigated against current code and production. The dynamic, country-filtered State/Province dropdown described in this enhancement request already exists and is fully wired up:
app-address-sectionrenders amat-selectpopulated fromavailableStates(), whichProfileComponent.loadStatesForCountry()refreshes viaPostalCodeService.getStatesForCountry()whenever the Country field changes.GET /api/PostalCodes/states/{countryCode}(GetStatesForCountryQueryHandler) queries a Mongo-backedPostalCodescollection seeded from GeoNames at startup (PostalCodeSeederService, with retry/backoff and a/healthzcheck)./healthz"Postal Code Data" check is Healthy with 317,784 seeded records, andUS,CA, andMXall return correct, populated state/province lists right now.So I can't reproduce an empty dropdown for any of the common countries I tested. It's possible the country selected when this was filed has sparse/no admin1 (state-level) data in GeoNames — some smaller countries genuinely don't have state subdivisions in that dataset. Could you confirm which country you had selected when you saw the empty list? If it's a real GeoNames coverage gap for that country, the fix would be a narrower data-coverage ticket rather than the full autocomplete rebuild proposed here. The one piece of the original ask that's genuinely missing is type-ahead/autocomplete (today it's a standard dropdown, not filter-as-you-type) — happy to scope that separately as a smaller enhancement if still wanted.
Good news: the enhancement this ticket asks for already exists end-to-end and now works in production. The dropdown wiring was all in place (
profile.componentloads states on country change via a cachedPostalCodeService→GET /api/PostalCodes/states/{countryCode}→address-sectionselect) — the ticket predates the postal-data seed, when the endpoint had nothing to return, hence the empty "-- Select --". With the data seeded (317k records, #489's resolved half), verified live today: US → 53 entries, CA → 13, MX → 32, country-dependent as proposed.Backend PR #249 fixes the two defects that remained: a blank entry at the top of the US list (GeoNames rows with missing admin names) and the query materializing ~40k rows per country to group in memory (now projected+deduped before fetch). 2 new xUnit tests.
Suggest closing on #249's merge. If you also want type-ahead autocomplete rather than the current dropdown, that'd be a small follow-up (mat-autocomplete over the same cached service) — say the word.
Board-sweep hygiene: spikerj verified the data live in prod (US 53/CA 13/MX 32) and conditioned closing on backend PR #249's merge — #249 (blank-name + projection fix) has merged. Applying the close.