Different dates at same areas of opreation are not showing

[tlongers]

Where a unit has an area of operation spanning a specified date range, this _is_disaplyed in sfm-cms. The below would display as a range inside the Areas of Operation block on WhoWasInCommand:

unit:name	unit:location	unit:location_first_cited_date	unit:location_last_cited_date
Brigade	That Place	2020-01-01	2022-01-01

However, where a unit has an area of operation at the same site on different days, but without a specified date range, these items are not displayed in sfm-cms.

unit:name	unit:location	unit:location_first_cited_date	unit:location_last_cited_date
Brigade	That Place	2020-01-01
Brigade	That Place	2020-02-01
Brigade	That Place	2020-03-01

In this case, the first row would be displayed as a single entry in the unit's Areas of Operation block in WhoWasInCommand. The expected behaviour is that all three rows would be included in the Areas of Operation list.

[hancush]

@tlongers Is it possible for an association to have many end dates but no start date? If so, is the behavior in that case the same as if there's many start dates but no end date?

[tlongers]

Yes. The below are all valid and should be displayed:

unit:name	unit:location	unit:location_first_cited_date	unit:location_last_cited_date
Brigade	That Place	2020-01-01	2021-01-01
Brigade	That Place		2021-02-01
Brigade	That Place		2021-03-01

[hancush]

From @tonysecurityforcemonitor:

---

--- Should emplacements (sites) behave the same way as AOOs, no rows collapsed in the event that there are multiple records associating an organization in the source data?

Correct!

Quick thought - the same would be true for the related units as well - no rows collapsed in the event that there are multiple records associating an organization in the source data

[hancush]

Ok, so with this clarification, the issue is that if we see an area (or site) associated with an organization, we create one association, then link with that single instance all the start and end dates for an organization in a particular area appearing in the import.

So, if we had data that looks like this –

Unit	Location	Start Date	End Date
Org A	Area A	2020-01-01
Org A	Area A	2019-12-13	2020-02-15
Org A	Area A		2021-01-24

– we'd wind up with one Association between Org A and Area A with two start dates and two end dates.

This actually caused an issue in #774 that I tried to resolve, but introduced the current issue instead!

The root problem with the way we're modeling the data on our side is that we implicitly assume there is only one start and one end date for a particular association. This gets even more complicated when there are multiple start and end dates, because there's no association between a particular set of start and end dates that form a range!

So, I added a new model, Tenure, which explicitly maps an association to its given start and end dates (and allows either date to be null), and updated the importer to populate this table when creating associations.

Taking our example from above, we now have one association between Org A and Area A with three Tenures, one starting 2020-01-01 with no end date, one starting 2019-12-13 and ending 2020-02-15, and one with no start date ending 2021-01-24.

I shared a screenshot of the resulting update and it looks good, per @tonysecurityforcemonitor.

I am going to do the same for emplacements/sites, then I'll need to do a fresh import on the affected instance on Monday so you all can review the changes.

[tlongers]

Looks like we are good to close this... @hancush concur?

[hancush]

Yep, so long as this is looking good on the relevant deployments, the fix has been completed and is live, @tlongers!