Description of problem: register a new user and it defaults the max_member values to 1 for org_admin and 0 for user applicant by default. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. rhn_register as new user 2. select org_id from web_contact where LOGIN_UC = 'ORGTEST'; ORG_ID ------- 6285639 1 row selected (0.01 seconds) this shows that user has successfully registered and has an org id. 3.for the given org id sql> select group_type,max_members from rhnUserGroup where org_id = 6285639; GROUP_TYPE MAX_MEMBERS ---------- ----------- 1 1 2 0 2 rows selected (0.01 seconds) group_type =1 is org_admin and group_type=2 is org_applicant. So by default the org_admin is set to 1 instead of Null in the backend code. Actual results: max_members =1 for org_admin Expected results: max_members = Null for org_admins Additional info:
apparently for new users, we default the max_members as 1 for admins and 0 for org_applicants this is in User class's __save() in server/rhnUser.py: we do something like: [pkilambi@prad server]$ svn diff Index: rhnUser.py =================================================================== --- rhnUser.py (revision 103273) +++ rhnUser.py (working copy) @@ -238,7 +238,7 @@ tbl = rhnSQL.Row("rhnUserGroup", "id") # Set the default admin limits to 1 tbl.load(adm_grp_id) - tbl["max_members"] = 1 + #tbl["max_members"] = 1 tbl.save() # Set the default applicats limit to 0 tbl.load(app_grp_id) removing out the max members sets the value to Null by default. Which is probably what we want. when i re-register a new user and check the rhnUserGroup with this change: rhnuser@webdev> select group_type,max_members from rhnUserGroup where org_id = 6285945; GROUP_TYPE MAX_MEMBERS ---------- ----------- 1 NULL 2 0 2 rows selected (0.00 seconds) group_type 2(org_admin) for this org_id has a max_member as Null.
the last statement in above comment shoud read: "group_type 1(org_admin) for this org_id has a max_member as Null." that was a typo. Sorry.
Test Plan: 1. Register a new user(say user=org-test) $ rhn_register 2. once the registration is success, on server db run these rhnuser@webdev> select org_id from web_contact where LOGIN_UC = 'ORG-TEST1'; ORG_ID ------- 6318866 3. for the org_id check if the max_members for org_admintype is Null. rhnuser@webdev> select group_type,max_members from rhnUserGroup where org_id = 6318866; GROUP_TYPE MAX_MEMBERS ---------- ----------- 1 NULL 2 0 group type 1 is for org_admin , from: rhnuser@webdev> select id from rhnUserGroupType where label = 'org_admin'; ID -- 1 1 row selected (0.00 seconds) SO if the max_members for group_type=1 is Null in rhnUSerGroup means it works.
Grabbing this bug while I'm in the office: QA Contact -> ssalevan
After registering the account "org-tester" on QA, I ran the following queries: rhnuser@webqa> select org_id from web_contact where LOGIN_UC = 'ORG-TESTER'; ORG_ID ------- 5099631 rhnuser@webdev> select group_type,max_members from rhnUserGroup where org_id = 5099631; GROUP_TYPE MAX_MEMBERS ---------- ----------- 1 NULL 2 NULL As the MAX_MEMBERS for group type 1 == NULL, meaning that this bug has been fixed, I'm moving this to VERIFIED.
Correction: rhnuser@webdev> select group_type,max_members from rhnUserGroup where org_id = 5099631; should actually be: rhnuser@webqa> select group_type,max_members from rhnUserGroup where org_id = 5099631; All tests were done against the webqa database, and I didn't want to confuse anyone about my test methods. Thanks!
moving from VERIFIED to RELEASE_PENDING since stage push is complete
closing -- current release. RHN415 is now in production.
*** Bug 171243 has been marked as a duplicate of this bug. ***