Bug 1674419

Summary:	syspurpose status states should be one of matched/mismatched/not specified
Product:	[Community] Candlepin	Reporter:	Nikos Moumoulidis <nmoumoul>
Component:	candlepin	Assignee:	Nikos Moumoulidis <nmoumoul>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Katello QA List <katello-qa-list>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	2.5	CC:	jsefler, katello-qa-list, khowell, redakkan, skallesh
Target Milestone:	---
Target Release:	2.5
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	candlepin-2.5.12-1	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1660878	Environment:
Last Closed:	2019-02-25 21:35:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1660878
Bug Blocks:	1652870, 1674415, 1678363, 1696790

Description Nikos Moumoulidis 2019-02-11 10:06:47 UTC

+++ This bug was initially created as a clone of Bug #1660878 +++

Description of problem:
Currently, querying the syspurpose status of a consumer, either by using the /consumers/{consumer_uuid}/purpose_compliance API, or by fetching the consumer with the /consumers/{consumer_uuid} API and then reading the systemPurposeStatus field on that, will show the status to be one of valid/partial/invalid. This does not fit with the original design, which is to return one of these states as a status: matched/mismatched/not specified.

Version-Release number of selected component (if applicable):
All current versions that support syspurpose, up to 2.5.8, 2.3.11 and master.

How reproducible:
100%

Steps to Reproduce:
1. Perform a GET request on the /consumers/{consumer_uuid}/purpose_compliance API and check the value of the 'status' field.

Actual results:
The status field has the value of either valid, invalid, or partial.

Expected results:
The status field should have the value of either matched, mismatched, or not specified.

Additional info:
An additional minor issue is that the response's 'reasons' include two reasons for each non-compliant SLA or usage, while there should be one for each.

--- Additional comment from Chris Snyder on 2019-01-10 15:24:07 UTC ---

Comment 1 Nikos Moumoulidis 2019-05-30 12:10:07 UTC

*** Bug 1654345 has been marked as a duplicate of this bug. ***