Webform CiviCRM: create relationship does not create related memberships

[davej]

Hi,

We have a membership type which specifies a Relationship Type; max_related is blank.

When adding a relationship of the relevant type, to contact B which has a membership of the relevant type, via contact A's relationships tab, contact A then gets the inherited relationship.

However adding a relationship of the same type to contact B via webform_civicrm does not result in contact A getting the inherited relationship. The relationship is created just the same. Going to contact B's membership tab and viewing the primary membership, under Related Contacts/Memberships we see contact A listed with a Create link, with title text "Create Related Membership".

Tested with webform 7.x-4.0-beta3, webform_civicrm 7.x-4.5+9-dev, civicrm 4.4.5 .

Cheers,

Dave

[Coleman Watts]

I think that bug should have been fixed by https://drupal.org/node/2140547

[davej]

Hi Coleman,

I was testing as I said with webform_civicrm 7.x-4.5+9-dev, which is dated 2014-04-18. That patch was committed November 21, 2013 so would be in this version? Here's the end of function preSave() in this version:

Code: [Select]

      // Process relationships
      foreach (wf_crm_aval($contact, 'relationship', array()) as $n => $params) {
        $relationship_type_id = wf_crm_aval($params, 'relationship_type_id');
        if ($relationship_type_id) {
          foreach ((array) $relationship_type_id as $params['relationship_type_id']) {
            $this->processRelationship($params, $cid, $this->id['cid'][$n]);
          }
        }
      }
      // Process event participation
      if (isset($this->all_sets['participant']) && !empty($this->data['participant_reg_type'])) {
        $this->processParticipants($c, $cid);
      }
    }
    // We do this after all contacts and addresses exist
    $this->processSharedAddresses();

    // Process memberships after relationships have been created
    foreach ($this->id['cid'] as $c => $cid) {
      if ($cid && isset($this->all_sets['membership']) && !empty($this->data['membership'][$c]['number_of_membership'])) {
        $this->processMemberships($c, $cid);
      }
    }
  }

This is different from both the "before" and "after" versions shown in the patch for https://drupal.org/node/2140547 , so it looks like there have been further changes to that code since.

I think the problem is to do with the processing that is (or isn't) done when a relationship is created, rather than when a membership is created.

Consider the case where a webform does not do anything with memberships, it just creates a contact A with a relationship to an existing contact B that has an existing inheritable membership. When this is done through the Civi UI, contact A automatically receives any relevant inherited memberships. When it is done through webform_civicrm, that does not happen.

Via Civi UI, this code is run in CRM_Contact_Form_Relationship::postProcess() after calling CRM_Contact_BAO_Relationship::create():

Code: [Select]

    // Membership for related contacts CRM-1657
    if (CRM_Core_Permission::access('CiviMember') && (!$duplicate)) {
      if ($this->_action & CRM_Core_Action::ADD) {
        CRM_Contact_BAO_Relationship::relatedMemberships($this->_contactId,
          $params, $ids,
          $this->_action
        );
      }
      ...

Whereas via webform_civicrm, processRelationship() in wf_crm_webform_postprocess.inc leaves all the processing to:

Code: [Select]

      wf_civicrm_api('relationship', 'create', $params);

civicrm_api3_relationship_create() calls CRM_Contact_BAO_Relationship::create() but does not do any additional processing for memberships for related contacts.

Sounds like the scene is set for a demarcation dispute about whether it should be the job of civicrm_api3_relationship_create() or of the code calling civicrm_api3_relationship_create(), to do the processing for memberships for related contacts.

Cheers,

Dave J

[Coleman Watts]

I think certainly yes an a relationship created via api ought to handle any additional processing needed, including related memberships. I'm surprised this isn't happening already and wonder if it is a regression.

[davej]

Hi Coleman,

Thanks for the quick response. Looks like it is a regression: see https://issues.civicrm.org/jira/browse/CRM-9386 , https://issues.civicrm.org/jira/browse/CRM-13652 .

Related issue & post: https://issues.civicrm.org/jira/browse/CRM-13306 , http://forum.civicrm.org/index.php/topic,29822.new.html

Cheers,

Dave

[rfenwick]

Our charity is affected by this bug and may be able to make a financial contribution to fixing it if that helps to move things along 

[Coleman Watts]

Yes, and this would be a good time to do it because we could get the fix into 4.5 while it's still in beta.
Please contact me and we can discuss your contribution.

[Dave Greenberg]

Thanks to sponsorship from The Association for Cultural Enterprises (acenterprises.org.uk) - a fix for this has been completed and will be included in 4.4.7.

https://issues.civicrm.org/jira/browse/CRM-13652

You can patch existing 4.4 sites from here:
https://github.com/civicrm/civicrm-core/pull/3745