[#5861] CBSubs: Little problem with promo depending on Geographic Zone of Buyer

Hi,

Generally, it works if in promotions under "Groups" I set a "Geographic Zone of Buyer", so the promo applies only to users from a specific zone.

But only if I store `country_name` as value in the field cb_country, not if I store an ISO country code.

However, I need to store `country_iso_code3` as value - for a number of reasons such as import of over 10,000 subscribers, compatibility with external systems, ability to change country name spelling over time, etc etc.

How can it be done?

Thanks in advance!

P.S.:
I see that in #__cbsubs_geo_zones_entries country_iso_code2 is stored as value, and so I tried storing this in cb_country (which could also work for me as long-term solution), but it also doesn't work then. Seemingly, the check for the condition is made only against country_name?

In my tests it appears CBSubs uses country_name. However, it's the raw untranslated name. So you could always translate the names without ever affecting the storage behavior. I'm not sure how your import usage works, but it could use the _comprofiler_countries database table to translate iso code to country_name for storage.

Hi Kyle,

Thanks for your response, though I'm not sure I understand, other than your agreement that CBSubs expects country_name for the promos (and possibly for taxes as well?).

Let me try to explain my case:

1. The client has ISO3 codes as raw values in the current database. They can be converted to ISO2 codes as well.
2. Their labels (long-format) country names are not identical with CB's country_name. Hence, those are useless.
3. I want/need/must import and store, and use in the long run for existing and new subscribers incl future mass imports, ISO3 or ISO2 codes in cb_country. After all, it's the purpose and beauty of ISO codes that we are able to use them as raw values, whatever their labels or translations are on a screen or when used externally. Just like "1" and "0" instead of "yes" and "no".
4. As you probably well know, the typical client comes at some point and wants to change something... in this context maybe change long-format country names "in his customers' interest", etc etc... one more big reason to not store and depend on long-format names.
5. Believe it or not: in my case here taxes are irrelevant. It's all zero tax. Ha!

I dare saying that, with #__comprofiler_countries (which I'm happily using, of course) on hand, in an ideal world you'd check on what type of value is stored in cb_country: ISO2, ISO3, or a long-format name when processing tax and promo conditions. This way it'd work for all of us and in the long run, including existing CBSubs sites out there.

Meanwhile, unless there's a simple way which I can't see, yet, I'd be very happy to get and use a hack for the promos to work with ISO3 values, or ISO2, whichever is simpler. Been through some files already, but only diagonally... as it would take me, while you can probably point at the right file and line in a blink...

Thank you, thank you, thank you! :blush:

CBSubs stores country_name as shown in _comprofiler_countries and directly stores it to the database column cb_subs_inv_address_country in _comprofiler. CBSubs has functions to convert country_name to its ISO. You would need to store them as country_name and you can use the _comprofiler_countries table to convert the ISO to country_name as needed. I agree it should be ISO, but you need to be using and considering a workaround (use of country_name) until then.

I honestly would not expect a rewrite of this behavior anytime soon. You've to consider it has behaved this way for years and the dangers of changing it. There are a lot of CBSubs sites already active with it behaving this way and changing it could result in them broken. So this has to be done extremely extremely carefully, which will take time. This is not a simple change one file and done. The parsing behavior and usage goes all throughout CBSubs and several of its integrations.

I've added a feature ticket for this to be looked into further.

#5861

Thanks Kyle,

As I tried to express, I can see that you can't change from storing country_name to ISO as value over night as practically all the many, many existing sites would go belly up on next update. Which is why I was "suggesting" a check what value format is stored, etc etc, so it'd work for old and new sites, existing users and those registering new. But it's clear that it's not a 10 minutes tweak.

So, since you replied I've built my workaround.

When you said

CBSubs stores country_name as shown in _comprofiler_countries and directly stores it to the database column cb_subs_inv_address_country in _comprofiler.

I took a quick look at the function "getPromotionsApplicableForPlan" in cbsubs.promotion.php, thinking that country_name must be the value in cb_subs_inv_address_country. Quickly made an Auto Action on register and profile update to update/set cb_subs_inv_address_country with country_name depending on the ISO3 value in cb_country. That part worked fine, but it didn't help with promo application.

Actually, cb_subs_inv_address_country remains empty even when the basket is loaded. Not sure when its getting populated (guess only once invoice address is confirmed = on payment?), but obviously it's irrelevant for promo application. So, also not sure why you mentioned it in this context?

So, reversed all that, and back to storing country_name in cb_country.
Then created a new CB field in a tab hidden for non-moderators to which I can mass-import the ISO3s. With a manual query this field can then be used to fill empty cb_country fields with country_name. Or update non-empty fields in case the client messes with country_name values...

Of course, I also have an Auto Action to keep the ISO3 field up to date on user registration and profile updates (in case a user moves from one country to another...).

Not that "simple" solution I had hoped for, but still viable. Loving Auto Action more and more, can do sooooooo much... a "custom plugin" is built in under a minute average... ha!
Thanks for that - and everything else!