Bug 251746 - editing user details loses "emailConfirmed" flag in User object
editing user details loses "emailConfirmed" flag in User object
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Web Site (Show other bugs)
RHN Stable
All Linux
low Severity low
: ---
: ---
Assigned To: Sebastian Skracic
Amy Owens
Depends On:
Blocks: 446437 447722
  Show dependency treegraph
Reported: 2007-08-10 16:21 EDT by Chris Duryee
Modified: 2008-06-26 16:21 EDT (History)
3 users (show)

See Also:
Fixed In Version: 5.0.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-26 16:21:21 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 Chris Duryee 2007-08-10 16:21:54 EDT
Description of problem:

If you go to https://rhn.redhat.com/rhn/account/UserDetails.do and edit your
user details, then go to
https://www.redhat.com/wapps/ugc/protected/account.html, you'll see that the
user's email address has become unconfirmed.

The email confirmation flag is stored in the PersonalInfo model object that
hangs off of the User model object. I think it may be getting dropped somewhere.

How reproducible: every time

Steps to Reproduce:
1. make a new sso user
2. confirm their email address by clicking the link in the email that's sent out
3. go to RHN and edit the user's details
4. go back to www.redhat.com/wapps/ugc and see that the email address has become
Comment 2 Sebastian Skracic 2008-05-20 08:10:02 EDT
Fixed in r118753.  The culprit was in RHN code not setting the value for
'emailConfirmed' flag, which was being interpreted as 'false' by UserService.
Comment 3 Amy Owens 2008-05-20 09:50:50 EDT
fails qa---
I updated a user (changed first name) and the flag got flipped from yes to no in
-select * from web_user_personal_info where web_user_id =2068412
Comment 4 Amy Owens 2008-05-21 08:25:44 EDT
OK so it looks like RHN fixed our side but there is the case where LDAP has no
value (null) and it carefully sets the value bcak to 'N' when the user updates
there info in RHN.. So here is the test case, have a user where email_confirmed
=Y and LDAP has no value. Update the users first name in RHN, the flag will be
flipped to N (the default in the db for this field is N).  I am cloning this bug
for Grant S and Maintenance Team
Comment 6 Stephen Herr 2008-06-16 14:28:13 EDT
verified in qa

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