Community
Participate
Working Groups
I recently changed email address and now I can't log into gerrit anymore. When I try to connect with my new email address the following message get shown: "cannot assign user name". Previous email address does not work either. Could you please help? Thx.
btw, I can successfully log into the portal or bugzilla.
Can you point me to the URL you used to change your email address? I'll fix your Gerrit account in just a second.
I changed my email on the portal https://dev.eclipse.org/portal/myfoundation/portal/portal.php
Thanks, Pascal. Wayne: when a user changes their email address, we must update other databases, such as Bugzilla, Wiki, Forums, Gerrit, and others... The ldap_community_creator facility performs these updates when site_login is used to change the email address, but the portal does not. We should either remove the ability to change email address in the Portal or update it to use the ldap_community_creator facility. Please see bug 376910 for some background.
I know of two links to change password in the portal. The first, labeled "Password change/reset", is on the login screen. This takes you to https://dev.eclipse.org/site_login/createaccount.php The second is on the "Eclipse Projects" component, labeled "Change my Eclipse.org password" which links to https://dev.eclipse.org/committers/committertools/passwd.php The second feels like the more correct thing, right? Pascal, is there another link that I'm missing?
At the bottom of the portal, you can change your address, postal code, phone number and email address. That's what is causing us some grief. https://dev.eclipse.org/committers/committertools/passwd.php redirects to site_login.
(In reply to Denis Roy from comment #6) > At the bottom of the portal, you can change your address, postal code, phone > number and email address. That's what is causing us some grief. Duh. I have change password locked in my brain. I'm better now. > https://dev.eclipse.org/committers/committertools/passwd.php > > redirects to site_login. I'm not following. What specific URL should I direct email/password changes to?
> I'm not following. What specific URL should I direct email/password changes > to? https://dev.eclipse.org/site_login/myaccount.php https://dev.eclipse.org/committers/committertools/passwd.php is an old Committer Tools link that can also be changed, but it already redirects to the correct location.
This is going to result in some workflow changes. When a committer changes their email address in the portal, it gives them an opportunity to indicate whether or not they've changed employers. An affirmative answer kicks off some workflow to change the record that involves the IP team (I've copied Sharon and Janet). If https://dev.eclipse.org/site_login/myaccount.php is to be the central point for account management (which I think is the right approach), then we need to move the entire address/personal information/organization affiliation change stuff there. That needs to include a means of changing employer. At this point, I think we need to remove the ability to change the email address in the portal and replace it with a link to the account information page. The portal implementation is badly broken.
(In reply to Wayne Beaton from comment #9) > This is going to result in some workflow changes. ... > If https://dev.eclipse.org/site_login/myaccount.php is to be the central > point for account management (which I think is the right approach), then we > need to move the entire address/personal information/organization > affiliation change stuff there. That needs to include a means of changing > employer. > > At this point, I think we need to remove the ability to change the email > address in the portal and replace it with a link to the account information > page. The portal implementation is badly broken. Will the move to the "account information page", trigger the kind of work flow we now see when a change occurs in the portal and there is a confirmation of an employer change? If yes, then I think this works. If no, then retaining the portal change capability is the only means we have today to verify whether additional legal documentation is required, either in the form of a Committer Agreement or Employer Consent Form.
I work for the same employer: yes no What does that trigger? An email? I can't remember where the Portal code is; I'll happily read up if someone can point me to it.
(In reply to Denis Roy from comment #11) > I work for the same employer: yes no > > What does that trigger? An email? I can't remember where the Portal code > is; I'll happily read up if someone can point me to it. AFAICT all that happens is an email is sent to emo-records indicating that the user has changed employers. I think that we're getting to the point where the change of email address does not necessarily imply a change of employers and a change of employers does not necessarily imply a change of email address (e.g. the use of gmail addresses). A committer may not need to change any of their personal information when they change employers and with the way that things are now, there really is no means for them to know to tell us. My suggestion is that, from the "account" page, we should just have a big "I've changed employers" button that sends an email to emo-records on their behalf (probably just a mailto: link). We can then frame the address, email, etc. capture fields with text that says "if you're changing this information because you have a new employer, you need to tell us" (or something to that effect). Further, my suggestion is that we only permit capture address or employer affiliation information for current committers. Should we move this to a new bug?
I've renamed the bug to capture what needs to be done. I agree a button with a mailto: and some explanations are likely sufficient since this is all that happens anyway.
Stage one is to get us into a consistent state. I recommend that we start by removing the email change fields from the portal component. In its place, I'll put a link to the "My Account" page with some text that says "go here to change your email address". The existing "I still work for the same employer" will continue to work as it does today: even if you change nothing else, if you select the "no" radio button, the emails will be sent. When the address/employer change functionality is added to the "My Account" page, stage two is to remove the component entirely. -- For completeness, there's another bit of functionality that sends a message to membership@eclipse.org if the individual has a "membership role" (e.g. planning council representative). The component also lets us capture a picture for the committer. Is this functionality that we want to keep? I'm inclined to restrict what we collect to only that information we actually need. Thoughts?
One more place to automate is the email address in gerrit under "Contact Information" in the field "Preferred Email"
(In reply to comment #14) > I recommend that we start by removing the email change fields from the portal > component. Done. > In its place, I'll put a link to the "My Account" page with some text that says > "go here to change your email address". The existing "I still work for the > same employer" will continue to work as it does today: even if you change > nothing else, if you select the "no" radio button, the emails will be sent. I've added two links. The first directs the user to the account management page: https://dev.eclipse.org/site_login/myaccount.php The second, is a "mailto" link that invites the user to send an email to emo-records with (e.g.) subject: "Wayne Beaton (wbeaton) has changed employers" and body: "I've changed employers. Please help me update my record." The existing employer change functionality exists and will continue to function.
Created attachment 240110 [details] What it looks like now
(In reply to Wayne Beaton from comment #17) > Created attachment 240110 [details] > What it looks like now Thanks for this. I would prefer if we require the Committer to answer a question as to whether they have changed employers or not. It requires the Committer to focus their attention on the question, and has to date been a very reliable means of keeping our Committer Records up to date.
(In reply to Janet Campbell from comment #18) > Thanks for this. I would prefer if we require the Committer to answer a > question as to whether they have changed employers or not. It requires the > Committer to focus their attention on the question, and has to date been a > very reliable means of keeping our Committer Records up to date. The radio buttons on the form still exist. If the user attempts to change any information, they'll be forced to explicitly tell us if they've changed employers before any of the changes are accepted (i.e. it does the same thing it used to do). The "send an email" link catches cases that we might have missed in the past. It's a means by which the user can tell us of the change even if there are no other changes to make. This will only work if the user actually sees the link or at least have some inkling that it's important that they tell us about employer changes. The only other way that I think we could make this better would be to provide a drop-down and let the user select their employer. That drop-down could list only those companies that have an MCA on file with--perhaps--two extra entries: "I don't work for anybody" and "My company doesn't have a Member Committer Agreement" (or something to that effect). We could automate or semi-automate (i.e. require approval) the update of the database. I don't see any reason why this couldn't have been done when the original portal was created, so I assume that there's a good reason to not do this. Is this assumption correct? FWIW, clicking that link opens a "send mail" window with some default contents. The user has to actually send the message. This puts the activity right in the face of the user. I don't think that we can make this any more obvious.
(In reply to Janet Campbell from comment #18) > Thanks for this. I would prefer if we require the Committer to answer a > question as to whether they have changed employers or not. It requires the > Committer to focus their attention on the question, and has to date been a > very reliable means of keeping our Committer Records up to date. I disagree with "very reliable", as I routinely send Sharon bounced emails from committers who have since moved on or relocated without telling us. During the recent election email blast to committers, we must have caught about 20.
(In reply to Denis Roy from comment #20) > (In reply to Janet Campbell from comment #18) > > Thanks for this. I would prefer if we require the Committer to answer a > > question as to whether they have changed employers or not. It requires the > > Committer to focus their attention on the question, and has to date been a > > very reliable means of keeping our Committer Records up to date. > > > I disagree with "very reliable", as I routinely send Sharon bounced emails > from committers who have since moved on or relocated without telling us. > During the recent election email blast to committers, we must have caught > about 20. Well, I didn't say "only reliable". :)
Mine.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
*** Bug 490388 has been marked as a duplicate of this bug. ***
Portal email address and account details information was migrated to accounts.eclipse.org.
