Bug 1386688

The difference with a working UI version is the missing of the types:[] array in the rule:

Failing Rule in the UI:

[crash] root@li-lc-1578:~# curl -K /opt/hoici/etc/sat6/curl-hoici.conf "-HContent-Type: application/json" "-d{\"per_page\":9999}" -XGET https://localhost/katello/api/v2/content_view_filters/15 | jq .rules
[
  {
    "content_view_filter_id": 15,
    "start_date": "2000-01-01",
    "end_date": "2016-10-16",
    "date_type": "updated",
    "id": 6,
    "created_at": "2016-10-16 14:01:06 UTC",
    "updated_at": "2016-10-16 14:01:06 UTC"
  }
]


Working Rule in the UI:

[crash] root@li-lc-1578:~# curl -K /opt/hoici/etc/sat6/curl-hoici.conf "-HContent-Type: application/json" "-d{\"per_page\":9999}" -XGET https://localhost/katello/api/v2/content_view_filters/25 | jq .rules
[
  {
    "content_view_filter_id": 25,
    "start_date": "2000-01-01",
    "end_date": "2016-10-19",
    "types": [
      "security",
      "enhancement",
      "bugfix"
    ],
    "date_type": "issued",
    "id": 9,
    "created_at": "2016-10-19 12:40:37 UTC",
    "updated_at": "2016-10-19 12:49:37 UTC"
  }
]

That means that the input check from the rules in the API is not correct. It should require also at least 1 type to be set

The API shall do sanity checking or added reasonable defaults when optional values are missing.
In case of the types with a date filter, when i do not specify it i do not care about it and the default shall then be all types.

Second note, the UI does not display the time within the day. Is the listed end date the start of the day or 23.59.59? and in which timezone are the dates and times?

Hi Peter, the behavior observed in the initial description is actually working as designed.  When creating the filter from the cli, it is created as an 'erratum' filter; however, the rule determines whether it is going to be treated as either 'Erratum - by ID' or 'Erratum - by Date and Type'.  The type would be based upon what parameters are associated with the rule.

For example:

- "Erratum - by Date and Type" - could include the following arguments from the cli:

 --end-date END_DATE                             erratum: end date (YYYY-MM-DD)
 --start-date START_DATE                         erratum: start date (YYYY-MM-DD)
 --types TYPES                                   erratum: types (enhancement, bugfix, security)
                                                 Comma separated list of values.

- "Erratum - by ID" - could include either of the following arguments from the cli:

 --errata-id ERRATA_ID                           erratum: id
    OR
 --errata-ids ERRATA_IDS                         erratum: IDs or a select all object
                                                 Comma separated list of values.

That said, I'll see if it is feasible to default the 'types' value to all types (i.e. security,enhancement,bugfix) to be consistent with the UI for cases where the rule is created without specifying errata IDs.

Regarding comment 3, it appears that the date rule would be based upon 'start of day' and timezone would be based on the Satellite server.

Hi brad,

The issue is about the fact that there are the API allows 3 rules types and the UI only 2

API supports:

"Erratum - by Date"
"Erratum - by Date and Type"
"Erratum - by ID"


UI supports:

"Erratum - by Date and Type"
"Erratum - by ID"

As far as i remember the rule type "Erratum - by Date" without the types is also working fine and selects all types.

There are multiple solutions:
- Fix the UI part in case that when the types field is null that it means all types are set.
- API when creating a rule without types field set then use the default value of all types

Peter

Hi Peter,

I was actually implementing your second proposed solution:

- API when creating a rule without types field set then use the default value of all types

One additional note, is that if the user provides 'errata_id' the logic will not set 'types' since it is not applicable for those rules.

Created redmine issue http://projects.theforeman.org/issues/17108 from this bug

Proposed solution in upstream Katello PR: https://github.com/Katello/katello/pull/6410

Verified on 6.3.0 snap 9

Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336