Community
Participate
Working Groups
From 176121 When a committer changes their email address via the Portal, there are other areas where this email address needs to be populated. We previously enforced this manually, as a committer needed to contact the Foundation. The committer's foundation-registered e-mail address must also match in Bugzilla, which will also cascade to IPZilla, and it must be updated in our LDAP directory for password reset and system e-mails.
cc'ing Sharon
And it should update all the mailing list subscriptions.
added to IT request queue
The drawback of this automation is that it will be easy for a committer to change employers without us ever knowing about it. Most committers don't even know that they should tell us. Currently, a red flag is raised when a committer : a) asks us to change the e-mail address, as a result of an employer change b) asks us for a password reset, as a result of not getting password warnings c) has e-mail bounces, as a result of sending mail to the previous employer's address I'm not sure if this is something we need to worry about or not. I'm just putting it out there.
(In reply to comment #4) > The drawback of this automation is that it will be easy for a committer to > change employers without us ever knowing about it. When a committer changes their email address, they are asked if they have changed employers. If they say yes, Anne is notified and then she forwards the notification to Sharon, etc. See the use-case: https://dev.eclipse.org/portal/myfoundation/tests/swim.php?file=finished/change_personal_address_when_person_is_a_committer.txt > I'm not sure if this is something we need to worry about or not. I'm just > putting it out there. It (committers changing employers) is definitely something we should worry about, but I think the portal workflow already has it covered.
Can you create a plaintext file (or append to a plaintext file) the list of old,new email addresses that need to be changed? I'll likely need to create a script/cronjob to update all the sources you mention. My job will delete the plaintext list when it has completed its work.
Is there a way to make the employer change step/question mandatory to be answered? I receive the notifications on these changes and in at least one instance, this question was blank and I had to email the committer. Thanks, Sharon
(In reply to comment #6) > Can you create a plaintext file (or append to a plaintext file) the list of > old,new email addresses that need to be changed? I'll likely need to create a > script/cronjob to update all the sources you mention. > > My job will delete the plaintext list when it has completed its work. Sure... the portal has direct access to the Foundation DB so it could change it there directly. So what about perhaps using the Foundation DB change log to track email changes and have the cron job use that as the source of which things need to be updated? We already write things to the ModLog so it should be no problem to add these when we update the Foundation DB. (In reply to comment #7) > Is there a way to make the employer change step/question mandatory to be > answered? > > I receive the notifications on these changes and in at least one instance, this > question was blank and I had to email the committer. Hmm, it's a required field (at least now it is). Was this recently that you got one without this quetion being answered?
October 24, 2007 was the date that I noticed for one committer - Sharon
(In reply to comment #9) > October 24, 2007 was the date that I noticed for one committer - Sharon > Is is possible that this person was not a committer? That's the only case I can see where they wouldn't get a sentence included in the email to you.
Nope - checked. The person has been a committer for quite some time.
(In reply to comment #8) > So what about perhaps using the Foundation DB change log to > track email changes and have the cron job use that as the source of which Sounds good. If I can query modlog for changes done yesterday where changetype = email, get the old value and set it to the current value in the person table, that would be great.
I'm downgrading the priority on this because it doesn't appear important enough to us to be a P1.
I'm writing something now that will compare FoundationDB mail addresses with their LDAP counterparts. For those that don't match, an email will be sent to webmaster cc SharonC.
DB -> LDAP mail addresses are now diffed and emailed nightly to both Sharon and webmaster so they can be synced up. Committers need to sync their bugs account with the DB for access to IPZilla anyway, and the mailing lists are self-serve. I honestly don't think there's more to do here.
(In reply to comment #15) > the mailing lists are self-serve. I think that from our customer's point of view (customers = committers), the mailing lists are just part of the service that we offer. It doesn't make sense - from a customer point of view - to have to change my email address in a dozen different places. As a customer, I have a relationship with Eclipse and when I go to Eclipse and change my email address, I expect all those places that the email address is used to change as well. It's the same when I go to amazon.com and change my email address: as a customer, I shouldn't care whether they have one back-end database or a dozen. So I do think that we (the EMO) should update the mailing lists when someone changes their email address.
We now have a web API to let us update the mailing lists.
It's been over a year, can we close this as fixed? -M.
(In reply to comment #18) > It's been over a year, can we close this as fixed? > > -M. > No sir. This is still very much under consideration as it's desperately needed.
Ok, we now have bugs tracking the other issues, so closing.
Released or closed for STAGING_324. Please see final comments for actual closure status. This message does not imply that any action was taken that has not already been described.
