expose cve_statuses on api/v1/sbom/{id}/advisory

[JimFuller-RedHat]

Now that we have the ability to filter on cve statuses for cves on an sbom's advisory we should expose via endpoint api/v1/sbom/{id}/advisory.

It is unclear how we can add this kind of nested query param to our default ?q= approach .. I am pretty sure we do not want to add a special 'snowflake' of ?cve_statuses=comma separated list of statuses.

When no filter is provided we select all statuses, otherwise a single value or a comma delimited set of values will instruct filter accordingly ... the status values should probably be those defined in status.slug.

[jcrossley3]

The query language already supports alternative values as |-delimited: ?q=cve_status=x|y|z

But that only works if cve_status is a scalar. I'm guessing since you called it cve_statuses (plural) that it's an array? That will require some thought. :)

[JimFuller-RedHat]

But that only works if cve_status is a scalar. I'm guessing since you called it cve_statuses (plural) that it's an array? That will require some thought. :)

yes ;) for example ?q=cve_statuses=affected,not_affected

[jcrossley3]

We can still use a pipe for that -- comma is used as a filter separator -- but we'd need to introduce logic to determine whether the field is a list and generate some sort of IN query.

[JimFuller-RedHat]

sounds good - as for IN query ... this specific example is another case of 'we just want to use the values' I think because the actual db filtering happens far down the call chain ... I could be mistaken.

[jcrossley3]

I'm sure IN query is wrong -- I'm a SQL idiot. However you say "are any of these things in your listy thing?"

[JimFuller-RedHat]

in pgsql, something like passing in ARRAY[] of strings ...

"status"."slug" = ANY($1::text[]))

or concretely

"status"."slug" = ANY(ARRAY["affected"])

[jcrossley3]

cool. if i can identify the appropriate type for slug, i can generate that.

[JimFuller-RedHat]

for this specifically (for now) we do not need db query as this filter is applied so differently and later then most of our queries (part of the work @dejanb has been doing) ... just another way of saying values are good for now.