[PROD] Review how cluster and region offices are handled

[jhenshall]

Issue

Cluster and Region IFRC offices, are stored in the countries table and use the ISO for the country that they're in. This can be confusing because they are not 'countries' and means there are duplicate ISO codes in the countries table, which has caused issues for e.g. #1636.

Expected behaviour

Any changes could be significant and have multiple knock-on effects with existing records being joined (e.g. field reports). Needs more detailed review but possible things to explore with very different effort levels:

• Changing the 'ISO' of these offices to be an IFRC code - so there are no duplicate ISOs.
• Rethinking the whole database structure. Initial thoughts from @GregoryHorvath on this previous issue:

  If we want to go with changing the database structure - my initial idea for separating the different types of records (just a quick mockup):

  1. Create new tables for each record_type a Country object can have (Region, Cluster, etc)
  2. Copy the separate types into their new respective tables
  3. Change the relations so Countries would have their Region mapped to the new table's records
  4. Create new endpoints, serializers, etc for the new tables
  5. Change the frontend pages, actions, etc to use the new endpoints if needed
  6. Remove all the hard-coded enums and deprecated fields from the api_country table

Related feature

• 1636

Impact

This could be a huge change but just needs the options considering as part of the wider review of geo data

cc @GregoryHorvath @batpad @geohacker

[jhenshall]

As an intermediary for this - ISO codes are being removed from all non-countries in the country database: regions and clusters. This has been done on staging for testing and assuming no issues, will be done on prod after the upcoming geo release.

[nanometrenat]

Hi there, did this ticket get sorted with the recent Country pages work?