2

CiviCRM 4.6.2 / Wordpress

On the civi change log we have spotted a edits of contact records entered by one user are being recorded as edits by another user. Any ideas on how this might happen, what can be done to stop it happening?

Improve this question

4 Answers 4

Reset to default
6

There are two main causes that I can think of.

  1. The person doing the editing was doing it whilst logged in as the other person. Possible scenarios and suggested 'solutions' are:

    • shared computers where the other person didn't log out when they had finished and the editor didn't bother to sign in as themselves. Solution: Remind all concerned of the importance of logging out when finished and of using their own log in.
    • The editor is able to masquerade as the other person and was doing so when making the changes Solution: Remind editor that they should not make changes whilst masquerading as someone else OR revoke their masquerade priviledges.
    • The editor knows the password of the other person and deliberately logged in as that user. Solution: Get the other person to change their password and keep it private.

  2. The table that links wordpress user to civicrm contact record has become (or was for a while) corrupted so that the wordpress login for the editor is/was linked to the civicrm record for the other person. (This could happen for a drupal-based site if the uf_match table was corrupted. I presume there is something similar in wordpress, but I don't really know.)

Improve this answer
5
  • It is not a shared computer scenario. I have also seen this happen live in a training session, where user1 edited a record logged in as themselves and it was then recorded as user2. ie not an issue of using of user1 being signed in as user2, or user1 knowing user2's password. You mention revoking 'masquerade privileges'... first I have heard of these where are they set/revoked in Civi?
    – Catherine
    Apr 15, 2016 at 16:59
  • Perhaps 'masquerading' is not available in Wordpress. In Drupal there is a module you can install that lets you give admins the ability to masquerade as someone else to help troubleshoot user problems. As you know nothing about maquerading probably that is not the problem.
    – JoAnne
    Apr 16, 2016 at 0:43
  • 1
    The sentence: "I have also seen this happen live in a training session, where user1 edited a record logged in as themselves and it was then recorded as user2." rings alarm bells. Every training session I have been at has each person having their own civicrm installation so that they can complete set exercises independently. In that situation there would be no way for the changes made by user1 to be recorded as being made by user2 unless there was mismatch in the wordpress equivalent of uf_match such that the wordpress login for user1 is linked to the civicrm contact record for user2.
    – JoAnne
    Apr 16, 2016 at 0:49
  • Unfortunately that was the situation. Thanks for your help.
    – Catherine
    Apr 18, 2016 at 7:51
  • 3
    Please accept this as the answer to help others users find correct answers
    – JoAnne
    Apr 18, 2016 at 11:50
5

JoAnne's answer is excellent. There's a third scenario I should add, however.

Sometimes, staff will try to register someone else for an event from the frontend without logging out. (Profiles in edit mode, petitions, and contribution pages do this too, but events seem most common.) They enter the other contact's name and email, and when they're done, CiviCRM has the other person's information in the first user's contact.

There is a notice about this at the top of contribution and event forms, complete with a link to let you fill out the form not as yourself (it tacks on &cid=0 to the URL). However, that notice is frequently missed.

Improve this answer
2
  • agreed. want to add about how to avoid this by using the link available for events to register others, or the cid=0 option?
    – petednz - fuzion ♦
    May 15, 2016 at 20:40
  • @petednz-fuzion done--good suggestion!
    – Andie Hunt
    May 19, 2016 at 0:21
1

If you have logging enabled /civicrm/admin/setting/misc?reset=1 then you should be able to track back via the changelog Tab on the record and see when things went awry which might shed some light on why this is happening.

Improve this answer
1

Finally figured out what happened on this. It looks like at the point of moving from Drupal to Wordpress the assocation between the user account and the civi contact were mismatched.

Did a manual fix through the front end (just 10 records impacted). On the contact record, click the user id link which takes you though to the user account record. Where these were mismatched we modified the contact record to match the user record. Job done. Lesson to self: don't forget the user/contact relationship!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.