Bug 19271
Summary: | RHN client allows blank Name, Address, City during product activation | ||
---|---|---|---|
Product: | Red Hat Satellite 5 | Reporter: | Martin C. Messer <mmesser> |
Component: | Registration | Assignee: | Cristian Gafton <gafton> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Jay Turner <jturner> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | unspecified | CC: | nobody+jcohen, plindner, skothari, srevivo |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-11-07 18:38:28 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: |
Description
Martin C. Messer
2000-10-17 16:51:10 UTC
Oops, I didn't know Paul wasn't an Assignee for RHN bugs. An example: http://www.redhat.com/support/supportable.html username: silviobruschi Registered on 09/25/00. Never imported. It does bother me that he registered a 6.2 box and not 7. Those are required fields in the rhn_register process, so I think this is probably a problem with the way that we are passing data rather than the client. Marty, Samir, What are the data requirements from the CRM side? Minimum length for address/name? The problem is caused by: User minimally registers on RHN. User then proceeds to register product via the web site. I think we should prompt for the user to fill in their data (like we do in RHN...) However this change needs to happen in more locations. We should require the same information we currently require for a customer to register their product. Test Case for Live and Dev Systems: developer will have to create their own accounts in order to see what characters are being defaulted into "empty" fields. Problem: users are creating profiles using the rhn_register program (but not registering any products) and not supplying all user information (because they are not required to and should not be.) Then the user is logging into their redhat.com accounts they just created and are registering products (which requires that all user information be present.) These records are failing import into Oracle becuase the information which was not provided by the user has been filled in with characters which are not valid for Oracle import (like "." for the address fields. Expected behavior after fix: user will be able to create a profile by providing only username, password and email address; user will then be able to go back to that account and register a product, thus forcing import into Oracle; import will be successful and product will be entitled. The real trick here is not so much the default data you're using in blank fields (which may or may not be the real problem) but that it seems the RHN client is not using the same methods to create user accounts in the web tables. If the redhat.com/join process isn't mirrored completely with this new client, then it will never work, regardless of the defaults you use. More info: the problem is definetly _not_ the '.' in the fields but that the required fields are not being populated at all. I registered this user account today, and was able to activate a product that imported into Oracle: yo_mama Look at the record here: http://www.redhat.com/support/supportable.html As you can see, I have '.' in every required field (other than email and login) and there was no problem on the Oracle end. The problem with the RHN client is that is doesn't put anything in the required fields. The required fields haven't changed in quite a while, and can be found here http://www.redhat.com/join OK, think that we actually have this resolved on the live site. All information from the registration client is making it to the oracle database now. I'm closing this bug out for now. Will reopen if stuff starts to go crazy again. (jkt; 1/17/01) |