Bug 251746 - editing user details loses "emailConfirmed" flag in User object
Summary: editing user details loses "emailConfirmed" flag in User object
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Web Site   
(Show other bugs)
Version: RHN Stable
Hardware: All Linux
low
low
Target Milestone: ---
Assignee: Sebastian Skracic
QA Contact: Amy Owens
URL: https://rhn.redhat.com/rhn/account/Us...
Whiteboard: US=22101
Keywords:
Depends On:
Blocks: 446437 447722
TreeView+ depends on / blocked
 
Reported: 2007-08-10 20:21 UTC by Chris Duryee
Modified: 2008-06-26 20:21 UTC (History)
3 users (show)

Fixed In Version: 5.0.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-26 20:21:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Chris Duryee 2007-08-10 20:21:54 UTC
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
unconfirmed

Comment 2 Sebastian Skracic 2008-05-20 12:10:02 UTC
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 13:50:50 UTC
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 12:25:44 UTC
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 18:28:13 UTC
verified in qa


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