Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
C
Core
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 979
    • Issues 979
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • Core
  • Issues
  • #2303

Closed
Open
Opened Jan 17, 2021 by eileen@eileen🎱Owner

Token plan - what is it

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
Edited Jan 18, 2021 by eileen
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: dev/core#2303