Red Hat Bugzilla – Bug 215783
Verify that Installation Numbers can be supplied in the "dashed" format
Last modified: 2007-03-29 11:58:14 EDT
The current format in which we display Subscription Numbers or Registration Numbers is in gorups of 4 hex characters separated by dashes: XXXX-XXXX-XXXX-XXXX Example from the mail received after registering for an Eval on redhat.com: [...] The following registration number has been assigned to your riek@redhat.de Red Hat login account. 7be3-d558-62b2-ca6a To activate your evaluation subscription, go to http://www.redhat.com/activate: [...] This is the format we use publicly and that OEMs use for printing registration cards. It currently works in RHEL5 B2 but we need to make sure it continues to work and make sure we test for it. So rhn_register and anaconda need to understand both formats: XXXXXXXXXXXXXXXX -and- XXXX-XXXX-XXXX-XXXX
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.