Modification of incorrect user when several users open

[Chris Burgess]

^{Forum admin: this is not really in the right forum, as it turned out to be more than a "Usability improvement" - please relocate if suitable.}

I've had a few users report the following behaviour, and would like to sound out if it's something which is easily addressed.

If you're the sort of user who uses many tabs to speed up workflows (by searching for "Address needs fixing", then opening several tabs and editing each one in turn), CiviCRM can have an unexpected behaviour.

Here's how to see it in action:

1. Search for a common term (eg surname "Smith")

2. Open several browser tabs for the first few users. Alice, Bill, Chetan.

3. With tabs open for Alice, Bill and Chetan, select the custom tab (suggest you use "multi") in each browser tab and choose the "Edit" link.

3a. Check that you have edit forms open for all three contacts before progressing to step 4. (It seems this is key to duplicating the issue.)

4. Update and save custom data for each contact in turn. (Suggest you use custom tab "Multi" and enter the name of the contact it appears you are editing.)

4. When the custom data values are saved for Alice, the displayed contact is Alice.

5. When the custom data values are saved for Bill and Chetan, the displayed contact is also Alice, and the custom data seems to have been updated for Alice, not for Bill / Chetan.

I believe that after editing the custom data for any contact, the displayed contact is usually the contact whose summary screen was displayed last - not the contact just edited.

I'm not sure of what the rule applied in 5 is - perhaps that we only set "return to this contact" when displaying the summary screen, rather than when displaying custom data screens also? Or perhaps that when we display the edit form for custom data, we set the CID into a session var, and this is not handled when a second edit screen is opened after the first, and before the first edit screen is saved.

When I view the custom data edit screen for the users, the CID is in the URL. The resulting form does not contain a CID reference that I can see, and seems to store the data against the contact which CiviCRM has selected internally, not the contact which appears to be getting edited.

Initially I was reporting this only as display of incorrect contact. However, my test showed that in some cases the data was stored against the wrong contact - perhaps in cases where multiple edit forms were displayed at once?

Ticket opened: http://issues.civicrm.org/jira/browse/CRM-2876

[Chris Burgess]

I'll risk beginning a monologue here There seem to be two (likely related) issues at work here - Pete identified a separate issue which helped me work out why this behaviour was confusing me.

1. If you use multiple tabs, and operate the edit custom data forms sequentially, the final contact displayed will be the one whose summary screen was displayed last - not (necessarily) the one just edited.

2. If you use multiple tabs, and open multiple edit forms simultaneously, then the custom data entered may be stored against a contact other than the one suggested when the form is displayed.

[petednz]

Interupting your monologue briefly. Just spotted it happened just now even though I only had one of several contacts windows opened.

Opened several contacts. Changed one. CLosed it. Changed next and upon hitting save it brought back the view?action=browse&selectedChild=rel of a contact I had already closed the window of.

The data had been saved correctly, but it is both disconcerting, and breaks the workflow as in order to do the next change to that contact i have to reaccess it from somewhere.

[Donald Lobo]

This is a known issue with the framework. We do have a workaround for this and we've implemented it in the 'Edit' forms. I've moved the issue to 2.1 and we'll implement the same workaround for the custom data form. This increases the size of the session (and we store a lot of info in the session), hence the hesitancy to introduce it in all forms.

lobo

[Chris Burgess]

We'd be interested to know more about the workaround you implemented for the Edit forms - might look at fixing it for our 2.0 install as well if feasible. Is there a previous ticket we can refer to in order to see the changes made to address the issue on non-custom data forms?

Can you tell us more about which of the two issues (displaying the wrong contact after edit, and editing the wrong contact) have been addressed already in the main Edit forms?

[Donald Lobo]

The workaround is quite simple and generic

There is a parameter called "addSequence" in CRM/Core/Controller.php which is by default set to false.

The 'Edit' form sets it to true. The custom edit form also needs to set this to true. We've propagated this variable to the constructor of CRM/Utils/Wrapper.php so it should be a relatively easy fix

most likely the fix is in:

CRM/Contact/Page/View/CustomData.php, line 101

Code: [Select]

       
      $controller =& new CRM_Core_Controller_Simple('CRM_Contact_Form_CustomData', ts('Custom Data'), $this->_action, false, true);

This should fix both the issues (i think)

lobo

[Chris Burgess]

Thanks Lobo

I also noticed today that if I load a custom search form A in tab A, then load a custom search form B in tab B, pressing "submit" in tab A will show the results of custom search B.

Is this similar enough to be included in the same issue?

[Donald Lobo]

yep

lobo

[Chris Burgess]

Lobo, this issue was fixed for user modification a while back, but I wonder if it's still around for other forms?

http://issues.civicrm.org/jira/browse/CRM-2876

We recently had a user who was editing custom data fields, and this issue bit him and resulted in the loss of a live data column (which he brought on screen to compare, after loading the one marked for deletion). He was using 2.0. Luckily we had DB backups to restore from, but it caused some alarm nevertheless

Would be good to know if this fix will be / has been generalised throughout the rest of CiviCRM?

[Chris Burgess]

Just a nudge to see if anyone knows whether the issues with multiple CiviCRM forms being loaded in several tabs has been generalised throughout the CiviCRM interface.

Are all forms safe to use with multiple windows / tabs now?

[Donald Lobo]

unfortunately not

I suspect we'll take a look at fixing it when we switch out frameworks and use something more recent / relevant (Zend/Cake etc)

lobo

[davej]

Hi,

We've had this report from a user of similar problems with 3.1.3:

When I have two records of the same type (e.g. events, individual info, etc.)
 open in different tabs of the same browser on edit and I save one of
them, the changes saved on one tab are saved to the record open on the other
tab - the one that was opened second.

For instance, today, I was copying settings from one event with small
modifications, but the changes were saved to the wrong event.

We've talked about this several months ago but it's becoming more of a
problem that I think needs to be brought to the attention of the Civi team.

Good to hear that it will be addressed but when is the framework switch planned for?

Dave J

[Donald Lobo]

this is fixed in 3.2 for most cases (there might be a few instances where it is not, but that is considered a bug and an issue should be filed for it)

lobo