CiviCRM Community Forums (archive)

This is a follow on thread / discussion split for the topic of the handling of allowed states / countries - discussion so far...
 

   4) language/currency/countries... If these aren't in the list they are probably still stored in the civicrm_domain table. They should be moved. I think most will be fairly simple but ..
    5) the handling of allowed states / countries need some thought - the current method is memory intensive. We could save the array as json in the settings table & unserialise it / use only when there is a country box. But there are other problems with the current method - e.g people like to restrict front end country entry - but then they can't even see the country for imported contacts from a non-permitted country. So, would be good to be clear firstly (because I'm not) what we expect from the country / state list restriction & then potentially look at how to store that.

Xavier's input below
Ah, ok. Might be better moving that discussion to another tread. anyway:

Shouldn't is simply be a new column "is_active" in the country table? and then using the "normal" pseudoconstant cache feature on it and leave all that outside of the setting table?

Probably needs as well a UI, that wouldn't hurt anyway if folks want to change the name of a country (had a request today to rename "Palestine, occupied territory" into "palestine" and indeed, some of the official names for countries are quite verbose.

I didn't have a use case of different countries for the front or back. I did have the case of different countries per profile.

So, in response to Xavier's thoughts. I had the same idea about is_active. The only thing is  - I guess you need is_active by domain? i.e, different domains can set separately.

Don't know, not using it. Is this a common case to a different countries for each domain? doesn't it risk altering addresses (eg. if I'm creating a contact in CH in one domain but editing it later in another domain that doesn't have it enabled?)
 
And wouldn't the argument "of per domain" be valid for a lots of elements (tags, relationship type...) that are common across domains?

Out of pure ignorance and for the sake of simplification, I'd go for the same list of countries for each domain, and is_active is a simple boolean

Also, caching all in a pseudoconstant may not make sense as I have seen grown servers cry (well - I've seen out of memory errors with 368MB RAM) when more than one country's states are enabled - it might make more sense just to go with the extra queries as they should be small.

Good point. let's not make the grown up server cries then.

But, I'm answering thoughts about the solution - when in my own mind I don't understand the problem. ie. what is the goal of the country limit. Is it to impose a limit on front end form data entry? In which case only loading the countries for front end forms would make sense.

I thought the goal to default to a country list limited to the US was mostly to have grumpy french citizen[1] complaining that we are not treated with the respect our great nation deserves; while being secretly relieved that the UK is ignored as well.

X+

[1] Completely fictional character, obviously