Several of Joinery's clients recently started seeing a dramatic increase in fraudulent card-testing behavior on CiviCRM sites using the Stripe payment processor. We've resolved this problem for them with some great new features in the CiviCRM extension ecosystem, thanks to the contributions from open-source developers and CiviCRM partners.
Blog posts by AllenShaw
Three new extensions were approved this week for in-app installation, thanks to the generosity of extension developers and the hard work of volunteer reviewers.
The CiviCRM Extensions Directory is already filled with over 300 available extensions, many of which have passed the community review process and are thus available for in-app installation.
Take a look at the goodies that await you:
Over at the Extensions Working Group, we’re making careful progress toward improvements to the extension ecosystem, aiming to make it easier for all of us to do what we want with extensions: End users and site admins: easier to find, select, and install the right extension; Extension developers: easier to publish extensions and set clearer expectations for support and maintenance, and easier to avoid duplicating existing extensions; Community volunteers: easier to conduct extension reviews and help them get qualified for automated distribution.As an early step in those improvements, I’d like to point you to the relatively new Extensions Lifecycle documentation, which describes the process of publishing extensions through the CiviCRM ecosystem, along with clear definitions of concepts like stewardship (who’s managing this extension?), project maturity (exactly what is meant by saying an extension is “experimental” or “stable”?), and more.
CiviCRM provides a "current employer" field for all individual contacts, and that field does some cool stuff. Problem is, when this field isn't an autocomplete (as in public-facing profiles), you're leaving the door open for typos and abbreviations, which will lead to duplicate records being created for an employer. Wouldn't it be cool to prevent that? Here's an extension that does that and more.
A member sends several separate payments to cover outstanding dues on a single purchase, like an expensive membership or a table at an event. How are you going to record this?
A conference participant selects “Pay Later” on several different event registrations, and later wants to pay them all in a single credit card transaction. How are you going to support this?
A couple of weeks back I wrote here some thoughts about letting users manage and modify their own private collection of reports without actually having site-wide "administer reports" privileges. I've since gone ahead and written up the code to make this happen, and I would love to get feedback from the community on its usefulness and ways to improve it.
Note: You can see videos of these features in action on NS Web Solutions' case study page for this project.
Update: Some of the code for these features is available on GitHub. See my comment below.
CiviCRM offers an incredible set of features straight out of the box. At NS Web Solutions we're sometimes asked to provide a CRM system with some pretty unique features, and we've found that by relying on CiviCRM's wide array of hooks and customization features, there's a lot that can be done.We recently completed a project for a client that conducts many events per year in which all participants are fully sponsored to attend, including airfare, airport pickup, hotel accommodations, and meals. To complicate the equation, not all participants are given the same package; variations include hotel room type, in-room amenities, class of travel, length of stay, type of airport pickup, and more. Seemlessly integrating all this data into CiviCRM was critical. We built a custom Drupal module implementing CiviCRM's wide array of hooks, in addition to a number of custom data fields, to achieve this.