Bug 156752

james, where's this coming from.  anything in the svn log about why?

David, is there a java satellite I can test this on?  I would also need to know
the db connection info for that satellite.

This exception was raised from an OTHERS clause in PL/SQL when deleting from
web_contact. So, basically I've got no real way to know what the real ora- error
was without testing.  Although I suspect there it's a referential integrity issue.

Sorry, it took me a while to bring rlx-3-06 back to live, and the bug is
definitely reproducible there. It uses its own database (rhnsat/rhnsat@rhnsat).
Login for the web UI is admin with the standard password. Standard password for
root, too. Ping me or mmccune if you run into trouble.

the exception is thrown b/c there is still a child record in rhnUserServerPerms
for the user that is trying to be deleted that used to be an org_admin in
web_contact.

I could modify the rhn_user.delete_server procedure to clean up these records
before attempting to delete from, but I think what probably needs to happen is
that when a user has a role taken away, such as org_admin, you need to call
rhn_cache.update_perms_for_user(user_id_in) for that user.  That way the records
would get cleaned up at that point.

cc'ing Robin, to see if he has any comments about how the perl code handles this.

The perl code doesn't really do anything magical here.  We push the users into a
set (user_group_list), and call a PL/SQL procedure to do the work.

(I think we do it this way for efficiency)

to remove them from the user groups (aka 'roles').  We don't do any cleanup or
anything.

Oh, I do see one thing we do on the perl side that is a bit unusual...after we
call 'remove_users_from_groups', we always call the 'add_users...'
function...which should be a noop if you are removing but not adding, but
perhaps there is a side-effect?

David, when taking org_admin away from a user is the pl/sql
rhn_user.remove_from_usergroup used? rhn_user.remove_from_usergroup calls
rhn_cache.update_perms_for_user(user_id_in) for org_admins, so those child
records should be cleaned up.

I called rhn_user.remove_from_usergroup from sqlplus for a org_admin, removed
them from the org admin group, and then deleted them from the UI, and it succeeded.

*** Bug 161935 has been marked as a duplicate of this bug. ***

SQL> select * from rhnuserserverperms where user_id = 246;

   USER_ID  SERVER_ID
---------- ----------
       246 1000010003
       246 1000010013
       246 1000010035
       246 1000010093
       246 1000010095

SQL> exec rhn_user.remove_from_usergroup ( 246 , 1 );

PL/SQL procedure successfully completed.

SQL> select * from rhnuserserverperms where user_id = 246;

no rows selected

SQL> rollback;

Rollback complete.


Now, I go over to the web ui for user_id = 246, login = testUser1120264613151
Uncheck the org admin role, click Submit, get the User Information Updated banner.

Go back to sqlplus...
SQL> select * from rhnuserserverperms where user_id = 246;

   USER_ID  SERVER_ID
---------- ----------
       246 1000010003
       246 1000010013
       246 1000010035
       246 1000010093
       246 1000010095
       246 1000010160
       246 1000010161
       246 1000010171
       246 1000010182
       246 1000010192
       246 1000010215
       246 1000010278
       246 1000010280
       246 1000010345
       246 1000010346
       246 1000010356
       246 1000010367
       246 1000010377
       246 1000010400
       246 1000010463
       246 1000010466
       246 1000010531
       246 1000010532
       246 1000010542
       246 1000010553
       246 1000010563
       246 1000010586
       246 1000010649
       246 1000010652
       246 1000010717
       246 1000010718
       246 1000010728
       246 1000010739
       246 1000010749
       246 1000010772
       246 1000010835
       246 1000010838
       246 1000010903
       246 1000010904
       246 1000010914
       246 1000010925
       246 1000010935
       246 1000010958
       246 1000011021
       246 1000011024
       246 1000011089
       246 1000011090
       246 1000011100

Not sure where it's getting those rows from.  What pl/sql functions (if any) are
called after remove_from_usergroup?

I'm not sure if the java code is using the pl/sql packages or not for users and
the adding/removing of roles.  If it's not, the code needs to match what's
happening in:

rhn_user.remove_from_usergroup (user_id_in in number, user_group_id_in in number)
and
rhn_user.add_to_usergroup(user_id_in in number, user_group_id_in in number)

This should ensure that all child records related to org_admin roles get cleaned
up, and then you should be able to delete the user.

Fixed @61583

TESTPLAN:
=========

* Go to the Users tab and either create a new user, or click on the name of an
existing user
* Click on the name of the user in the USers list (opens user details page)
* Check 'Organization Administrator' role and click 'Submit'
* Uncheck 'Organization ADministrator' role and click 'Submit'
* Click 'Delete User' link, and on the confirmation page, click 'Delete User' button
* Verify that user is taken back to 'Users' list, and no server error happens.

When I click to confirm the user deletion, I get a Internal Server Error instead
of the Users list.

Sat Build: rhn-satellite-4.0.0-89-redhat-linux-as-i386-4-embedded-oracle.iso

rhn-satellite-4.0.0-89 is too old and doesn't have the fix for this bug. Please
use a satellite ISO that was made after 7/11, e.g., rhn-satellite-4.0.0-91

Looks good on QA