Recently I was asked to compile a list of all CiviCRM releases since 3.1.0, identifying which were security releases so that we could make sure clients' sites were secure. The organization I work for (Freeform Solutions) is focused on doing sites for other non-profit organizations, many of whom are still running older versions of CiviCRM due to budgetary or other constraints, so we wanted to be sure that no one was running a version known to contain security vulnerabilities.
v3.4 and v4.0
IMPORTANT: You do NOT need to upgrade CiviCRM to remove this vulnerability. See "Prevent Attacks: Delete the Vulnerable File" below.
Vanco Payment processor
BackOffice Thinking is pleased to release the Vanco payment processor to the CiviCRM community. Today we are releasing versions for 3.4x and 4.1x and hope to have a 4.2x version shortly.
This processor allows single payment and recurring for credit cards and ACH (electronic check)
The Vanco payment processor is quite popular among religious organizations and we have been utilizing this processor for past 2 years with many of our clients. Thanks for all the support from the Vanco team along way.
The Progressive Technology Project has compiled a list of scenarios related to doing searches from our groups’ support requests. We would like to put these forward as suggestions/modifications for Advanced Search or custom searches. Perhaps some have already been solved and are lurking quietly as custom searches that we just don’t have on our radar yet. Please share comments and reactions to these - have any of your clients needed something similar?
There have been several hook() or Drupal module based solutions for "members only" pricing for events or for other 'discounts' related to memberships.
Okay, I'm double-posting today in case you don't find this buried in the forum. My forum posting contains all of the details regarding a custom hack written for a client to automate 7 renewal email reminders based on expire date.
I do hope you find this useful. http://forum.civicrm.org/index.php/topic,6176.msg98034.html#msg98034
Tales from a Blackbaud Kintera Conversion to a Drupal CiviCRM Solution - Part 2 - Converting Transactions
Hey gang sorry it's taken me so long to get back to you but we've been busy slogging through a few outstanding issues. For those of you who are currently in the throes of your data conversion here are a few quick words of advice.
1. Set up a local site for your data conversion so you don't run into any restrictions on how many records you can import at one time on your server, otherwise, you will spend a lot of time creating many, many small text files.
Notice to non-developers: This post is about how some functionality in 4.2 will be implemented in code and in the database, with very minor changes to anything visible through a browser. If you're not a developer, it probably won't interest you.
Having just had to import data that included a membership number for a client, rather than make a new field for the number it made sense to use the Contact ID, given that this is already a consecutive number and unique to each contact. The problem was that over the years there were big gaps in the consecutive numbers.
While the following is pretty straightforward, I've seen this issue brought up a number of times on the forum so I've written up what we did so that others may find their solution here! I hope its useful: