Download & Extend

[regression] Patch to issue 49606 causes all logged in user input to be reset to UID 1 in volunteer form on submit.

Project:volunteer
Version:master
Component:Code
Category:bug report
Priority:critical
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

When appling the patch to issue 49606 to volunteer (http://drupal.org/node/49606 CiviCRM Profiles bleed through when using volunteer; my exact modified file diff: http://drupal.pastebin.com/577497) data inputted by an authenticated user in a volunteer form is reset to the stored contact information for contact_id 1 on submit.

The is 100% reproducable on CivicSpace trunk. To see this problem:
- Create a new site, with the political action profile defaults.
- Create a new event
- Create a new user
- Attempt to volunteer the new user to the event
- See the "completed" message
- Log in as amin and look at the volunteer list -OR- see the auto-genorated email sent to the site's email address.
- Note that it's list UID:1, and not the new users details.

I've debuged this to the following line of the patched version of volunteer:

  elseif ($userID) {
    $params = array('contact_id' => $userID);
    list($values, $options) = crm_contact_search($params);
  }

crm_contact_search is returning the entire list of contacts in the database as an array, sorted by contact_id. It then requests (later on down) $edit = $param_list[0]; which gets the first record, which is always UID: 1.

To see this list add the following code to your patched volunteer.module (around line 432):

  $userID = $user->uid ? crm_uf_get_match_id( $user->uid ) : NULL;
  $action = $userID ? CRM_CORE_ACTION_UPDATE : CRM_CORE_ACTION_ADD;


  //DEBUG
  $data_temp = array('contact_id' => $userID);
  $temp_data = crm_contact_search($data_temp);
  print_r($temp_data);



  //The following call not only generates HTML, it also
  //interacts with the CRM data store:

This will show you what volunteer is seeing.

This tape will self-destruct in 10 seconds....good luck Jim...

Comments

#1

Robin,

As I said, good catch.

I've posted my patch (to CVS HEAD) to http://drupal.org/node/49606, since I also resolved killes' issues over there.

I've tried the patch locally (beta is apparently in DNS transition right now), and it works (I got email, and the record added to CRM looks legit). This one needs a bit of pounding though, since the file is munged up a fair bit.

Hopefully this one's the charm, and we can get RC6 out into the ether.

#2

Status:active» fixed

fixed by http://drupal.org/node/49606

#3

Status:fixed» closed (fixed)