Bug 195248 - [RFE] allow users to view and control entitlement<->contract relationships
Summary: [RFE] allow users to view and control entitlement<->contract relationships
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Network
Classification: Retired
Component: RHN/Web Site
Version: RHN Stable
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Máirín Duffy
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-06-14 16:06 UTC by Jesus M. Rodriguez
Modified: 2008-10-15 15:02 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-10-15 15:02:27 UTC
Embargoed:


Attachments (Terms of Use)

Description Jesus M. Rodriguez 2006-06-14 16:06:18 UTC
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 16:09:39 UTC
Original bugnumber was 194611, this number has been reused by a different bug.

Comment 2 Amanda Carter 2008-10-15 15:02:27 UTC
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.