Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Critical
-
Resolution: Cannot Reproduce
-
Affects Version/s: 3.0.3, 3.0.4, 3.1, 3.1.1, 3.1.2, 3.1.3
-
Fix Version/s: 3.2
-
Component/s: Core CiviCRM
-
Labels:None
Description
from this thread: http://forum.civicrm.org/index.php/topic,12571.0.html
Three problems identified in the thread:
1. Editing from the frontend will not save the county.
2. Import wizard allows attempts to import data into County field, DOESN'T save the data into the County field, but then reports that the import completed successfully.
3. Current implementation of County field as a list of values is problematic and not fully implemented (most likely due to difficulties of current design), which is most likely the underlying cause of these problems.
DETAIL: From looking at the data structure, "County" is not actually stored in the civicrm_address table, instead there is civicrm_address.county_id which is a foreign key to the civicrm_county table (which has only 6 rows in it).
In addition to the obvious performance implications of having to do an extra join every time an address with a county needs to be displayed, I feel it doesn't make sense for "County" to be a lookup value. There are probably thousands of counties in the US alone, the number of counties in the entire world is probably more than 100,000. Even assuming you could get a list of every county in the world, how would you keep that list up to date? What about when people mis-type or mis-enter data? What is the purpose/benefit of an external reference to county data when city and zip code are free form? There is no way for an implementation consultant to know in advance exactly which counties will be required by all future users of the application. Eliminating the ability of system users to enter County data without the assistance of a developer to modify data in a system table introduces an unnecessary dependency and greatly limits the utlity of the field for users. It also introduces unnecessary complexity for CiviCRM's development team, as now there is an additional database object to deal with (not to mention potential issues associated with obtaining/maintaining/updating/filtering a potentially massive list of counties)
I would like to propose that "County" be converted to be just a standard free form text field like "City", with the actual value stored in the civicrm_address table. Instead of giving County special handling, it should be treated like any other Address field.
Right now CiviCRM ships without any County data except for six counties in California making the County functionality unusable for all intents and purposes. In addition, the Import wizard is currently providing misleading information as to the state of attempted imports of data into the County field. Turning it into a text box might be a little painful in the short term but the benefits over the long run in terms of application performance and reduced development and testing, as well as the benefit of giving users a working County field inside the Address object ,make it worthwhile IMHO.
Thanks.