search

SNEWS2 / SNEWS_Publishing_Tools

Publishing Tool for SNEWS
BSD 3-Clause "New" or "Revised" License
2 stars 2 forks source link

properly storing the alerts #35

Open KaraMelih opened 2 years ago

KaraMelih commented 2 years ago

In the latest modification, I added an option to specify where to dump the received alerts in the subscribe method. By default it is None and if this is the case, it fetches from the test_config.env here

Then, there is this helper function here which makes a name with the current date like; '0_2022-03-11_ALERT.json' the first zero being the index i.e. it is the first alert message on 2022-03-11 and my idea was to increase this if there are more messages within the same day. This same name is also passed to CLI's --plugin option, so we call any given custom script with name (e.g. on 1st of April, we receive an alert, and you have a follow-up script named 'customscript.py', as soon as the alert comes, save the JSON, and call python customscript.py 0_2022-04-01_ALERT.json so it always finds the correct alert and does stuff)

Now there are two open issues; 1 - The counter is not yet properly implemented (I could use help) 2 - We should decide on how to handle the UPDATE alerts.

I guess for the updates, I'd go for the former, as files do not occupy a lot, and people might wanna go back and say "oh at first, there was this message and I did that, and then this one with the updates caused this etc"

dallaval5u commented 2 years ago

To make it as simple as possible, should we just forget about the updates and send only alerts with the sublist number?

KaraMelih commented 2 years ago

Do you mean completely ignoring any updates and keeping only the alerts formed by the first two messages? Or, do you mean only saving them as ...ALERT.json and since there is a sublist number, the user can interpret whether this is an update of the previous alert or not?

dallaval5u commented 2 years ago

Yes, the second thing. Sublist number should probably be enough