Duplicate contacts in your CRM are a source of trouble.
Blog posts by AllenShaw
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.
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.