Description of Problem: Activation Keys do not assign a system to a base channel. Version-Release number of selected component (if applicable): How Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information:
Renaming this to "Revised Entitlement Policy" so that it can incorporate the entire new entitlement policy. The basic premise for the new policy: if a customer specifies an activation key, use it to the best of your ability, or die with error. If no activation key is specified, entitle them automatically wherever possible -- unless they've specifically chosen a preference on the website that says "don't automatically entitle". This means that, in addition to the changes in the registration code, the following new functionality is required: * When a new org is created, add a default org-level preference for "auto-entitle" and set it to "yes". * Place a new org-level preference on the web site for "auto-entitle". The full policy for this feature is detailed in CVS: CVS/docs/EntitlementPolicy.txt.
*** Bug 75925 has been marked as a duplicate of this bug. ***
Should be on my plate.
Implemented, in devel. Test plan: Comprehensive QA of the registration code is required. Additionally, one should explore a couple of different scenarios. The full algorithm is described in cvs/rhn/docs/EntitlementPolicy.txt - try to break the code with cornercases. - token entitlement - enterprise entitlements available - enterprise entitlements exhausted, basic entitlements available [should fail] - no entitlements available [should fail] - token with no base channel specified - should follow redhat-release - base channel specified in the entitlement token, different than what redhat-release would entitle - should follow the token's - base channel and subchannels specified - subchannels are correctly subscribed - subchannels without an available entitlement specified (like, say, the proxy channel): should not subscribe to these channels - server groups present in the token (not sure if it's implemented web-side) - non-token entitlement - fresh system to a fresh user - should be entitled to basic - create fresh user, grant enterprise slots to that user's org, subscribe systems. Should receive enterprise entitlements first, followed by the free basic entitlement, then no entitlement. Maybe find more test cases...
Setting to high/high and reassigning to jkt.
Testing Activation keys for another bug, so I'll add my results here. All testing was looking good until I tried to creat a custom child channel and select the custom base channel and the child channel: Traceback (most recent call last): File "/usr/sbin/rhnreg_ks", line 294, in ? main() File "/usr/sbin/rhnreg_ks", line 267, in main profileName = profilename) File "/usr/share/rhn/up2date_client/rhnreg.py", line 274, in registerSystem raise up2dateErrors.CommunicationError(f.faultString) up2dateErrors.CommunicationError: Error communicating with server. The message was: While running 'registration.new_system': caught exceptions.TypeError : unexpected keyword argument: commit
Fixed and deployed in devel.
Activation keys seem to work properly in all cases. Still need to test new account registration without tokens.
Non-token stuff works as advertised on dev, closing.