In the past we got rid of the meta field where we used to group all unknown key-value pairs. Instead we were now adding them as new key-value pairs to the dictionary.
However, with the new SQL backed, this seemed more complicated to track. So, I rolled back to the original idea.
If the user builds a message that contains some key-value pairs "that do not belong to ANY of the created tiers" they are shipped under the "meta" key in the message. These meta keys are NOT displayed in the alert messages but they are there for long-term storage and additional investigation, e.g. any comment the user might have, or any additional data that they might provide for triangulation etc. Coincidence System (snews cs) does not try to investigate the data send under the meta.
Along with this addition, I also
fix the detector name setting issue
made is_test an accepted argument for each tier, defaulted it to False when nothing is passed
In the past we got rid of the
meta
field where we used to group all unknown key-value pairs. Instead we were now adding them as new key-value pairs to the dictionary.However, with the new SQL backed, this seemed more complicated to track. So, I rolled back to the original idea.
If the user builds a message that contains some key-value pairs "that do not belong to ANY of the created tiers" they are shipped under the
"meta"
key in the message. These meta keys are NOT displayed in the alert messages but they are there for long-term storage and additional investigation, e.g. any comment the user might have, or any additional data that they might provide for triangulation etc. Coincidence System (snews cs) does not try to investigate the data send under the meta.Along with this addition, I also
is_test
an accepted argument for each tier, defaulted it to False when nothing is passed