Events get associated to the wrong user

[urlisse]

I'm a bit baffled by this bug... It would seem that new Events get added to a previously edited user instead of the one being currently edited, when adding them from the Contact's Event pane. This issue is said to also affect other entities, such as Memberships.

I'm looking either for guidance or a magic solution with unicorns and shining stars, in case I'm in luck...

Here are the steps to reproduce :

1. Access user A page
2. Click on Events tab
3. Add a new event
4. Access user B page
5. Click on Events tab
6. Add a new event

Results: Event gets added to user A!

Alternatively, if I log out, log in, access user A page, add a new event, I get a "Could not find valid value for cid" error messages.

I tried reproducing this bug on demo.civicrm.org, and a blank CiviCRM instance on a same Aegir platform as the live site, without success. That's why I'm posting this request here, and not opening a major issue on JIRA. I can replicate that bug, however, on a clone of the live site.

I'm running a clean CiviCRM 4.1.2 under a clean Drupal 6.26 setup, and the problem also occurred before a recent upgrade from clean CiviCRM 3.4.8, and earlier, and on a different host, too. This website isn't using any consequential custom CiviCRM code and the code base hasn't been fiddled with.

I have seen similar issues on JIRA, and the recommendations were to avoid multiple tabs/windows, disable caching mechanisms, turn off some PHP acceleration features, and make sure we're accessing the site from a same and single URL, which I did. The issue persists.

It would appear that some contextual session values aren't updated when switching from user A (cid=4686, in example below) to user B (cid=20). The (partial) session dump below appear at step 4 when viewing user B. We see that some contextual session values refer to profile A.


Array
(
    [ufID] => 16
    [userID] => 20

[... snip, snip ...]

    [view.id] => 20
    [CRM_Contact_Page_View_Relationship] => Array
        (
            [cid] => 4686
            [action] => 16
            [context] => search
        )

    [userContext] => Array
        (
            [ 0 ] => /civicrm/contact/view?reset=1&cid=4686
            [ 1 ] => /civicrm/event/search?force=1
            [ 2 ] => /civicrm/contact/view?reset=1&cid=20
        )

    [CRM_Event_Page_Tab] => Array
        (
            [action] => 16
            [cid] => 4686
            [context] => search
        )

    [CRM_Contact_Page_View_Summary] => Array
        (
            [cid] => 20
            [context] => search
            [action] => 16
            [contactType] => Individual
            [contactSubtype] =>
            [selectedChild] => summary
        )

    [CRM_Activity_Form_ActivityLinks_d1ec8f2000f7e4361ae51fc431a09349_9738] => Array
        (
            [qfKey] => d1ec8f2000f7e4361ae51fc431a09349_9738
            [cid] => 20
        )
)

I figure that Civi is expecting a cid value to attach the event to, but that the cid hasn't been timely set to the current user before we add the new event. I'm not closely familiar with CiviCRM's session-based form handling routines and I haven't yet dived into the core to attempt to figure out if my intuition is right.

Also, I see that a JavaScript Syntax error occurs in jquery.min.js when switching the value of the "Event" field in "Register New Participant" (but I doubt that's where we fail to set the cid, since this action should have happened before) :

var eventFeeBlockValues = ;

This JS bug looks a bit like CRM-10156, except it happens in a slightly different context. I haven't yet traced back the origin of this bug.

Any help will be appreciated. Thanks for reading me up to here.


PS: sorry for not escaping my code; the forum doesn't like me using the [ code ] tag.

[emilyf]

sounds like you may have already verified this, but just to be sure did you set a single url in .htaccess for drupal arounds line 81 or 88 to ensure it's not adding/removing www for session control? if you can't replicate on demo or the other site but on a clone of this one then it sounds like something related to session,urls/etc.

also triple verify that

resource urls
directories

are set correctly in civi.

and then double check civicrm/admin/setting/updateConfigBackend?reset=1

[Donald Lobo]

can you see if you can reproduce this on drupal6.demo.civicrm.org?

lobo

[urlisse]

Thanks all for your answers.

@emilyf, I quadruple checked ressources urls, directories, updateConfigBackend, the .htaccess (even though all domain names already redirect to a main domain). Everything looks good.

My next steps are : (1) search the database itself for old path and domain name configurations, which may or may not cause this issue; (2) doublecheck the main PHP configuration, namingly by disabling and testing various configurations of suhosin, apc and such; (3) examine the issue more closely by tracing my requests in the core.

@lobo, I wasn't able to replicate the error on drupal6.demo.civicrm.org, but I will attempt to do so once I find out what's going wrong more exactly.

[urlisse]

While examining this issue, I found that, on some occasions when adding a new participant (civicrm/contact/view/participant?reset=1&action=add&cid=20&context=participant), the smarty variable $eventFeeBlockValues doesn't get set in the EventFees.tpl template file, which causes the JavaScript error listed above.

I don't know if this should always be the case, that it gets set. I rewrote the JavaScript anyway not to break in case it doesn't. This seems like a good practice to me, except if the JS error is actually helping us prevent a graver danger! Before turning this into a formal patch, can anyone educate me about whether the lack of an $eventFeeBlockValues could be a sign that something else is very wrong?

Thank you. Here are the lines I changed :

civicrm/templates/CRM/Event/Form/EventFees.tpl (around lines 286,287) :

Code: [Select]

var eventFeeBlockValues = {/literal}{$eventFeeBlockValues|default:"new Object()"}{literal};
totalAmount = eventFeeBlockValues['amount_id_'+ amountVal];

(Gosh, these forum reply captcha letter make me feel like I'm an old Timex Sinclair 1000...)

[urlisse]

For the record, the issue was indeed related to session management. However, nor the Drupal cache or the server configuration was responsible for mixing up input parameters with past session values when saving CiviCRM forms.

I've tracked down the issue to the Drupalchat module, which appears to cause Drupal sessions to get mixed up when used in pair with certain modules, such as CiviCRM. Turning off the Drupalchat module solved all of our problems.

I've opened a Drupal issue about it : http://drupal.org/node/1650980