Bug 1252145 - [RFE] New API's to support Red Hat Customer Portal Subscription Views
[RFE] New API's to support Red Hat Customer Portal Subscription Views
Status: CLOSED CURRENTRELEASE
Product: Candlepin
Classification: Community
Component: candlepin (Show other bugs)
1.2
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Alex Wood
Katello QA List
:
Depends On:
Blocks: 1122832
  Show dependency treegraph
 
Reported: 2015-08-10 15:52 EDT by Thomas "Shea" DeAntonio
Modified: 2018-05-10 16:11 EDT (History)
9 users (show)

See Also:
Fixed In Version: candlepin-2.0.10-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-05-10 16:11:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas "Shea" DeAntonio 2015-08-10 15:52:06 EDT
In order to improve the customer experience in the Red Hat Customer Portal around subscription management we are going to need some new API's in order to show the relationships between Systems, subscriptions,contracts and status.

I will add some folks to help give definitions around exactly which API's are needed.
Comment 1 Jonathon Turel 2015-08-11 09:41:00 EDT
What we are ultimately looking for is the ability to list consumers based on their subscription criteria.

Listing consumers that have pools with:

1) a given subscriptionID
2) a given SKU
2) a given contract number
3) a given contract number and SKU

I think our only option right now would be to get all consumers and their pools and do our own filtering.
Comment 3 Alex Wood 2015-09-18 14:57:45 EDT
Just to clarify, these queries will be within the context of an org.  Probably an extension to the /owner/{id}/consumer resource.
Comment 4 Alex Wood 2015-09-21 15:24:16 EDT
(In reply to Jonathon Turel from comment #1)
> What we are ultimately looking for is the ability to list consumers based on
> their subscription criteria.
> 
> Listing consumers that have pools with:
> 
> 1) a given subscriptionID

By subscription ID do you mean the entitlement ID?  Or do you want to actually search via the source subscription for a given pool?
Comment 5 Jonathon Turel 2015-09-21 15:46:56 EDT
Source Subscription ID, please.
Comment 6 Alex Wood 2015-09-22 16:35:25 EDT
Pending merge as https://github.com/candlepin/candlepin/pull/990
Comment 7 Alex Wood 2015-10-14 09:42:27 EDT
Jonathon,

I was just running through this code this morning and realized that the implementation may have some unforeseen quirks.

Assume SystemA is subscribed to SKUs "p1" and "p2".  SystemB is subscribed to "p1" only.

POST /owners/my_org/consumers?sku=p1&sku=p2

The result would be [SystemA, SystemB, SystemA] since SystemA has both p1 and p2.  Personally, I think that violates the principal of least astonishment.  I can see it being valid to return [SystemA] (implicit AND) or [SystemA, SystemB] (implicit OR with a `uniq` applied).

I tend to lean a bit towards the implicit AND because the JSON that is returned doesn't actually have any entitlement information in it.  With the implicit OR + uniq, it would be impossible to subsequently narrow down whether the consumer was selected because it had p1 or p2,.

The same type situation also exists with the new "subscription_id" and "contract" query parameters.

Please let me know what you think.
Comment 8 Jonathon Turel 2015-10-14 16:02:09 EDT
Alex,

Thanks for bringing this to my attention. The behavior I would expect would be the implicit AND as you described because of your observation about principle of least astonishment, and that's just how we'd like for it to behave in terms of our use case.
Comment 9 Peter Vreman 2018-05-09 02:43:19 EDT
Is this not already solved in Sat6.3 with Candlepin 2.0 and the updated susbcription allocation handling in the Portal?
Comment 10 Bryan Kearney 2018-05-09 11:52:20 EDT
Thanks Peter, sending to Barnaby to look at.

Note You need to log in before you can comment on or make changes to this bug.