Bug 2178854

1. Proposed title of this feature request

[RFE] Be able to see recently expired subscriptions like you can on the portal.

3. What is the nature and description of the request?

The customer would like to be able to see which subscriptions have expired when they examine the web interface of the Satellite server, rather than them simply disappearing from view entirely.

4. Why does the customer need this? (List the business requirements here)

From the customer:  Once the subscriptions expire there is no way to know what you had in the manifest.  Yes, on the portal side you can see what subscriptions expired, but you can't tell what manifest used to have them.  There is more work involved with subscription management than there should be.  SCA helped but hasn't gone far enough.  Manifest management is still a big pain.

You can go into subscriptions on satellite and export a csv, but you have to do that before they expire.  After the fact you are out of luck.
You can download a csv for all of the subscriptions, but it is flat and doesn't tell you where they are used.
You can download a csv for all of the Subscription Allocations, but it is flat and doesn't tell what is in them.
You can download a csv for each manifest, but you have to do it one at a time and it takes a lot of time.

5. How would the customer like to achieve this? (List the functional requirements here)

This would be enough:
- retain rows for expired subscriptions in the Content > Subscriptions page on the Satellite server

This would make it more obvious to people that they are expired:
- print those rows in red text

This would help to filter what you are looking for:
- add a new Status column with possible values "Current", "Future Dated" and "Expired"

Note:  In some cases people add large numbers of subscriptions to their manifests.  In such cases, displaying the expired subscriptions by default might make the display unmanageable.  Perhaps if a check-mark box were added to the subscriptions page to include recently expired subscriptions, that would let people easily view that information without forcing them to do so.


6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

.

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

no

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL8, RHEL9)?

no

9. Is the sales team involved in this request and do they have any additional input?

no

10. List any affected packages or components.

foreman
candlepin

11. Would the customer be able to assist in testing this functionality if implemented?

yes


2. Who is the customer behind the request?

Account: 	United Health Care Services and acct # 620335
TAM customer: yes
CSM customer: no
Strategic: yes