Answers.Body: <p>Just answering this for anyone else who sees this. The case above was confirmed by Brad Bell and was fixed in <a href="https://craftcms.com/changelog#2-6-2984" rel="nofollow noreferrer">Craft 2.6.2984</a>. So, going forward, the scenario described above should return an error to handle.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T22:05:29.553Z
Answers.LastActivityDate: 2017-07-21T22:15:47.293Z
Answers.LastEditDate: 2017-07-21T22:15:47.293Z
Answers.UserDisplayName: Mike
Body: <p>We have a front end form for a logged in user to change their Username (email). In our testing, it does not appear to check against and prevent selecting an email address that's already taken (like happens on a login form). However, our Create Account from - which is almost identical - works.</p>
  
  <p>This Form (our create account form) works and catches duplicate emails and returns an error:</p>
  
  <pre><code>&lt;form id="createForm" method="post" accept-charset="UTF-8"&gt;
  
      {{ getCsrfInput() }}
      &lt;input type="hidden" name="action" value="users/saveUser"&gt;
      &lt;input type="hidden" name="redirect" value="{{ siteUrl }}account/signup-sent"&gt;
      &lt;div class="input"&gt;
          &lt;label&gt;Email &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
          &lt;input id="signupEmail" name="email" placeholder="Email" value="" data-parsley-type="email"&gt;
      &lt;/div&gt;
      &lt;div class="input"&gt;
          &lt;label&gt;Confirm Email &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
          &lt;input id="confirmEmail" placeholder="Confirm Email" value="" data-parsley-type="email"&gt;
      &lt;/div&gt;
      &lt;div class="input"&gt;
          &lt;label&gt;Password &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
          &lt;input name="password" id="password" type="password" placeholder="Password" value=""&gt;
      &lt;/div&gt;
      &lt;div class="input"&gt;
          &lt;label&gt;Confirm Password &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
          &lt;input name="confirmPassword" id="confirmPassword" type="password" placeholder="Confirm Password" value=""&gt;
      &lt;/div&gt;
      &lt;input type="hidden" name="fields[accountReceiveEmails]" value=""&gt;
      &lt;div class="checkbox"&gt;
          &lt;input type="checkbox" name="fields[accountReceiveEmails][]" value="yes" id="emailOptin"&gt;
          &lt;label for="emailOptin"&gt;&lt;span class="checkbox"&gt;&lt;span&gt;&lt;/span&gt;&lt;/span&gt;Yes, I would also like to receive offers, discounts and news for Cadex products by email.&lt;/label&gt;
      &lt;/div&gt;
      &lt;footer&gt;
          &lt;button&gt;Create Account&lt;/button&gt;
      &lt;/footer&gt;
  &lt;/form&gt;
  </code></pre>
  
  <p>This is our form for users logged into their account. It does not return an error when a user tries changing their email to one that already exists in another account:</p>
  
  <pre><code>&lt;form id="profileCredsForm" method="post" accept-charset="UTF-8"&gt;
      {{ getCsrfInput() }}
      &lt;input type="hidden" name="action" value="users/saveUser"&gt;
      &lt;input type="hidden" name="redirect" value="account/profile/saved"&gt;
      &lt;input type="hidden" name="userId" value="{{ currentUser.id }}"&gt;
      &lt;div class="input"&gt;
          &lt;label&gt;Current Password &lt;span&gt;*&lt;/span&gt;&lt;/label&gt;
          &lt;input id="currentPassword" name="password" placeholder="Current Password" value="" data-parsley-required="true"&gt;
      &lt;/div&gt;
  
      &lt;div class="input"&gt;
          &lt;label&gt;New Password&lt;/label&gt;
          &lt;input name="newPassword" id="newPassword" type="password" placeholder="New Password" value=""&gt;
      &lt;/div&gt;
      &lt;div class="input"&gt;
          &lt;label&gt;Confirm New Password&lt;/label&gt;
          &lt;input name="confirmNewPassword" id="confirmNewPassword" type="password" placeholder="Confirm New Password" value=""&gt;
      &lt;/div&gt;
  
      &lt;div class="input"&gt;
          &lt;label&gt;New Email&lt;/label&gt;
          &lt;input id="email" name="email" placeholder="New Email" value=""&gt;
      &lt;/div&gt;
      &lt;div class="input"&gt;
          &lt;label&gt;Confirm New Email&lt;/label&gt;
          &lt;input id="confirmNewEmail" placeholder="Confirm New Email" value=""&gt;
      &lt;/div&gt;
  
      &lt;button type="submit"&gt;Update&lt;/button&gt;
  &lt;/form&gt;
  </code></pre>
  
  <p>We've tested this repeatedly, changing an email to one for another existing account and no error is returned, the form submits and the email is sent to confirm the new email address.</p>
  
  <p>Also, as an aside, the confirm link in the follow up email seens to ignore the <code>activateAccountSuccessPath</code> set in our config. Is that expected behaviour?</p>
  
  <p>Thanks.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-15T23:02:32.187Z
