Simplify the tag data structure required by the Incident API endpoint

[lunkwill42]

Tags need to be posted as a list of tag models when POSTing incidents to the API, which seems unintuitive and should be changed to simplify the API. It shouldn't matter to the API consumer how the internal modelling of Argus works in this regard.

E.g. one needs to post something like this as of today:

{
    "start_time": "2020-09-01 14:54:42",
    "source_incident_id": "2",
    "details_url": "/not-a-real-url",
    "description": "Something went wrong",
    "tags": [
    	    {"tag": "host=example-sw.uninett.no"},
    	    {"tag": "ipaddr=10.0.0.1"}
    ]
}

A more intuitive way might be

{
    "start_time": "2020-09-01 14:54:42",
    "source_incident_id": "2",
    "details_url": "/not-a-real-url",
    "description": "Something went wrong",
    "tags": ["host=example-sw.uninett.no",
     	     "ipaddr=10.0.0.1"]
}

or even

{
    "start_time": "2020-09-01 14:54:42",
    "source_incident_id": "2",
    "details_url": "/not-a-real-url",
    "description": "Something went wrong",
    "tags": {"host": "example-sw.uninett.no",
    	     "ipaddr": "10.0.0.1"}

}

(although I'm not entirely convinced we should always require a tag to be key=value, even if it would be the norm...)

EDIT: Also, the API endpoint requires the tags attribute to be present, even though tags aren't mandatory. Allowing the attribute to be omitted, rather than requiring an empty list to be posted, should be considered part of this issue.

[jorgenbele]

When considering the two more intuitive ways it should be decided if we want to support more than one value per key (tag "type" as I've named it in frontend source code). The first version retains this property while the second one does not. There are some places where this property is required, such as when filtering by tags, so it could be useful to have it be universal.

[hmpf]

foo=bar as the tag-format is pretty hardcoded everywhere: validators, etc. Makes GET-parameters very easy also. Multiple tags with the same key is also supported IIRC everwyhere: tags=foo=bar,foo=xux in GET-parameters, each tag as a separate string elsewhere.

[hmpf]

If we are to support "simplex" tags, what makes sense is the tag being just a key, not a value. Backend-wise, that can be supported by allowing the bits after '=' to be an empty string.

[hmpf]

I would have preferred the API to be:

{
    "start_time": "2020-09-01 14:54:42",
    "source_incident_id": "2",
    "details_url": "/not-a-real-url",
    "description": "Something went wrong",
    "tags": ["host=example-sw.uninett.no",
     	     "ipaddr=10.0.0.1"]
}

[hmpf]

More importantly data-model wise, currently, a tag-relation has an owner and a date.

class IncidentTagRelation(models.Model):
    tag = models.ForeignKey(to=Tag, on_delete=models.CASCADE, related_name="incident_tag_relations")
    incident = models.ForeignKey(to="Incident", on_delete=models.CASCADE, related_name="incident_tag_relations")
    added_by = models.ForeignKey(to=User, on_delete=models.PROTECT, related_name="tags_added")
    added_time = models.DateTimeField(auto_now_add=True)

I think the purpose is to prevent there being a build-up of unused tags or something. The frontend cannot change tags at the moment, and the backend shouldn't either. Incidents should not (never?) be deleted, so currently, tags should never be deleted, so currently, this is YAGNI.

Changing this should not affect the API though.

[lunkwill42]

Maybe this is a suitable second task for @katsel. What do you think, @hmpf?

Edit: Maybe we'll do an IRL discussion of the merits of this issue first, to make sure we're all on the same page.

[katsel]

We could consider the use of PostgreSQL JSON storage and query features.
Storing tags as JSON in the database avoids typed tags.

https://www.postgresql.org/docs/11/functions-json.html