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
Here are few tips to avoid the need of inspecting the expired subscriptions, that should be the standard flow. If the subscription expires while there's a need for it, it sounds more like a fire fighting, though with SCA enabled, that shouldn't be needed at all. 1) Every user can subscribe to email notification called "Subscription expiring soon", to do that in the UI, click on your name, select My Account, then choose Email Preferences tab, find the aforementioned notification. Choose how often you want to receive it and select how many days prior the expiration you want to be notified. 2) You can also generate the list of all existing subscriptions through the "Subscription - General Report" report template. That contains Start and End Date. This can be easily rendered e.g. through hammer like this > hammer report-template generate --name 'Subscription - General Report' Such command can be executed from cron periodically and again, sent via email or further processed. I understand that does not solve the ask, but hopefully at least helps to ease the subscription maintenance. Implementing this may not be trivial, as the data gets cleaned from Candlepin on manifest import/refresh.