Drupal user edit profiles - not displaying correct country and state

[Paul Jacobson]

Hi All,

I've come across an issue with 3.0.3 and have just confirmed the same problem can be reproduced in 3.1 sandbox.

When using a profile that contains Country and State as a user edit profile in Drupal (6.15)  the profile incorrectly displays the default country and "select" for state if the record displayed contains any other country than default. This only occurs on the Drupal user edit page, and displays correctly within CiviCRM.

If a member from a non-default country accesses the page "corrects" the entry and saves, the page displays the default country and select for state when it reloads.

I've also noticed that at least one UK state  - West Midlands - displays incorrectly xWMD under 3.0.3 and 3.1 sandbox.

To illustrate both issues I've added country and state to a profile used in the 3.1 sandbox.  If you check My Account in drupal you'll see under "employee info" the incorrect xWMD abbreviation and if you click the edit employee info link the page loads with the default country displayed rather than United Kingdom.

I'm wondering if anyone else is seeing this?

cheers
Paul

[Dave Greenberg]

Paul - The country / state-province behavior looks like a bug. I've filed an issue - you can follow at:
http://issues.civicrm.org/jira/browse/CRM-5655

Regarding the xWMD abbreviation, there has been work done recently on UK  State / Province list, so I'm pinging Tom K on this since I see that several of the abbreviations in the table have a lower-case 'x' prefix and I have no idea why ??

http://issues.civicrm.org/jira/browse/CRM-5224

From the current SQL script which defines state / province values:

Code: [Select]

(9986, 1226, "xTYW", "Tyne and Wear"),
(9988, 1226, "xGMA", "Greater Manchester"),
(9989, 1226, "xTYR", "Co Tyrone"),
(9990, 1226, "xWYO", "West Yorkshire"),
(9991, 1226, "xSYO", "South Yorkshire"),
(9992, 1226, "xMSD", "Merseyside"),
(9993, 1226, "xBRK", "Berkshire"),
(9994, 1226, "xWMD", "West Midlands"),
(9998, 1226, "xWGM", "West Glamorgan"),
(9999, 1226, "xLON", "Greater London"),


[mrfelton]

I (Tom K) have no idea why this is, but it definitely looks like a bug. Those x prefixes should be removed.

[Piotr Szotkowski]

I (Tom K) have no idea why this is, but it definitely looks like a bug. Those x prefixes should be removed.

Do the codes (after dropping the prefixes) look sane (e.g., have the right postal meaning)? If so, I’ll drop the prefixes before tomorrow’s 3.1.beta5.

[Paul Jacobson]

Thanks everyone.

The postal codes are correct with the x removed.

I'll definitely keep an eye on the progress of the bug. The group I run the site for only has about 15 "non-default country members" but we are about to send out subscription reminders and having just transitioned from a poorly maintained access database most need to edit their addresses - the first test renewal caused some confusion with the changes to country and state not "sticking".

I've modded the sql database on my install to remove the x's so that solves that problem for me in the interim.

cheers
Paul  

[Paul Jacobson]

Hi

I see that this bug has been fixed and marked as closed but this appears to have only been done in the 3.1 branch.  Is it possible for the fix to be applied to 3.0.4 or a patch against 3.0.3 made available?

thanks
Paul

[Donald Lobo]

we will backport it to 3.0 and will be part of 3.0.4

in the meantime u can patch your local install (click on the fisheye link in jira for a set of patches)

lobo

[Paul Jacobson]

hi lobo,

I knew there had to be an easier way than finding the diffs in svn with ZigVersion

local install is patched with kiran's changes and everything is running smoothly. thanks for the speedy fix.

cheers
Paul

[Piotr Szotkowski]

The postal codes are correct with the x removed.

Ok, I went on and fixed the codes in r25877.

I dropped the ‘x’s and actually changed some codes to match the below lists; let me know if I broke anything this way.

http://bifhsgo.ca/chapman_codes.htm
http://logisticsworld.com/ukcounties.asp