CiviCRM Community Forums (archive)

We've been using CiviCRM for almost 2 years to sell tickets to theatre performances.  Right out of the gate, we sponsored participant counts for price sets (i.e. "table of 8" price sets, CRM-5724) and soon thereafter submitted a patch for admin-only price sets (CRM-5766).  We needed both of these in order to use civi at all, but even then there were a number of pain points I outlined in a rather long-winded rant (forum.civicrm.org/index.php/topic,13226). 

(Several of the issues identified have since been addressed by the core team - thanks again!)

It took longer than I hoped, but we are finally ready to sponsor a few more of our highest-priority items.  It is my sincere hope that other folks will find these helpful and they can be folded back into the core project.  So, submitted for your feedback, in roughly descending priority, a few things we'd really like to get done:





1. Handling live credit card transactions in the same backend form as cash/check transactions.

Basically, when entering a new participant or contribution, there should be a choice of either recording a (cash/check/etc) transaction or submitting a live CC transaction.  This should be true everywhere, notably:

- participant/add
- contact/view/participant?reset=1&action=add
- contribute/add
- contact/view/contribution?reset=1&action=add
- contact/view/participant?reset=1&action=update

(This last would allow CC payment on 'pay-later' registrations -- a major pain point now.)



2. Auto-loading of contact data into the credit card form.

This currently works if the transaction is initiated from the contact record, but it should be true everywhere.  Upon selecting a contact in participant/add or contribute/add the contact's name and billing address should be loaded into the CC form, saving much frustrating re-entry of data. 

(If no billing address data exists for the contact, the primary address should be loaded instead since they're the same 90% of the time.)

When the form is submitted, the name and address should be written to the contact's billing address exactly as it is now.



3. Allow transferring a registration to another event.

For those of us with many similar events (e.g. performances of the same production), ticket exchanges are a common need.  I have been doing this for the past year by directly manipulating the database (simply changing the event_id in the participant record is all that is needed), but a UI would be very helpful.  I imagine a link or button on the 'view participant' page that brings up a form where a new event can be selected.

The source field for the participant record should also be changed to something like "Registration transferred from {old_event} (by {user})".

Obviously, it is not always appropriate to transfer a registration to another event.  For this reason, the feature should be a) separately permissioned AND/OR b) globally enabled somewhere in admin/setting.



4. A custom report that combines individual and household contributions.

If The Smiths make a $100 donation, Jane Smith makes a (separate) $50 donation, and Joe Loner contributes $75, I need a report that produces The Smiths: $150; Joe Loner: $75.  The report should be based on the "Top Donors" report (i.e. descending aggregate).

<digression> As a side note, I think this is a big weakness of the civi data model.  Individuals 'without' a household are really just a household of 1.  I wish reports/searches/labels/etc all worked at either a 'household level' (i.e. grouped) or an 'individual level' (i.e. ungrouped). </digression>



5. Add the ability to update basic contact data in the middle of an event registration or contribution. 

Say you're registering an contact for an event and you learn that they've changed their email address or that you've misspelled their name.  It would be nice to make the correction without having to leave the form, search for the contact, make the change, and then start all over with the registration.  I'm not sure how this is best accomplished - maybe just opening the contact in a new window or a floating form.  Right now, there is not even a link to the contact.



6. Some small miscellaneous changes.

a) Make a link to event location map available as a smarty variable in confirmation emails (CRM-6589).

b) Display available participants when an event is selected on the backend registration form.  Currently a message is displayed if the maximum has been reached (or exceeded), but this doesn't help in the case of someone wanting to register 2 participants when only 1 slot is left.

c) Make the "paid via" field required (and perhaps defaulted).  This field is often left blank when entering data quickly which causes a hassle when (for instance) the cash drawer doesn't balance or the list of checks to deposit is incomplete.



7. More robust credit card swiper support.

