Bug 195248 - [RFE] allow users to view and control entitlement<->contract relationships
[RFE] allow users to view and control entitlement<->contract relationships
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Web Site (Show other bugs)
RHN Stable
All Linux
medium Severity medium
: ---
: ---
Assigned To: Máirín Duffy
Red Hat Satellite QA List
Depends On:
  Show dependency treegraph
Reported: 2006-06-14 12:06 EDT by Jesus M. Rodriguez
Modified: 2008-10-15 11:02 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-15 11:02:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jesus M. Rodriguez 2006-06-14 12:06:18 EDT
Description of problem:

In RHN there is currently no way to determine which system/entitlement is
associated with a particular contract (or vice versa), and therefore no direct
way to determine when an entitlement will expire or when a system will lose its
update priviliges.  As someone pointed out on the RHN list, entitlements are
expired on a last in, first out basis.  This is hardly helpful and actually
counter-intuitive - if contract A is bought for machine X in January, and
contract B is bought for machine Y in June, why would any reasonable person
expect machine Y's entitlement to expire first?  But this is what would happen,
if they were registered in that order and no other changes made.  And "fixing"
it currently requires all systems (or at least all the ones using the same
entitlement level) to be un-registered and then re-registered in REVERSE order
of desired disentitlement.

What I'm requesting is the ability to view within the RHN web interface the
contract<->entitlement<->system relationships, and to be able to reassign them
at will so that the end user has direct control over which system will lose its
update privileges first if a contract expires.

Version-Release number of selected component (if applicable): n/a

How reproducible: always

Steps to Reproduce:
1. register some systems
2. wait until a contract expires

Actual results:

The last system registered (which, logically, should have the most "life" left)
loses its update privileges.

Expected results:

The first system registered should logically lose its update privileges first.
Or, since systems may be un-registered and re-registered for a variety of
reasons, the user should have control over which will expire first via the
ability view and change the association of systems/entitlements with contracts.
Comment 1 Jesus M. Rodriguez 2006-06-14 12:09:39 EDT
Original bugnumber was 194611, this number has been reused by a different bug.
Comment 2 Amanda Carter 2008-10-15 11:02:27 EDT
This bug has been closed due to inactivity.  Please open a new bug with specific details if this problem is still occurring or if an enhancement is needed.

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