Why is the country group code required/usefull for?
We need to add some start_date and end_date to the relation of countries of a group.
This allows some countries to leave a group on a given date (we had a recent example with Brexit).
I think its interesting to give some defaults values. Could you give more info on how such module can be used to fill the data?
Also I’m not sure if it’s worth having a separate module. I’m wondering if it won’t be better to just add the models on the country module and extend the import_countries module to fill such data. This way we will avoid having two separate script for loading the same data.
Not sure is useful. We don’t predict the future. Brexit is an isolated case. Most of the time groups exists and there’s no validity date. I mean, a country will not leave a continent and also there’s no versioning on the group. (European community V1 with Great Britain, EC V2 without Great Britain). Seems easier to manage manually such cases (which, i think, are not so frequent). You don’t know if Belgium will leave NATO or if spain will join OPEC…
Some defaults values could be the continents and doing the association of countries on each continent. This could be done in a script like import_countries and with python-restcountries · PyPI which allows to get continents and the countries related. Some other regional blocs are also referenced on this API (European Union, Pacific Alliance, …)
Code could be useful for reporting (using EU, OCDE, is shorter) but I don’t think it should be mandatory.
I tend to agree with @pokoli here a starting and ending date of membership is useful. A part from the continent case where for obvious reasons countries won’t leave them (at least until the tectonic plates crash one into the other) I don’t see organization that can not be joined or left by a country on some dates.
I have the impression that the starting year is usually known in advance (because there is a process to join those supranational instances), the ending year could be a bit more blurry (eg Northern Ireland is still part of the EU for some stuffs while the rest of the UK isn’t).
Agreee, it should be a One2Many with the dates. And we should allow the country to join/leave multiple times and also setting a relation with empty start and end dates (this will be the case of continents).
One question that it raises. Do we need to have an active field that hides the countries that are not applicable to the current date?
Indeed a continent is also an Organization, a geographical organization but a organization.
As the target of the relations will be CEU/EU, NATO and other country organiztion it make sense for me.
It depends on the company and the business, many of our statistics are based on continents… Some shipping costs could be also linked to continent or reports about exportations. So continent should be considered in this group otherwise we need another feature to add continents but it’ll be similar to this feature.
Such reporting is not really based on geography because many countries are on at least 2 continents (Turkey, France, Egypt etc. more) so there need to be choices.
And I do not think it can be used the organization design because it requires uniqueness for each country.
So for me it should be an upper level to country for example region which could be included in the sale reporting per region (which can not done with organization).
Could you provide examples? For me the shipment cost is based on the carrier and the addresses.
For me legal reports are not based on geographical properties but on commercial organization like intrastat is based on CEU.
I did not yet see a carrier that follow existing country organization for their cost.
It seems logical that the cost is mainly based on geographical distance. So for me the current “From/To Country” is good enough for the majority of case.
I guess we could complete the model to include country organization as rule criteria.