USB swipers come in 2 types.  The basic (and cheaper ones) will read the CC number and insert it into a text field, which works fine with civi.  The other sort reads all the data on the magnetic stripe in its raw ascii form.  (see http://en.wikipedia.org/wiki/Magnetic_stripe_card#Financial_cards)

I imagine CC forms in civi including a "swipe now" button that brings up a floating form with a single text field.  Swiping a card would fill the text field with the raw data (allowing visual confirmation of successful swipe) and hitting enter would dismiss the form, parse the data, and populate the appropriate fields of the main CC form.

The feature should be globally enabled/disabled from the admin section.



I am really not interested in creating or maintaining a fork of civiCRM, so community feedback will meaningfully impact how or even if we get these done.  Any change that doesn't look promising in terms of eventually being incorporated into civi will likely be dropped.  So please weigh in!


Basically our plan is to just work down the list until we run out of budget.  Can't say how far that will get us, but if anyone has similar needs and would like to chip in, that would be awesome.

Regarding the address pre-filling issue. [...] The issue I was looking at was that at the moment it WILL pre-fill for back-office entry but using the location_type = 5 (Billing) rather than the is_billing flag.

This is my experience when beginning the registration/contribution process from a view contact page.  E.g: contact/view/participant?reset=1&action=add

The improvement I would like to see is:

1) loading name/address from participant/add and contribute/add once a contact is selected (first priority)
2) loading the primary address if the billing address is not available (second priority)

(We wound up just changing our address types to 5 rather than fixing)

I would be interested in hearing a little more about how you made this work.  In truth, we don't much need more than 1 address/contact.

Not sure if you planned to do the work yourself & contribute or sponsor the core team to but this item I would definitely recommend you sponsor core team to do.

Planning on hiring someone to to do the work.  Probably webaccess just because we have an existing relationship with them.

Ah.  So its a recurring-maintenance thing more than a set-and-forget thing.  Still helpful, though.  Thanks.

At the risk of hijacking my own thread, does is_billing actually do anything?

I'm not sure if it is a good sign or bad sign that s few have weighed in on these proposals.  Either no one has any objections, or else no has the same frustrations/priorities as we do. 

We are (finally) ready and willing to chip in and contribute to the project again as we did a couple years ago.  It would make a big difference going forward if we had some sense as to whether these things (especially items 1-3) might be folded back into core.

Would it be preferable to turn it into a MIH? (Probably removing items 4 and 6a so that it is more focussed on POS improvements.) 

Thanks lobo.  I will work on a more focused spec for a blog post.

Here's the thing, though:  Even if nobody else is interested enough to chip in to a MIH, we would still like to sponsor as much as we can afford.  In which case it would be nice to know what items might be eligible to be folded back into core before we throw our hard-earned money into something that quickly becomes obsolete. 

Thanks lobo.

I think it is obvious at this point that number 4 is different in kind and doesn't belong on this list.  6a is also a bit off the main topic.

I think the simplest way to handle 5 is to generate a link to the contact record (that opens in a new tab/window) once a contact is entered into the registration/contribution form.  Maybe there is a cooler/smoother solution possible, but this would meet the immediate need and seems very straightforward.  I don't understand the code well enough to know how/if data in the main form would need to be refreshed once the contact form was saved...

Items 2, 5, and 6b all amount to just loading more data into the form upon selection of a contact or event.  6b seems almost trivial given that civi already checks current- vs max-participants.  Outputting the difference instead of just a full/not message can't be a very big deal.  (I might attack this one myself). 

Kirk - These all seem like good additions and improvements (excluding item 4 for now which we've said would be best to discuss separately).

I think #1, #2 and the miscellaneous improvements (#6) could be grouped together as a single project - "Streamline back-office credit card transaction input". Ballpark estimate for this set would be ~40 hrs.

RE #3 - Sounds like you do NOT need to account for fee_level / fee_amount differences when you change events. Is this because all your events have the same fee structure? If we take the simplistic approach and just change the event_id w/o updating the $$-related fields (and w/o updating associated contribution record) - seems like things would be "out of balance". I guess we could allow this via UI and "warn" the user that the fee data would not be changed / would reflect the original event fee?? As Eileen noted, supporting adjustments to fees received should probably wait for CiviAccounts functionality.

RE #5 - Adding a link to open contact edit form in a new window is trivial BUT might not be the best approach. Opening a pop-up form based on a profile seems preferable - since you could control which fields to include and user could save the changes inline and get returned to the participant form. This feature could use the existing reserved "New Individual" profile. Alternatively, Adam Wight at Giant Rabbit just submitted a potential patch to set a "default event registration profile" - which could be used here. We can check w/ Kurund on a ballpark for this once we figure out an approach.

RE #7 - Don't know much about this, but I agree with Lobo that a Drupal module might be the way to go.

I'll ask Kurund for a ballpark on #5 using a profile.

RE: #3 - Limiting transfer of registration to events using the same price set seems like a good 1st step. That's probably a simple change and we could include that in the "Streamline ..." project

Would be good to get these in the 4.2 queue relatively soon. Keep us posted about funding availability.