Gift Memberships - update?

[KarinG]

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

[Donald Lobo]

2 will be part of 3.4.8 and later. Its a fairly easy patch if u'd like to backport it to 3.4.7

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

lobo

[KarinG]

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

[petednz]

Hi Karin - care to update this ticket and/or point me to other more recent discussions with potential 'gift membership' solutions?

[KarinG]

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

[petednz]

Thanks for the quick update - dare say we will be in touch then to see how we can get this firing for 4.1

Can you provide patches for a 3.3.6 config and we will take a look?

Also you or anyone else know who did the Gift Membership process for the UN Women US site https://www.unwomen-usnc.org/civicrm/contribute/transact&reset=1&id=4

Is that just a usage of honoree - and if so, does it actually assign the Membership to the person it is being gifted to?

[KarinG]

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.

[KarinG]

Hi Pete,

I Emailed you the diff between a default 3.3.6 and my civicrm_local. If you have any questions please let me know.

-- Karin

[Eileen]

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'

[Eileen]

OK, so another option might be that we add another variable to honour_type option group - if they select 'Gift Membership' then the processing is 'like normal' - except that the contact_id is swapped out when saving the membership.

This might be possible via a hook but it could get caught up in that the point you want to swap out the contact _id is half way through the processing of the membership.

For me it also raises questions as to where on-behalf-of & honor could be consolidated into one thing with options (since both really want to be able to have the choice of what profiles to use, who to notify) .

[Eileen]

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

Code: [Select]

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,

[Eileen]

OK - I got some feedback from our customer about this which seemed like quite a useful requirement list for gift subscriptions so I thought I'd add it here. Note that I have implemented the code above to demonstrate how a hack/hook on the honor_id would look so that's what he is responding to.

It looks like it would be fine to collect the order but is it enough for us to manage in the back end?

Below is a list of criteria that I am using to compare HONOUREE vs ON BEHALF methods. Both fall down in the back end from what I can see.

Front End:
- Simple for the subscriber: HONOUREE (Yes) / ON BEHALF (Yes)

Back end:
- Gift subscription can be entered from the back end: HONOUREE (Can't tell?) / ON BEHALF (Don't think so)
- Gift subscription can be traced from giver and receiver's contact: HONOUREE (No) / ON BEHALF (No)
- Contribution can be traced from both giver and receiver's contact HONOUREE (No) / ON BEHALF (No)***honoree does soft credits so might be possible***
- If a giver gives multiple gift subscriptions, each recipient's status is visible in the back end: HONOUREE (No) / ON BEHALF (No)

Mail Dispatch to Address:
- The recipient's address can be separated from the giver in mailings, searches and reports : HONOUREE (Can't tell?) / ON BEHALF (Yes)

Renewal emails:
- First renewal email can be automatically sent to the gift giver: HONOUREE (Yes) / ON BEHALF (Yes?)
- Further renewal emails can be sent to the recipient: HONOUREE (Can't tell?) / ON BEHALF (Yes)

[johnd]

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.

[Eileen]

 

[sjthespian]

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.