Bug 215783
Summary: | Verify that Installation Numbers can be supplied in the "dashed" format | ||
---|---|---|---|
Product: | [Retired] Red Hat Network | Reporter: | Daniel Riek <riek> |
Component: | RHN/Backend | Assignee: | James Slagle <jslagle> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Corey Welton <cwelton> |
Severity: | urgent | Docs Contact: | |
Priority: | urgent | ||
Version: | rhn500 | CC: | borgan, dlehman, jlaska, jslagle, jturner |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | rhn500h | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-03-29 15:58:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 166615 |
Description
Daniel Riek
2006-11-15 18:50:11 UTC
All of the logical parsing to determine if an installation number is valid or not happens server side in RHN. So, both formats would be supported by rhn_register, since it's just going to send it up to the server and wait for a response as to whether it's valid or not. Keeping in mind, however, that for beta2, no numbers will appear valid to RHN. Not in the client side packages, it is in the backend. Not a blocker. Adjusting priority to P1. The issue is that this has to work end-to-end. So if you enter a dashed format in anaconda or rhn_register, it has to work correctly. This might mean removing the dashes in rhn_register. Anaconda currently supports the dashed format while the inderlying rhel-instnum implementation does not. This indicates that Anaconda removes the dashes before using the number. I still consider this a RHEL5 GA blocker. What are you asking for specifically? Please read what I wrote in comment #1. It does not matter if the user inputs the number with dashes or not. We did that to make the usability easier. I'll be adding support to the underlying library (rhel-instnum) to handle dashed numbers. Once that's done, this should be a non-issue. While I'm messing around in the parsing code, are there any other formats I should add support for? maybe 'xxxx xxxx xxxx xxxx'? Or can we say with some certainty that the two formats described in comment #0 are the only ones we are concerned with? Here's a wild and crazy idea . . . what about having 4 boxes, separated by dashes in the UI. Each box capable of having 4 chars entered and the cursor automatically jumping to the next in the series once 4 chars are entered. This would not only force the correct format entry, but also makes it far easier for the user to determine if they are in-fact entering the correct number. Well, we also plan to use 24 and 32 digit numbers at some point (although I don't think the plan includes making users enter them manually). Then there's kickstart. But still, that sounds worth doing if it's not deemed too late. On comment 6: What I ask for is that entering the number in dashed format works. For anaconda it makes sense to actually strip it. I am not sure about rhn_register because of the Dell Service Tag issue. I assmue that just sending everything to the backend and have that take care is a valid approach. But this makes it a requirement for the backend. On comment 10: The problem here would be the longer number we want to be able to support at a later point and immediately the Dell Servie Tag wich is a alphanumeric string. This bug is a server side bug so no client changes are required. In other words, this bug will not affect any RHEL5 packages. This functionality will be deliver with RHN Hosted 500. this bug should have been blocking rhn500h-must, since it was in that release. |