Argus' tag concept is simple enough for most cases where arbitrary metadata needs to be attached to an incident: A flat list of key/values, where values are always strings.
However, there are many use-cases where metadata needs to be slightly more complex, especially if we want to introduce more advanced filtering functionality. Some examples:
We might want to filter on metadata number values using "less than" or "greather than" filters. The only way to do that would if the metadata values themselves had data types, rather than being strings-only.
Users such as the GÉANT NOC want to have more structured metadata. A simple example could be that one piece of metadata needs to be a list of values, or even a list of sub-keys and values (where values also have simple data types).
Today's tag data model is really over-engineered considering its outward simplicity. Tags have creation dates and authors, which several years of use has shown is really not that useful. The JSON data model used for submitting incident tags in the API is also needlessly complex compared to the outward simplicity of the current tag concept, as described in #136.
Ultimately, #790 introduced a new metadata attribute to the incident model. This attribute is a JSON document, which would allow for nearly arbitrarily complex metadata (within reason). It was added as an alternative to tags, but Argus has (not yet, anyway) no filtering capabilities for this field.
I would suggest that the current tag model be entirely scrapped and replaced by the new metadata attribute.
Argus' tag concept is simple enough for most cases where arbitrary metadata needs to be attached to an incident: A flat list of key/values, where values are always strings.
However, there are many use-cases where metadata needs to be slightly more complex, especially if we want to introduce more advanced filtering functionality. Some examples:
We might want to filter on metadata number values using "less than" or "greather than" filters. The only way to do that would if the metadata values themselves had data types, rather than being strings-only.
Users such as the GÉANT NOC want to have more structured metadata. A simple example could be that one piece of metadata needs to be a list of values, or even a list of sub-keys and values (where values also have simple data types).
Today's tag data model is really over-engineered considering its outward simplicity. Tags have creation dates and authors, which several years of use has shown is really not that useful. The JSON data model used for submitting incident tags in the API is also needlessly complex compared to the outward simplicity of the current tag concept, as described in #136.
Ultimately, #790 introduced a new
metadataattribute to the incident model. This attribute is a JSON document, which would allow for nearly arbitrarily complex metadata (within reason). It was added as an alternative to tags, but Argus has (not yet, anyway) no filtering capabilities for this field.I would suggest that the current tag model be entirely scrapped and replaced by the new
metadataattribute.As discussed in https://github.com/Uninett/Argus/issues/790#issuecomment-2084505676 and IRL several times.