CRM-21321 - Membership fields not loading in 'On behalf of' profile

[yashodha]

Overview

Membership fields not loading in 'On behalf of' profile

Before

After

---

• CRM-21321: Membership fields not loading in 'On behalf of' profile

[yashodha]

@monishdeb can you please look at this? I think this is an oversight where you can't add the membership fields on contribution page when behalf profile is activated.

[jusfreeman]

@yashodha great addition - thanks for your work 👍

[monishdeb]

@yashodha @eileenmcnaughton there is a validation written about not to allow membership profile IF onbehalf profile is set, it rather suggests us to move the membership fields to onBehalfOf profile. I don't see what was the need for this as removing those two validations allows me to add membership profile and upon submission, it correctly records custom field data. So instead of amending support for Membership type fields here in buildComponentForm(...) can we remove those two validation rules? i.e. https://gist.github.com/monishdeb/02ce35549222b84c2e6b304362549b08

[eileenmcnaughton]

I assume the issue arises if fields get added to the profile that are about the membership itself - not just custom data fields?

[monishdeb]

yes, issue is membership fields w/o custom fields are not shown on onBehalf profile.

Actually due to the formrule in place, if the contribution page is already configured with onbehalf profile then you can not add membership Profile (including custom fields), it rather instruct you to add the membership fields (w/o custom field) in onbehalf profile. Which looks a bit odd to me. So I was suggesting why not remove the validation in first place.

[eileenmcnaughton]

So removing this doesn't allow 'membership_status_id' or anything functional to be added?

[monishdeb]

No it allows, see :

[eileenmcnaughton]

So I think that is why the block is there - it was considered too tricky to filter appropriate fields so it was just blocked

[monishdeb]

Yeah but then core doesn't respect this block, see #11151 where it doesn't allow membership fields to be added to onBehalf profile. Strange. So should I merge this PR then?

@eileenmcnaughton

[yashodha]

@monishdeb yes #11151 is a precursor to this. The underlying documentation also suggests that the exception be made while adding membership fields to an 'on behalf' profile but is not working cause the logic doesn't handle the conditions well.

[monishdeb]

Agree, tested the patch and works fine. Merging now.

[eileenmcnaughton]

So to clarify - is it now possible to add inappropriate fields (membership type/ membership status) to an on behalf profile and have them show up on a public page?

[monishdeb]

@eileenmcnaughton still no as you need to apply/merge #11151 first, which will allows you to add membership fields to on-behalf profile. This patch will then allows you to load n show membership fields on on-behalf profile and yes it will show the inappropriate fields on public page too based on what 'Visibility' chosen. Isn't this appropriate as per the formrule written?