Bug 1252145 - [RFE] New API's to support Red Hat Customer Portal Subscription Views
Summary: [RFE] New API's to support Red Hat Customer Portal Subscription Views
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Candlepin
Classification: Community
Component: candlepin
Version: 1.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Alex Wood
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks: 1122832
TreeView+ depends on / blocked
 
Reported: 2015-08-10 19:52 UTC by Thomas "Shea" DeAntonio
Modified: 2018-05-10 20:11 UTC (History)
9 users (show)

Fixed In Version: candlepin-2.0.10-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-10 20:11:51 UTC
Embargoed:


Attachments (Terms of Use)

Description Thomas "Shea" DeAntonio 2015-08-10 19:52:06 UTC
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 13:41:00 UTC
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 18:57:45 UTC
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 19:24:16 UTC
(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 19:46:56 UTC
Source Subscription ID, please.

Comment 6 Alex Wood 2015-09-22 20:35:25 UTC
Pending merge as https://github.com/candlepin/candlepin/pull/990

Comment 7 Alex Wood 2015-10-14 13:42:27 UTC
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 20:02:09 UTC
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 06:43:19 UTC
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 15:52:20 UTC
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.