[Humanitarian Updates] Create new model for “Humanitarian Scope”

[btornes]

Create a new model for “Humanitarian Scope”, which will have roughly six custom attributes.

The attributes for the HumanitarianScope model are:

integer => project_id (foreign_key) string => type, :null => false (maps to http://iatistandard.org/202/codelists/downloads/clv3/json/en/HumanitarianScopeType.json) string => vocabulary, :null => false (maps to http://iatistandard.org/202/codelists/downloads/clv3/json/en/HumanitarianScopeVocabulary.json) string => vocabulary_uri string => code, :null => false string => narrative

More details from https://vl.basecamphq.com/projects/13497398-ngo-aid-map-strategy-and-development/posts/103253285/comments:

These line up with the 4 attributes and 1 sub-element (narrative) for the IATI element, documented at http://iatistandard.org/202/activity-standard/iati-activities/iati-activity/humanitarian-scope/. The 6th attribute is the foreign key for the projects table.

Regarding the external codelists: the backend project form will need to have a new section clearly marked for humanitarian-specific fields. Within this section, we’re adding a boolean humanitarian flag to mark whether a project is humanitarian (this is one of the two new attr on projects), and this method of tracking humanitarian projects will replace the current humanitarian-aid-as-a-sector approach. We’re also bringing back clusters. Humanitarian clusters were built into the platform early but fell into disuse. Now that we’re bringing them back as part of a larger cohort of humanitarian data fields, we want to handle them at least a little bit differently to allow for seamless updates to an evolving external codelist.

The cluster codelist is at https://www.humanitarianresponse.info/api/v1.0/global_clusters. To retain some of the functionality to perform various operations with clusters within the platform (that has been dormant for a while), I am thinking we should utilize the existing cluster model and db table, and create a task that routinely syncs the cluster data in our db to the external codelist. Right now there’s only two attributes in the cluster table (id, name), but we probably should add a few more for tracking purposes at least (such as timestamps, and maybe one or two others…?).

The two other codelists are for HumanitarianScope data:

humanitarian-scope@type—> http://iatistandard.org/202/codelists/downloads/clv3/json/en/HumanitarianScopeType.json humanitarian-scope@vocabulary—> http://iatistandard.org/202/codelists/downloads/clv3/json/en/HumanitarianScopeVocabulary.json

Unlike the clusters, adding new db tables to manage relationships for these two fields seems excessive (maybe your team thinks otherwise). That would involve creating new models/relationships for these two fields and creating a sync task like the one clusters. I figured it would be simpler (no new models/migrations) to cache these codelists in Redis and refresh them periodically. Then populate the form dropdowns for these fields from Redis. We generally need the ‘code’ and ‘name’ from the codelists—the name for displaying in the form dropdown and the code for storing with the HumanitarianScope relation). I’m open to considering all options for how to tackle this. I’m just wary of starting to use our database and models as a mirror for IATI codelists.rea

[btornes]

@RBFraxinus This is ready for QA on Staging. Let us know if you have any questions on what you see.