Bug 215783 - Verify that Installation Numbers can be supplied in the "dashed" format
Verify that Installation Numbers can be supplied in the "dashed" format
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Backend (Show other bugs)
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: James Slagle
Corey Welton
Depends On:
Blocks: 166615
  Show dependency treegraph
Reported: 2006-11-15 13:50 EST by Daniel Riek
Modified: 2007-03-29 11:58 EDT (History)
5 users (show)

See Also:
Fixed In Version: rhn500h
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-29 11:58:14 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 Daniel Riek 2006-11-15 13:50:11 EST
The current format in which we display Subscription Numbers or Registration
Numbers is in gorups of 4 hex characters separated by dashes:


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.

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

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:
Comment 1 James Slagle 2006-11-15 14:10:21 EST
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.
Comment 3 Fanny Augustin 2006-12-04 13:59:08 EST
Not in the client side packages, it is in the backend.  Not a blocker.
Comment 5 Daniel Riek 2006-12-05 10:48:26 EST
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.
Comment 6 James Slagle 2006-12-05 10:51:31 EST
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.
Comment 7 David Lehman 2006-12-06 19:02:53 EST
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.
Comment 8 David Lehman 2006-12-07 09:46:27 EST
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?
Comment 9 Jay Turner 2006-12-07 10:29:47 EST
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.
Comment 10 David Lehman 2006-12-07 10:36:42 EST
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.
Comment 11 Daniel Riek 2006-12-07 13:17:02 EST
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.
Comment 12 Fanny Augustin 2006-12-18 14:55:00 EST
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.
Comment 13 James Slagle 2007-03-29 11:58:14 EDT
this bug should have been blocking rhn500h-must, since it was in that release.

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