GitLab

At the moment I'm looking at the civimember backoffice code and there is a lot of mess around the tokens in the receipts - it's hard to fix it up without knowing where we are going. The receipt template is shared between 3 forms Back office membership, Back office membership renewal, back office batch entry.

Broadly speaking there are 5 types of tokens in the receipt

1. form specific - this is text entered on the form that is not stored in the db. I think there might be one other submission dependent variable
2. membership specific - this are various values relating to the membership or memberships in the form
3. contribution specific - only one contribution would ever be relevant to the given form
4. contact specific
5. weird invoicing format

token	notes
{contact.email_greeting}	loaded from token system
{$customValues}	Name=>value array of fields that were present on the form - not batch
{$formValues.total_amount}	contribution.total_amount
{$formValues.contributionType_name}	contribution.financial_type
{$totalTaxAmount}	contribution.tax_amount
{$formValues.total_amount}	contribution.total_amount
{$receive_date}	contribution.receive_date
{$currency}	contribution.currency
{$formValues.paidBy}	contribution.payment_instrument
{$formValues.check_number}	contribution.check_number
{$membership_name}	used for single quick-config membership
{$membership_start_date}	used for single quick-config membership
{$membership_end_date}	used for single quick-config membership
{$lineItem}	When quick config is not in use this is iterated to present line item details, could be loaded from contribution
{$dataArray}	Augments lineItem with tax details when invoicing is enabled
{$cancelled}	I think this is never assigned
{$isPrimary}	Appears to be unnecessary as inner ifs achieve the same
{$billingName}	submission specific from payment form
{$address}	submission specific from payment form
{$credit_card_type}	submission specific from payment form
{$credit_card_number}	submission specific from payment form - field is just the last 4 digits
{$credit_card_exp_date	submission specific from payment form
{$formValues.receipt_text_signup}	submission-specific, no reason not to just use {$formValues.receipt_text} for both
{$formValues.receipt_text_renewal}	submission-specific, no reason not to just use {$formValues.receipt_text} for both
{$headerStyle}	assigned within the template, if we ever moved logo to db would look at moving to a db-stored message header or field
{$labelStyle}	as above
{$valueStyle}	as above
{$logo}	Not available but we really should offer this as a token
{$messageHeader}	Not available but we really should offer this as a token