Answers.Body: <p>Ideally, the day-to-day workflow of entering contributions/memberships for your staff should be to use the back-end forms, not the front-end forms, so you don't experience this.  However, to help with this transition, you may want to consider installing the "no overwrite" extension, which prevents the problem you're describing: <a href="https://civicrm.org/extensions/no-overwrite">https://civicrm.org/extensions/no-overwrite</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T17:42:05.177Z
Answers.LastActivityDate: 2015-03-24T17:42:05.177Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>You should also consider giving your staff their own personal user accounts for a number of reasons.</p>
  
  <ul>
  <li>It will be clear that they're acting as themselves rather than as a generic staff person</li>
  <li>You can isolate the culprit(s) who are recording memberships the wrong way (see Jon's answer), meaning they don't cause problems for others and you can talk with them specifically</li>
  <li>When people leave the organization, change roles, etc. you don't need to change the password for everyone</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T20:51:18.043Z
Answers.Text: I never thought of this. I think we will move in this direction.
Answers.UserDisplayName: P a u l
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T19:52:30.200Z
Answers.LastActivityDate: 2015-03-24T19:52:30.200Z
Answers.UserDisplayName: Andie Hunt
Body: <p>I installed the latest CiviCRM on WordPress. WordPress is set up to refuse new accounts to the public, and there are about 12 utility admin/editor related accounts not tied to a specific person: AdminCrm, Editor, Staff1, Staff2, etc. </p>
  
  <p>There is an ongoing problem if the logged-in user uses or tests a contribution page, because CiviCRM mixes up the current WordPress login with the user's contact information. The person logged into WordPress is invariably a member of the organization, and if they renew their membership while logged into one of these utility accounts, the email address for the renewal is copied from that of the <em>current</em> login which results in a duplicate contact created.</p>
  
  <p>It would be nice if there was some way to turn off this behavior. I think CiviCRM on Wordpress was designed to assume contacts were always linked to a Wordpress login. Need suggestions on how to handle this day-to-day.</p>
  
Tags: <wordpress><cms-integration>
Title: How can we avoid staff users overwriting emails of utility WordPress accounts when testing CiviContribute pages?
ThreadText: # How can we avoid staff users overwriting emails of utility WordPress accounts when testing CiviContribute pages?
  
  (Asked by: username_0 on 2015-03-24)
  
  I installed the latest CiviCRM on WordPress. WordPress is set up to refuse new accounts to the public, and there are about 12 utility admin/editor related accounts not tied to a specific person: AdminCrm, Editor, Staff1, Staff2, etc.
  
  There is an ongoing problem if the logged-in user uses or tests a contribution page, because CiviCRM mixes up the current WordPress login with the user's contact information. The person logged into WordPress is invariably a member of the organization, and if they renew their membership while logged into one of these utility accounts, the email address for the renewal is copied from that of the *current* login which results in a duplicate contact created.
  
  It would be nice if there was some way to turn off this behavior. I think CiviCRM on Wordpress was designed to assume contacts were always linked to a Wordpress login. Need suggestions on how to handle this day-to-day.
  
  **Tags:** wordpress, cms-integration
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-03-24. Score: 8 | Accepted answer
  
  You should also consider giving your staff their own personal user accounts for a number of reasons.
  
  * It will be clear that they're acting as themselves rather than as a generic staff person
  * You can isolate the culprit(s) who are recording memberships the wrong way (see Jon's answer), meaning they don't cause problems for others and you can talk with them specifically
  * When people leave the organization, change roles, etc. you don't need to change the password for everyone
  
  > **Comments:**
  > **username_0**: I never thought of this. I think we will move in this direction.  
  
  ---
  
  ### Answer by username_1 on 2015-03-24. Score: 7
  
  Ideally, the day-to-day workflow of entering contributions/memberships for your staff should be to use the back-end forms, not the front-end forms, so you don't experience this. However, to help with this transition, you may want to consider installing the "no overwrite" extension, which prevents the problem you're describing: <https://civicrm.org/extensions/no-overwrite>
  
  
  ---
  
  