CiviCRM Community Forums (archive)

Hi Eliet,

I just upgraded to 3.4.7 and I ran into several issues with the core onBehalf bits (which I need). For anyone else upgrading onBehalf contribution pages to 3.4.7:

1. you must select a Profile on the Title and Settings page - or your Contribution Page is broken right from the get go: See: http://forum.civicrm.org/index.php/topic,21760.msg91296.html#msg91296

2. If you select onBehalf as "required" (on the Title and Settings page) - onBehalf doesn't work (no onBehalf records are created; no Contribution is recorded for onBehalf but for payee instead, no Membership for onBehalf). See:
http://issues.civicrm.org/jira/browse/CRM-9067

So, that's where I'm at right now. 1. is an easy fix - 2. is a problem. But one that has already been addressed: it's working on civicrm demo now [I just finished testing onBehalf there], but that's not available 'in the sourceforge store' yet.

-- Karin

Ok, we pulled over the latest svn repository. And OnBehalf = required is now working as it should. Brilliant: thanks to all of you who are patching things so quickly. I will now work on getting the basic Gift Membership functionality I had in 3.3.6 working on this 3.4.7+ and will report back when I have something potentially useful for others.

-- Karin

Hi Pete,

Compared to 3.3.6 (where I had things basically working other than the front end configuration bit) there have been a fair number of changes to this subsection of CiviCRM in the 3.4.x - So, I really need to start back at square one, but - sorry to say - haven't been able to find time to do so. At times it feels like every non-profit in Canada wants a Drupal/CiviCRM site...

If you're keen on this though - and can help guide me - then I'll dig in and find time for this.

-- Karin

4.1 - cool. I'm in. I'll send you what I did for 3.3.6 tomorrow - it's almost lights out here.
I don't know who did the unwomen-unsc.org site.

I have been looking at this for a customer - this is how I see the spec would look

Contribution Page table / BAO / Form
1) change field civicrm_contribution_page.is_for_organization to is_for_contact_type - to hold contact and / or sub-contact type.

2) Add a field 'profile_id' - to specify the profile in use (otherwise we have to start getting into multiple default profiles) - limit by #1

3) Add a field 'relationship_type_id' - to specify the type of relationship to be created (currently an employer of relationship is always created). Would need to be restricted so that it joins Individual to the contact type specified in #1

4) the rules of inherited don't really apply to gift memberships -one person could give several gift memberships & doesn't become a member themself they are more like honorees. Potentially an 'onbehalfof_type' which could be 'inherited' or 'honoree'. If honoree we would try to use existing honoree code but create a membership for that person?

Mail templates
5)  Probably we would need an email template for the gift recipient so they receive a different message to the sender.

Code changes then required in Contribution/BAO Contribution/DAO Contribution/Form, UFGroup & UF Form to implement these options.


However, am just thinking through another option using 'honor_id'

OK - I tested the use of 'honor' for purchasing memberships & got it to create the membership for the second person rather than the first. Not sure if this convinces me to continue down this path or not. However - it seems to suggest that swapping the membership id at the line I've picked is the spot to do it - at least for online pages


Index: CRM/Contribute/Form/Contribution/Confirm.php
===================================================================
--- CRM/Contribute/Form/Contribution/Confirm.php (revision 37365)
+++ CRM/Contribute/Form/Contribution/Confirm.php (working copy)
@@ -770,6 +770,15 @@
                 $membershipParams['selectMembership'] = $membershipTypeIds;
                 $membershipParams['contribution_type_id'] = $contributionTypeID;
             }
+            $membershipContactId = $contactID;
+            require_once 'CRM/Core/OptionGroup.php';
+            // if honor type has the name 'membership' then the created membership will be agains the 'honored' person
+            $honortypes =       CRM_Core_OptionGroup::values( 'honor_type',false, false, false, null, 'name' );
+            if(CRM_Utils_Array::value('honor_type_id',$this->_params) && isset($honortypes[$this->_params['honor_type_id']])
+              && $honortypes[$this->_params['honor_type_id']] == 'Membership' ){
+            $membershipContactId  = $membershipParams['contact_id'] = $this->createHonorContact(  );
+            }
+
             require_once 'CRM/Member/BAO/Membership.php';
             CRM_Member_BAO_Membership::postProcessMembership( $membershipParams, $contactID,
                                                               $this, $premiumParams, $customFieldsFormatted,

Just outing myself as Eileen's client and still a newby to CiviCRM.

Reading this thread has been great. Whilst I'm not a coder, it is starting to make sense to me.

I've started a project wiki based on our requirements, "Making Gift Memberships a Standard Feature"

It should apply to most gift membership users.

Has anyone done any coding against this? I'm trying to track down one or more of our members to work on the project, but I don't want to duplicate anyone else's work if I can avoid it.