Surge Alerts: use `molnix_status` for filtering and display

[batpad]

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 status field on the Surge Alert model, which is filled in based on the closes timestamp returned from Molnix - logic here: https://github.com/IFRCGo/go-api/blob/develop/notifications/models.py#L81

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

In 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 my molnix_status and 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_status field to determine Open, Closed and Stood Down.

cc @anamariaescobar @frozenhelium @szabozoltan69 @thenav56 @tovari

[samshara]

Previous Issue https://github.com/IFRCGo/go-web-app/issues/481

[Rup-Narayan-Rajbanshi]

@batpad Do we recieve monlix_status other than 'active', 'archived', 'unfilled'. If yes, what will be the status for those surge alerts? cc @samshara , @susilnem

[batpad]

@batpad Do we recieve monlix_status other than 'active', 'archived', 'unfilled'. If yes, what will be the status for those surge alerts?

@Rup-Narayan-Rajbanshi that's a very good question. Those should be the only 3 valid values for molnix_status. I think for now the frontend code can maybe treat anything with an invalid value as "archived", but ideally this should never happen.

@szabozoltan69 - let's see if we can create a ticket to add some validation to the backend to only allow these three values for the molnix_status on the backend so we can have more confidence that this will never happen and the frontend doesn't need to have any weird code to deal with invalid values?

[Rup-Narayan-Rajbanshi]

@szabozoltan69 After we implement this, I dont think we require to run update_surge_alert_status task.

[tovari]

@batpad, @anamariaescobar, there are now a lot of open alerts (227 pages) in the Open ALerts list: https://go-web-ifrc.dev.datafriendlyspace.org/surge/overview

We need to apply a filter here to show the actual ones I think.

[anamariaescobar]

These open alerts seem to be from times before Molnix............... you can tell because of the lengthy messages on the position field. Can we filter out all the alerts before the Molnix integration, and since we are on this, make sure that the ones with the NO_GO tag are also filter out?

@batpad @tovari @Rup-Narayan-Rajbanshi @szabozoltan69

[samshara]

@tovari @anamariaescobar

We have deployed the latest data for surge alerts to https://alpha-1.ifrc-go.dev.datafriendlyspace.org/surge/overview.

Please check the data and make sure it's accurate.

The database at https://go-web-ifrc.dev.datafriendlyspace.org/surge/overview is a bit old, this might have caused the number of open surge alerts to increase.

1. Do you have any suggestions for filtering out alerts from before the Molnix integration? There doesn't seem to be a field to identify these data points.

2. We will filter out the NO_GO tags. Will this help with the issue?

[anamariaescobar]

Hi @samshara, to filter out Alerts from before Molnix, you can just filter out those that do not have a Molnix id.

@tovari

[udaynwa]

Also @anamariaescobar , do we require the data that does not have Molnix ID in the API itself? Or, do we just hide them on the client-side?

If the alerts without Molnix ID are filtered out in the API, then we won't be able to see those alerts anywhere except in the database.

[anamariaescobar]

I think hiding them from the API is needed to, that data is not reliable as multiple Alerts were put in one sigle line manually before the integration. So yes, hide them from the API too please

@udaynwa @samshara @tovari

[samshara]

I think hiding them from the API is needed to, that data is not reliable as multiple Alerts were put in one sigle line manually before the integration. So yes, hide them from the API too please

@anamariaescobar Thanks. We will do that.