DigitalCommons / mykomap-monolith

A web application for mapping initiatives in the Solidarity Economy
0 stars 0 forks source link

[back-end] Add test data #24

Closed rogup closed 1 month ago

rogup commented 1 month ago

What? Why?

Related to issue #20

In our delivery meeting, we confirmed that this mock data covers all the fields we need in the Delhi demo

{
  "Identifier": "test/cuk/R000001",
  "Name": "Test Co-op",
  "Description": "We sell some stuff",
  "Website": "https://test.coop",
  "DC Domains": "test.coop;testlong.coop",
  "Country ID": "GB",
  "Primary Activity": "ICA230",
  "Organisational Structure": "OS60",
  "Typology": "BMT30",
  "Latitude": 51.507476,
  "Longitude": -0.127825,
  "Geo Container Latitude": 51.50747643,
  "Geo Container Longitude": -0.12782464,
  "Geocoded Address": "1 West Street, Sheffield, S1 2AB, UK",
  "NCBA Member": 0,
  "ICA Member": 0,
  "DC Registered": 1,
  "CUK Member": 1,
  "CUK Sector": "Water"
}

We need to add some demo JSON files based on this, so we can start adding UTs.

Checklist

wu-lee commented 1 month ago

I think multiple-valued items like this:

"DC Domains": "test.coop;testlong.coop",

Would be better as arrays?

"DC Domains": ["test.coop","testlong.coop"],

Using delimiters can be a bit fraught in general, as you need to either pick one which cannot legitimately appear in the data or implement an escaping rule.

Necessary sometimes with CSV, but I think this can be entirely avoided in JSON.

wu-lee commented 1 month ago

One thought about the "member of" fields. Perhaps these would need to be (or more conveniently be) collapsed into a single field, perhaps an array or an object.

Whether this is true or not depends a bit on how we handle them in the filters - the UI design I've seen wants them to be one filter, not N filters.

rogup commented 1 month ago

I think multiple-valued items like this:

"DC Domains": "test.coop;testlong.coop",

Would be better as arrays?

"DC Domains": ["test.coop","testlong.coop"],

Using delimiters can be a bit fraught in general, as you need to either pick one which cannot legitimately appear in the data or implement an escaping rule.

Necessary sometimes with CSV, but I think this can be entirely avoided in JSON.

Updated this

rogup commented 1 month ago

One thought about the "member of" fields. Perhaps these would need to be (or more conveniently be) collapsed into a single field, perhaps an array or an object.

Whether this is true or not depends a bit on how we handle them in the filters - the UI design I've seen wants them to be one filter, not N filters.

Yes, good idea. I think this makes more sense.

Although I don't think they're always a 'member of' each of them e.g. DotCoop. I'll call the field 'data_sources' since this matches with the popup design https://xd.adobe.com/view/3ef8c8d0-84bb-480e-bdfe-113d11f1583b-6bab/screen/2cccf667-44b9-4e12-ac7e-3c1c9d17eb60/

wu-lee commented 1 month ago

All good for merging I think.

rogup commented 4 weeks ago

These changes were re-added after Nick's API changes, along with some small changes to fix the UTs 328f013f90dac854d8ed6a37955e79aab1a413e4