Part of FreeREG-Core-Records (shared with FreeCEN).

Models: app/models/county.rb, app/models/manage_county.rb, lib/chapman_code.rb · Controllers: app/controllers/counties_controller.rb, app/controllers/manage_counties_controller.rb · Constraints: app/constraints/manage_counties_*_constraint.rb · Menu definitions: lib/userid_role.rb (COUNTY_MANAGEMENT_OPTIONS, COUNTY_OPTIONS_TRANSLATION)

FreeREG is organised by county. Each county has a county coordinator who looks after its gazetteer (places, churches, registers), reviews uploaded batches, manages the county's images, and is the contact for researchers. There are two parts to this:

• County is the persisted record: which counties are active and who coordinates them. It's administered by data managers and system administrators at /counties.
• ManageCountiesController is the coordinator's working dashboard for one county at a time (/manage_counties). Its model, ManageCounty, is just a form object. Coordinator-Admin-Tools has a short overview; this page covers both in full.

Counties are identified everywhere by Chapman codes (SOM, KEN, WRY…), a standard genealogical three-letter scheme. lib/chapman_code.rb defines ChapmanCode::CODES, a nested hash country → { county name → code }, with helpers values, name_from_code, code_from_name, has_key, values_at, merge_counties. Non-geographic pseudo-counties (Overseas British, Royal Navy Ships, Military…) and country/region entries are excluded from FreeREG pick-lists by FreeregOptionsConstants::CHAPMAN_CODE_ELIMINATIONS.

Some codes group several others. The search form expands YKS → ERY, NRY, WRY and CHI → ALD, GSY, JSY, SRK (Search-Query-System).

Fields: chapman_code, county_description (the name), county_coordinator (a userid string, not a reference) with a _lower_case copy, previous_county_coordinator, county_notes. The record-count fields files, total_records, baptism_records, burial_records, marriage_records (FreeCEN: census_records) are legacy; current counts come from County.records(chapman) and FreeREG-Content-and-Statistics.

Class helpers used across the app:

• County.application_counties: active counties for the current site, minus the pseudo-counties.
• County.coordinator_name(code) / coordinator_email_address(code): look up the coordinator's UseridDetail. Used on the Database Contents county page and in contact/feedback routing (Contact-System).
• County.inactive_counties: Chapman codes with no County record yet (offered when activating a county).
• County.county_with_unallocated_image_groups: drives the image allocation views.
• County.records(code): sums records over the county's batches, by record type.

• new/create "activates" a county: pick one of inactive_counties and a coordinator. create looks up the chosen UseridDetail and stores its userid.
• edit/update runs County#update_fields_before_applying when the coordinator changes:
  • old coordinator: previous_county_coordinator is set; the county is removed from their county_groups; if this was their only county, their person_role is demoted to syndicate_coordinator (if they have syndicate groups) or transcriber, unless their role is one of a protected list;
  • new coordinator: the county is added to their county_groups; if they had no counties and were a transcriber, syndicate_coordinator or researcher, they're promoted to county_coordinator.
  • It's all a sequence of save(validate: false) calls with no transaction, the same pattern as syndicate coordinator changes (Syndicate-System).
• The index view shows edit controls only to system_administrator and data_manager (@control_access_roles).

A member's counties are therefore stored in two places: County.county_coordinator (one userid per county) and UseridDetail.county_groups (the list of codes the member can manage). The dashboard below reads county_groups. If the two disagree, a coordinator may not see a county they're listed for, or vice versa.

new → get_counties_for_selection:

• most members get their own county_groups (plus counties from any country_groups);
• roles with national scope get every active county: system_administrator, data_manager, master_county_coordinator, country_coordinator, executive_director, volunteer_coordinator, contacts_coordinator, documentation_coordinator, project_manager, REGManager/CENManager/SNDManager. In FreeCEN, county_coordinator and reporter_transcriber are added too.

With one county the member goes straight in. Otherwise they pick one, and create/selected store session[:chapman_code] and session[:county]. Everything after that is scoped by session[:chapman_code].

select_action shows UseridRole::COUNTY_MANAGEMENT_OPTIONS. For FreeREG:

A member acting as reporter_transcriber only sees "CAP Report".

The menu doesn't link to the actions directly. UseridRole::COUNTY_OPTIONS_TRANSLATION maps each option to /manage_counties/selection?option=<text>, and config/routes.rb has ~17 routes for that same path, each with a constraint class (ManageCountiesErrorBatchConstraint, ManageCountiesAllPlacesConstraint, …) that matches the option text. To add or rename a menu item you have to change three things together: the option text in COUNTY_MANAGEMENT_OPTIONS, the URL in COUNTY_OPTIONS_TRANSLATION, and the constraint class's match string. Otherwise the request silently falls through to the generic select_year route.

The dashboard is driven by session keys: chapman_code, county, manage_user_origin ('manage county', used by shared batch/image views to know where to send the user back), sorted_by, stats_year, and image-group selection keys. clean_session_for_county and clean_session_for_images reset them when a new county is chosen. If a page "remembers" the wrong county, these are the keys to look at.