CiviCRM Profiles bleed through when using volunteer
| Project: | volunteer |
| Version: | HEAD |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Torenware |
| Status: | closed |
Hello all!
I'm having trouble with other CRM profiles "bleeding" through on my volunteer page. In other words,
1. create additional CRM profiles at => PathToDomain/civicrm/admin/uf/group
2. in the profile settings, if "Profile" is selected (as opposed to User Registration or View/Edit User Account), all those CRM profiles that are marked "used for profile" appear when a user volunteers for an event. This is regardless of the permissions set on the profile itself as in... User and User Admin Only or Public User Pages and Listings.
If I understand the volunteer module correctly, the behavior I would expect is that an admin selects the CiviCRM profile form for volunteers here => PathToDomain/admin/settings/volunteer
Only the profile selected in the volunteer admin settings should appear when a user volunteers for an event.
Right now, ALL profiles appear when a user volunteers for an event that have been designated as => "user for profile"
thx,
#1
I snatched this from CVS, not Drupal 4.6 - sorry!
#2
This appears to be a function of whether the user is logged in or not.
If logged in, you get the correct profile as specified in admin/settings/volunteer.
If not logged in, you get all eligable profiles (i.e., any profile that has an email field).
I'll investigate the uid = 0 case and see why this is.
#3
Lobo's given me something to try. Patch coming up soon.
#4
Figured the buggah out. Patch is against CivicSpace trunk.
If someone can verify that this makes the pain go away, much obliged.
#5
All patches need to be against CVS. I believe head in this case.
Kieran
#6
Hm... patched against the wrong tree. Here's the patch against Drupal CVS.
#7
please run cvs up before creating patch, it was created against an old version of volunteer.module.
#8
Will do. For now, I'm going to post the module as I have it, since I'll need to resolve any conflicts later. For now, let's figure out if this puppy works.
After working with Lobo, it's clear that the module for interacting with CRM is a little different than most of us thought; short version is that crm_get_profile_html() is the Swiss Army knife of the API for playing with profiles; it not only generates the html used in profile edit forms, it also does any extraction or writing of data to the data store as well. So protocol needs to be (1) call crm_get_profile_html(), and (2) get back the affected contact object and get your munged data from there (and not from $_POST). The code in volunteer_volunteer and volunteer_volunteer_form is commented a fair bit, so you should be able to see the method in all the madness.
As soon as Lobo and you are happy with the beast, I'll check it into the CVS HEAD.
Rob
#9
changing status for previous entry.
#10
Gehrhart -- actually, you're gonna be doing the checking in. But same general idea...
Rob
#11
Gerhard -- OK, hopefully this patch is in the form you want. Against CVS v 1.53, which is at the tip as I write this.
#12
Rob, why did you remove my calls to db_set_active()?
#13
> Rob, why did you remove my calls to db_set_active()?
They are unneeded since db_set_active() is a Drupal API, and does not in fact affect CRM in any way. CRM is using PEAR libraries to access the database, and ignores db_set_active(), which is setting a global used by the Drupal database abstraction layer:
<?phpfunction db_set_active($name = 'default') {
global $db_url, $db_type, $active_db;
static $db_conns;
?>
While you were extremely careful to match calls (and therefore, was causing no harm), a less careful coder might forget to make the restoring call to db_set_active(), which would not be so good. I spoke with Lobo about this, and the recommendation was to remove the calls.
#14
killes --
OK, here's a patch that:
1) includes db_set_active around all the places it used to be, and has db_set_active bracketing any new CRM calls I've introduced.
2) It resolves http://drupal.org/node/51833 , the crm_contact_search issue that Robin found (#51883).
This patch is against Drupal CVS HEAD (1.53 being the previous revision).
#15
applied
#16
Cool. Bravo Robin.
Looks like we're live on RC6. K'einaharah. (i.e., no hubris just yet).
#17