Skip to content

MM-189: Expose membership fee token for webform calculator formula field #78

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: 7.x-5.8-patches
Choose a base branch
from

Conversation

viraj-compuco
Copy link

@viraj-compuco viraj-compuco commented Apr 8, 2025

Overview

This PR changes allow the membership fee field available as token to further used in the webform calculator formula field as token.

Detailed Specs: https://compucorp.atlassian.net/wiki/spaces/DruStandard/pages/5111676967/Membership+Tokens

D7 or D8?

D7

Before

  • When adding a membership to a membership purchase webform, it’s not necessary to expose the membership fee value.
  • When the fee is not exposed , the fee amount for the membership type is automatically pulled through the contribution page.
  • If the the membership fee is exposed, then the value no longer populates based on the membership type selected.

image-20250129-150329

How It Currently Works

  • The Membership Fee field is optional in CiviCRM webforms.
  • Webform calculator modules cannot access the Membership Fee value unless explicitly enabled.
  • There is no default way to expose the membership fee in a webform for calculations without explicitly including the Membership Fee field.

After

How It is working now

  • A new field called "Membership Fee (from Membership Type)" is created.
  • This field automatically pull the latest membership fee from the selected membership type when a form is instantiated.
  • Function similarly to the existing "Membership Fee" field, ensuring that membership line items reflect the correct amount.
  • It is shown like a normal field.
  • It is accessible for use in webform calculator module calculations (e.g., for applying discounts).
  • Allow users to set the field to private/hide from webform while still loading the value.

Screenshot 2025-04-09 at 11 30 36 AM

Test.Membership.Discount._.Site-Install.mp4

Technical Details

  • Create new field membership_fee_amount_from_membership under utils.inc.
  • Autofill the new field with current membership data in findMemberships method
    $membership['fee_amount_from_membership'] = number_format($this->getMembershipTypeField($membership['membership_type_id'], 'minimum_fee'), 2);
  • Added new Drupal behaviour membershipTypeFeesUpdate to handle the ajax request for autofilling the membership fee field when changed the membership type field.
  • This JS handles the on change part for multiple membership type fields on same form.
  • Implemented new method getMembershipFees under includes/wf_crm_webform_ajax.inc file.

@viraj-compuco viraj-compuco force-pushed the MM-189-membership-fees branch 3 times, most recently from 41f1c4b to b9f3ccc Compare April 9, 2025 05:42
@viraj-compuco viraj-compuco force-pushed the MM-189-membership-fees branch from b9f3ccc to 475fb50 Compare April 9, 2025 06:12
@viraj-compuco viraj-compuco requested review from hitesh-jain and erawat and removed request for hitesh-jain April 9, 2025 06:26
Copy link
Member

@erawat erawat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@viraj-compuco I am not sure what has been discussed, are we considering patching this to the webform core?

@viraj-compuco
Copy link
Author

Hey @erawat,
This can be good idea but we have specific use case for MM that can be used by other clients too, hence for now we are considering this patching upto our internal repo of webform_civicrm.
I don't know how much this patching helps in the core webform_civicrm.
@jamienovick What you suggest?

@jamienovick
Copy link

@viraj-compuco
Whilst normally I would say that we should always try and get our patches committed, my understanding is that in the case of webform_civicrm, getting the patches merged is very difficult as they have a D8+ version and a D7 version so I'm ok with carrying our own patches for this module only for the time being. There will come a time where we might want to change this approach however.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants