Doing something about recipient-region pages/filters

[stevieflow]

Follow on from #239 (which is nearly 10 years old!)

• The following Regions are on the default recipient-region vocabulary: https://codelists.codeforiati.org/Region/

(we know that some other publishers use https://codelists.codeforiati.org/RegionM49/ but that can be out of scope on this, right now)

• We also know an activity can have one or more recipient-region and/or recipient-country
• We also know that recipient-region should not be used to declare a hierarchical geography (as in recipient-country is in recipient-region)

As an addition to d-portal I'd suggest one of the two

• Append the regions list to the Recipient Country drop down (and rename the drop down to "Recipient Country/Region" --> that way it is a bit clearer that they are choices from the same list
• Add a new list fro "Recipient Region" --> the risk here is that people may then falsely assume that selecting a region will then return all countries (in that region)

The important function is to enable people to find and see activities that have a recipient-region value. Right now, that is not possible

Thanks!

cc/ @IsabelBirds

[xriss]

A slight spanner in the works is when transactions/budgets are split over countries it is exclusive. This is also true of regions, however is is not true of a mix of countries and regions. This was the main problem we originally raised and why it did not happen.

So if you ask for region A and country B it is possible for a single activity to allocate all of its money to region A and country B creating an obvious double accounting problem.

[xriss]

Ahh, looks like I might be out of date and it is now intended for region+country to add up to 100%

The simplest "hack" would be to add regions to the country code list, and maybe stop referring to it as countries.

[stevieflow]

Thanks @xriss

The IATI schema changed in 2.0x ( I think - can double check --> but I think that's metioned in #239_ so that recipient-country+region in any activity should add to 100%

Of course, that's not always followed - but can be filed with all other validation issues

@IsabelBirds - I think there are specific rules where recipient-country+region do not sum to 100%, which are then surfaced in the validator?

[xriss]

I think we are good at assuming country+region add up to 100% but this is going to involve changing how non explicit transactions are split and I'm not sure its easy to do in a way that can be previewed since it is a major change to how the database is built. I will have to redo the transaction splitting code at import time and probably clean up the logic as it is currently rather overly complex.

So this will be a change ( to the calculated numbers ) when we push it live with no easy way to preview. Obviously I will keep it to a minimum and try not to break old country code but it will involve a slightly scary backend change.

@notshi suggestion is to rename countries to recipients which can then also include regions. Shall we go ahead and make that UI change behind the test flag?

[stevieflow]

Thanks @xriss @notshi - understood

suggestion is to rename countries to recipients which can then also include regions.

There's a risk then that people might think this is actual recipients, as in organisations / receiver-org --> if needs, then rename to "Country/Region"?

Thanks

[IsabelBirds]

At the activity level- "Percentage values for recipient countries or regions, must add up to 100%."
https://github.com/IATI/validator-rule-tracker/blob/e49edd0b4d78446581918595c90ecb3348925ca4/rulesets.csv

At the transaction level - both region and country say "This element must occur no more than once (within each parent element)." But this is not in the validator.
https://iatistandard.org/en/iati-standard/203/activity-standard/iati-activities/iati-activity/transaction/recipient-region/