Membership profile field data not showing up during membership renewal

[nant]

Was able to reproduce on the joomla demo site.

Steps to reproduce:

1. I created a new Membership ID field for a new Membership Profile and I added the profile to the existing Member Signup and Renewal contribution page

2. I assigned the demo user from backend to the General membership and I populated the Membership ID field with 123.

Login to demo site as demo user.
visit the Membership page here:
http://joomla.demo.civicrm.org/index.php/component/civicrm/?task=civicrm/contribute/transact&reset=1&id=2

As you can see the Membership ID field is empty.

[petednz]

Nick - don't get this.

I changed it to english - confirmed this was a read only

Went through and added another 'read only' and an 'editable' field to the same Field Group - entered some data for both fields for 'demo'
http://joomla.demo.civicrm.org/administrator/?option=com_civicrm&task=civicrm/contact/view/membership&action=view&reset=1&cid=202&id=32&context=membership&selectedChild=member
added both to Profile
and neither is prefilling with data as i expect it would.

Didn't also test on the Drupal Demo

I added Name and Address profile to same form and yes that prefills.

I repeated on drupal (see links below) - also not prefilling

Core team - is this a bug - or after 7 years of civi I am still learning new things about Profiles?

Field http://drupal.demo.civicrm.org/civicrm/admin/custom/group/field?reset=1&action=browse&gid=6
Profile http://drupal.demo.civicrm.org/civicrm/admin/uf/group/field?reset=1&action=browse&gid=14
Contact with data http://drupal.demo.civicrm.org/civicrm/contact/view/membership?action=update&reset=1&cid=203&id=33&context=membership&selectedChild=member
Member sign up page http://drupal.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=2

[nant]

I see no way that is anything but a bug ...

[pratik.joshi]

There is intensional code with logic defining "not to show default value for membership fields", this can be seen in CRM/Contribute/Form/Contribution/Main.php in function 'setDefaultValues()' which is responsible for prefilling profile field values .

Code: [Select]

$removeCustomFieldTypes = array('Contribution', 'Membership');
      $contribFields = CRM_Contribute_BAO_Contribution::getContributionFields();

      // remove component related fields
      foreach ($this->_fields as $name => $dontCare) {
        //don't set custom data Used for Contribution (CRM-1344)
        if (substr($name, 0, 7) == 'custom_') {
          $id = substr($name, 7);
          if (!CRM_Core_BAO_CustomGroup::checkCustomField($id, $removeCustomFieldTypes)) {
            continue;
          }
          // ignore component fields/
        }
        elseif (array_key_exists($name, $contribFields) || (substr($name, 0, 11) == 'membership_') || (substr($name, 0, 13) == 'contribution_')) {
          continue;
        }
        $fields[$name] = 1;
      }

      if (!empty($fields)) {
        CRM_Core_BAO_UFGroup::setProfileDefaults($contactID, $fields, $this->_defaults);
      }
So, after looking into it, i would say its not a bug.

[nant]

Please read my initial post - this is not a default value - it is a value that is populated for a specific user.

[Donald Lobo]

pratik did mean the values populated for a specific user previously.

Am not sure of the exact reasoning behind this but the issue it references is here:

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

if i had to guess, its primarily because we think the user might want to enter new values for membership data etc

lobo

[nant]

pratik did mean the values populated for a specific user previously.

Am not sure of the exact reasoning behind this but the issue it references is here:

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

if i had to guess, its primarily because we think the user might want to enter new values for membership data etc

lobo

So there is no way to show a fields existing value in the form?

Sorry, this is not consistent with how other profiles work with individual custom fields.

[Donald Lobo]

Currently no

I think for contributions it makes sense, since they are always separate for every transaction

for membership renewal it does not make as much sense, since there is only one membership record. For multiple memberships, you dont want to populate it anyway

I suspect dave will chime in with his thoughts next week

lobo

[Dave Greenberg]

I'm not sure why Membership related custom fields were originally excluded from being loaded into profile fields - since the original issue specifically focused on Contribution custom fields.

I did a quick experiment removing 'Membership' from the $removeCustomFieldTypes array - and indeed that does allow for the behavior you're looking for (a membership custom field value in an included profile gets populated for a logged in user in the 'renewal' flow (i.e. they have an existing membership).

However there are a few complications to work out to come up with a valid solution that would result in an acceptable patch for 4.5:

1. The existing code is loading a default from an existing membership regardless of whether THAT membership is actually even offered on THAT membership signup page. Since not all membership types are necessarily exposed on a given signup form - this can result in the existing custom field value being 'assigned' to a new membership unintentionally. The "fix" for this would involve dynamically populating (or updating) the custom field (existing) values based on the selected membership type.

2. The code which handles formatting for different field types when existing values are injected in the profile form is currently only handling contact-related fields. The immediate result is that you get a notice when a membership custom field is included in the profile form. The code would need to be amended to handle membership custom field format requirements.

The switch statement on line 2266 throws this notice (if you hack Main.php to allow membership custom fields):

Notice: Undefined index: 11 in CRM_Core_BAO_UFGroup::setProfileDefaults() (line 2266 of /Users/dgg/git/crm_v4.4/CRM/Core/BAO/UFGroup.php).

If you're up for working on a patch for 4.5, jump on IRC and we can help.