Comments.Text: You're saying you've got one form where it works as expected and an identical form where it doesn't?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-15T23:21:10.323Z
Comments.Text: I've expanded the original post with both forms. While not literally identical, I cannot see any functional difference between them that would affect this behaviour (if, indeed, logged in users should be prevented from updating their email (username) to one that already exists). FYI, twig error code and client side validation has been removed for clarity.
Comments.UserDisplayName: Mike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-15T23:58:08.777Z
Comments.Text: As far as Craft is concerned, the first is going to register a new user and the latter is going to edit an existing user.  But I just did a test case with your 2nd form and changed the email to another existing email address and got the expected "Email "a@b.com" has already been taken." validation error.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-16T00:02:12.097Z
Comments.Text: Wow... ok, thanks Brad. Not certain what is going on then. We have Commerce installed also but I assume that should have no affect, correct?
Comments.UserDisplayName: Mike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-16T00:05:56.877Z
Comments.Text: Wouldn't think so... if you've got xdebug.org installed, throw a breakpoint in Craft's `craft/app/controllers/UsersController->actionSaveUser()` and that might shed some light on what's going on.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-16T00:13:43.433Z
Comments.Text: Ok... and just curious. Should the verify email link in this scenario bypass a `activateAccountSuccessPath`?
Comments.UserDisplayName: Mike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-16T01:40:10.813Z
Comments.Text: Not at computer, but I'd guess so? The account is already activated for an existing user, you're just verifying the email.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-16T03:31:15.573Z
Comments.Text: Thanks Brad. Can we pursue this further through another channel? I have been able to reproduce this behaviour consistently on a new, clean install of Craft in a new environment with absolutely barebones forms. I'm guessing your test had one of two things different.
Comments.UserDisplayName: Mike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-16T18:40:15.927Z
Comments.Text: Can send a database dump, templates and steps to reproduce over to support@craftcms.com and we can try it there.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-19T18:11:33.933Z
Comments.Text: Just totally throwing this out there, but Craft has elevated sessions to that if you change an email or username, Craft will ask for the currently logged in users' password to confirm the change. Perhaps since it  isn't getting that, its skipping everything and sending the verify email anyway?
Comments.UserDisplayName: Damon
Tags: <users>
Title: Changing Username On Front End To Another Account Email
ThreadText: # Changing Username On Front End To Another Account Email
  
  (Asked by: username_0 on 2017-06-15)
  
  We have a front end form for a logged in user to change their Username (email). In our testing, it does not appear to check against and prevent selecting an email address that's already taken (like happens on a login form). However, our Create Account from - which is almost identical - works.
  
  This Form (our create account form) works and catches duplicate emails and returns an error:
  
  ```
  <form id="createForm" method="post" accept-charset="UTF-8">
  
      {{ getCsrfInput() }}
      <input type="hidden" name="action" value="users/saveUser">
      <input type="hidden" name="redirect" value="{{ siteUrl }}account/signup-sent">
      <div class="input">
          <label>Email <span>*</span></label>
          <input id="signupEmail" name="email" placeholder="Email" value="" data-parsley-type="email">
      </div>
      <div class="input">
          <label>Confirm Email <span>*</span></label>
          <input id="confirmEmail" placeholder="Confirm Email" value="" data-parsley-type="email">
      </div>
      <div class="input">
          <label>Password <span>*</span></label>
          <input name="password" id="password" type="password" placeholder="Password" value="">
      </div>
      <div class="input">
          <label>Confirm Password <span>*</span></label>
          <input name="confirmPassword" id="confirmPassword" type="password" placeholder="Confirm Password" value="">
      </div>
      <input type="hidden" name="fields[accountReceiveEmails]" value="">
      <div class="checkbox">
          <input type="checkbox" name="fields[accountReceiveEmails][]" value="yes" id="emailOptin">
          <label for="emailOptin"><span class="checkbox"><span></span></span>Yes, I would also like to receive offers, discounts and news for Cadex products by email.</label>
      </div>
      <footer>
          <button>Create Account</button>
      </footer>
  </form>
  
  ```
  
  This is our form for users logged into their account. It does not return an error when a user tries changing their email to one that already exists in another account:
  
  ```
  <form id="profileCredsForm" method="post" accept-charset="UTF-8">
      {{ getCsrfInput() }}
      <input type="hidden" name="action" value="users/saveUser">
      <input type="hidden" name="redirect" value="account/profile/saved">
      <input type="hidden" name="userId" value="{{ currentUser.id }}">
      <div class="input">
          <label>Current Password <span>*</span></label>
          <input id="currentPassword" name="password" placeholder="Current Password" value="" data-parsley-required="true">
      </div>
  
      <div class="input">
          <label>New Password</label>
          <input name="newPassword" id="newPassword" type="password" placeholder="New Password" value="">
      </div>
      <div class="input">
          <label>Confirm New Password</label>
          <input name="confirmNewPassword" id="confirmNewPassword" type="password" placeholder="Confirm New Password" value="">
      </div>
  
      <div class="input">
          <label>New Email</label>
          <input id="email" name="email" placeholder="New Email" value="">
      </div>
      <div class="input">
          <label>Confirm New Email</label>
          <input id="confirmNewEmail" placeholder="Confirm New Email" value="">
      </div>
  
      <button type="submit">Update</button>
  </form>
  
  ```
  
  We've tested this repeatedly, changing an email to one for another existing account and no error is returned, the form submits and the email is sent to confirm the new email address.
  
  Also, as an aside, the confirm link in the follow up email seens to ignore the `activateAccountSuccessPath` set in our config. Is that expected behaviour?
  
  Thanks.
  
  **Tags:** users
  
  > **Comments:**
  > **username_1**: You're saying you've got one form where it works as expected and an identical form where it doesn't?  
  > **username_0**: I've expanded the original post with both forms. While not literally identical, I cannot see any functional difference between them that would affect this behaviour (if, indeed, logged in users should be prevented from updating their email (username) to one that already exists). FYI, twig error code and client side validation has been removed for clarity.  
  > **username_1**: As far as Craft is concerned, the first is going to register a new user and the latter is going to edit an existing user.  But I just did a test case with your 2nd form and changed the email to another existing email address and got the expected "Email "a@b.com" has already been taken." validation error.  
  > **username_0**: Wow... ok, thanks username_1. Not certain what is going on then. We have Commerce installed also but I assume that should have no affect, correct?  
  > **username_1**: Wouldn't think so... if you've got xdebug.org installed, throw a breakpoint in Craft's `craft/app/controllers/UsersController->actionSaveUser()` and that might shed some light on what's going on.  
  > **username_0**: Ok... and just curious. Should the verify email link in this scenario bypass a `activateAccountSuccessPath`?  
  > **username_1**: Not at computer, but I'd guess so? The account is already activated for an existing user, you're just verifying the email.  
  > **username_0**: Thanks username_1. Can we pursue this further through another channel? I have been able to reproduce this behaviour consistently on a new, clean install of Craft in a new environment with absolutely barebones forms. I'm guessing your test had one of two things different.  
  > **username_1**: Can send a database dump, templates and steps to reproduce over to support@craftcms.com and we can try it there.  
  > **username_2**: Just totally throwing this out there, but Craft has elevated sessions to that if you change an email or username, Craft will ask for the currently logged in users' password to confirm the change. Perhaps since it  isn't getting that, its skipping everything and sending the verify email anyway?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-07-21. Score: 1
  
  Just answering this for anyone else who sees this. The case above was confirmed by username_1 username_1 and was fixed in [Craft 2.6.2984](https://craftcms.com/changelog#2-6-2984). So, going forward, the scenario described above should return an error to handle.
  
  
  ---
  
  