UK Code sprint august 2011

[Eileen]

I have quite a few items on customer's wishlists which I'll post here in case anyone else on the sprint has a shared interest in any of them

1) Groups - there are performance issues around hierarchical groups & smart groups & ACLS. The particular aspect we are seeing are in multisite implementations where the parent group is used to restrict which contacts can be seen. So, the civicrm_group_contact_cache is filled up with every possible contact in the group (for each level in the hierarchy) & then it is restricted on the way out. It seems to me that the concept of a smart group that searches within the parent group rather than extends the parent group would be useful.

There has been previous discussion / interest in improving smart groups so they can go on contact tabs.

2) pledges - we find that our customers that use pledges want ALL contributions to be pledges with a requirement that recurring contributions are transformed into pledges. The would be somewhat similar to what was done for memberships.

Tangental to this would be a contribution report that includes pledge fields (ie. civicrm_contribution LEFT JOIN civicrm_pledge).

3) Events & Price-sets - I have been given a  list of ways in which price set usage for events could be improved
1.   As posted here http://forum.civicrm.org/index.php/topic,20496.msg86002.html#msg86002  if you are using the ability to set a maximum number of participants for each price field option, I think civicrm checks if an option has reached its limit when the event registration screen is opened but doesn’t re-check when a registration is actually submitted.  I could be wrong as I haven’t looked at the code (and I don’t know that I would understand it just yet!), but Lobo seems to think that could be the case and thinks that would be a good improvement for CiviEvents.

2.   An easy way to find out the current total for any price option or price field.  At the moment I think the only way to do it is to export the results  for the “Price set details for event participants” custom search and use a spreadsheet to find the totals.  This is rather cumbersome especially if you have several hundred people attending the event because searches and exports take time.  Perhaps I am wrong and there is already an easy way to find these totals – if so, please let me know because I need it for this conference!

3.    Fixing the problem with the “total participants” that we discussed yesterday and which I first mentioned in the post http://forum.civicrm.org/index.php/topic,20494.msg85675.html#msg85675  .  I have thought about this a lot and I think the best approach would be to add a(nother) tick box to the price field set up page (attached).  The tick box would be labelled, say,   “Include this price field in total participants count for the event?” and the formula for the total participant count for the event would need to be changed to only include those fields with a tick in the box.

I think it needs to be an opt-in tick box because different events will have different requirements.  There is no way to have a blanket rule that links inclusion in the total participant count for an event to price fields where there are non-$0 options, or to price fields where the options have a value entered into the “participants count” field as our conference shows 

For our conference  we have:

•   Price fields with non-$0 options that we want included in the total participants count.  These are the first two fields ( ‘Standard fee’ and ‘discount fee…’)  where non-$0  options have participants count = 1 and the $0 options have participant count = 0. So adding the participant counts for those two price fields will give us the number we want for “total participants”.
•   Price fields with non-$0 options that we do not want included in the total participants count.   These are the ‘conference dinner’ and ‘transport for dinner’ fields.  People are allowed to buy up to 2 tickets for the dinner and transport and we need to know how many are coming, so we have a ‘participants count’ = 0, 1 or 2  as appropriate.
•   A price field with non-$0 options that we do not want included in the total participants count and where we have not entered any value into the “participants count” field for each option (‘My role in the conference is’  - we are using that to give speakers etc. the discount they are entitled to) 
•   Price fields that have all $0 options that we do not want included in the total participants count.   (‘Thursday am sessions’ and 3 similar price fields that don’t show in the snippet) As each option has its own “Max Participants” value varying from 12 through to 150,  we have set  participants count =1 for all but the first option.

4.   Fixing the problem that exists with ordering of price sets as outlined in the post http://forum.civicrm.org/index.php/topic,20330.msg84961.html#msg84961 .  (I was sure I was adding to someone else’s original post on the topic, but now it is just standing by itself.) This is still a problem on the 3.4 demo site.  I have attached a screenshot of the price field I have just set up which shows the problem.  You can get around the problem by editing each price option and changing the number in the ‘order’ field, but trying to reorder using the arrows is quite a challenge.

[Eileen]

OK, I have another item - this is one I'd really like to get on the list - there is a problem with all off-site payment processors (from what I can see) in that the documentation for all the ones I have looked at (including paypal std) that they say you should POST to their site (ie. have a form that submits directly to their site). Despite the documentation all the ones currently implemented (incl Paypal Std, Elavon VM, Payflow Link) have actually accepted 'GET' requests.

I seem to have just hit one that won't & which needs the POST method & I suspect that existing ones may change / more may eventuate.

I'd like to look at adding another payment processor billling_type which would be POSTToExternal (we have 'form', 'notify' & 'button' far - not the most intuitive names).

This requires some re-factoring of the form - I would like to work with someone on this at CiviCON.