We should deprecate the status field and remove logic on our end to calculate it. Anyways, it seems very brittle to be doing that calculation on save.
Speaking to @anamariaescobar we should remove all custom logic that tries to infer the status of an Alert, and just use whatever Molnix gives us as molnix_status, regardless of whether this causes a mismatch with the dates of the alert, which can be treated as an upstream data problem.
There are three possible values of molnix_status, and they should map to the following strings for display / filtering:
A molnix_status of active should be shown as Open
A molnix_status of archived should be shown as Closed
A molnix_status of unfilled should be shown as Stood Down
Am sorry this has gotten a bit confusing due to the way this has evolved a bit and assumptions we made that have changed. I do think the above changes will greatly simplify everything once we implement them, as the idea would be to remove all custom logic on our end and just used the molnix_status field to determine Open, Closed and Stood Down.
cc @anamariaescobar @frozenhelium @szabozoltan69 @thenav56 @tovari
When we fetch Surge Alerts from the Molnix API, they come with a status string from Molnix, which we store as
molnix_status.For various historical reasons, we don't use this field to denote "Open" and "Closed" positions on the Surge Alerts table:
We use a different
statusfield on the Surge Alert model, which is filled in based on theclosestimestamp returned from Molnix - logic here: https://github.com/IFRCGo/go-api/blob/develop/notifications/models.py#L81We should deprecate the
statusfield and remove logic on our end to calculate it. Anyways, it seems very brittle to be doing that calculation onsave.Speaking to @anamariaescobar we should remove all custom logic that tries to infer the
statusof an Alert, and just use whatever Molnix gives us asmolnix_status, regardless of whether this causes a mismatch with the dates of the alert, which can be treated as an upstream data problem.There are three possible values of
molnix_status, and they should map to the following strings for display / filtering:molnix_statusofactiveshould be shown asOpenmolnix_statusofarchivedshould be shown asClosedmolnix_statusofunfilledshould be shown asStood DownIn places in the frontend where we want to only show "Open" positions, we are currently filtering by the
end_date: https://github.com/IFRCGo/go-web-app/blob/develop/app/src/views/SurgeOverview/SurgeAlertsTable/index.tsx#L87 - instead, we should just filter mymolnix_statusand show only things that are Open or Stood Down.Am sorry this has gotten a bit confusing due to the way this has evolved a bit and assumptions we made that have changed. I do think the above changes will greatly simplify everything once we implement them, as the idea would be to remove all custom logic on our end and just used the
molnix_statusfield to determine Open, Closed and Stood Down.cc @anamariaescobar @frozenhelium @szabozoltan69 @thenav56 @tovari