CiviCRM Community Forums (archive)

CiviContribute allows one contribution page for each program, campaign, etc.  We are attempting to do something slightly different -- we need a user to be able to make multiple contributions on one contribution page.

We have successfully modified the Main, Confirm and ThankYou templates to show multiple items on a single page.  However we now need to handle the DB insert. 

CiviCRM takes the total of the line-item contributions and places it in the civicrm_contributions table.  We need to insert the line-item contributions into the table, not the total.  Any suggestions on the best way to do this without completely hacking the code? 

Hey Lobo, thanks for the reply.  Sorry about not placing the question in the right area.  Let me offer more explanation to see if there is a way to handle this with minimal hacking. 

Based on our modifications, here is how the code currently works:

• 1) User enters billing information and multiple amounts for donation.  Values stored in session.  (Main.tpl/Main.php)
• 2) User confirms billing information and contribution amounts.  (Confirm.tpl/Confirm.php)
• 3) Total amount stored in civicrm_contribution table, and detail line-item amounts stored in a Drupal table called donations.  We place the same invoice_id and trxn_id in Drupal as cross-reference.  Thank You page presented to the user.  (ThankYou.tpl/ThankYou.php)

All of the above works fine.  The issue we have is with administration.  When an admin visits CiviContribute, we would like him/her to be able to (a) see detailed-line item donations in the Recent Contributions list and (b) download them using the Find Contributions functionality. 

Admins can deliver line-item amounts to the right groups only if they have a way to see them.  Of course we could have created a separate donation page for each group, but the current site bundles together multiple donation opportunities on one page.  (Note: when we first started working on this, we considered creating separate contribution pages in CiviContribute and then finding a way to merge them on the front-end.  However we ran into similar problems with the donation process rather than the admin process.)

Within CiviContribute code we can write queries to get the detailed line-items from Drupal:
SELECT * FROM drupal.donations
LEFT OUTER JOIN civicrm.civicrm_contribution ON (donations.tid = civicrm_contribution.invoice_id)
WHERE donations.status = '1'
However not entirely sure how this would integrate with the Recent Contributions and Find Contributions lists, or if there is an easy way to do so.  That's why we were wondering if the better approach was to just insert contribution records at the time of donation.

Hmmm ... I've been looking at the code more closely, and I'm wondering if there might be a way to accomplish this without too much hacking.  Let me explain my proposed solution and tell me if there are any risks I should consider.

To clarify, I'm not interested in creating unique invoice_id's and trxn_id's for each line-item of the transaction.  In fact, I want each line to have the same IDs so we can see they are part of the same contribution.

What I'm thinking is a for loop around the entire code in processContribution.  To ensure we can use processContribution for other contribution types, we will pass a session variable identifying if a transaction has multiple line-items.  If multiple records, all the $params['amount'] values will be set to the line-item amount, and $params['source'] will be set to the unique information that identifies the line-item record.  Otherwise, process as normal.

I would think this approach would make all the line-items show up as individual records in Recent/Find Contributions.  Am I correct to assume this?  As for building a custom search, probably the easier approach is to have "donations" be a content type in Drupal, so each contribution is a new node.  Using the Views module would allow for an easy way to build a powerful search tool.  However, I'd rather avoid hijacking content nodes for the purpose of donations.  There's really no need to do so.

Ahhh there always has to be a wrench to mess things up.   

I'll take a look at the custom search and compare to the tweaks necessary for the proposed solution.  When you say contribution id for the mail, is it the function needs a specific id to send the mail?  Or are you just referring to what information is displayed on the message?

So I'm curious to know, any chance CiviCRM will in the future move to a more traditional/flexible data schema of a contribution_header table with line-items stored in a contribution_detail table?   

After reviewing the wiki, am I correct to assume the custom search capability is part of 2.x and not in 1.9?    Guessing in 1.9 I would need to edit/hack the files you mentioned in CRM/Contribute/BAO and CRM/Contribute/Form/Search.

I've avoided upgrading to 2.x because of concerns about compatibility.  I decided to give it a try this evening, and sure enough, my concerns have been confirmed.  When I attempt to run the upgrade, I receive the following error:

Fatal error: Call to undefined function crm_uf_get_match_id()
in /htdocs/sites/all/modules/civinode/civinode_utils.inc on line 593
If I remove the CiviNode module from Drupal, of course it makes it through the rest of the upgrade successfully.  We're using CiviNode 5.x-1.2 (http://drupal.org/project/civinode) to expose contact records to the user so they can update personal information from their user profile.

Unless there is some other way to allow this to happen in Drupal with CiviCRM 2.x, I just don't see how we can upgrade at this point.  Also here is an on-going thread discussing some of the issues:  http://drupal.org/node/230103  Any thoughts?

Ah you know what?  You are absolutely right.  I'm not sure why I was thinking that our exposing of contact records is being done via CiviNode.  In fact we are using CiviCRM profiles.  It is still a bit of an issue, since we are exposing CiviCRM fields through CCK in a couple of places.  In the interim we may be able to work around this by just putting the data in Drupal, then eventually migrating it back to CiviCRM.

I did work for a bit on attempting to create a custom search per the wiki.  Very slick and this does seem like it could solve our issues.  I was able to merge together CiviCRM and Drupal data into a single result set, and export the data.  The functions to select data columns for export doesn't seem to work, but I'm ok with just dumping all the data to the screen and doing one large export of all columns for now.

I'm not sure what the long-term plans are for the custom search capabilities, but if it was eventually integrated into a query-building front-end (a la Drupal Views), it could be a very powerful data mining solution.