Dispatch from the sprint

I'm writing from the third day of the post-CiviCon code sprint in Truckee, California.  With 36 participants, we've divided into several groups focused upon making the upcoming CiviCRM 4.5 release as stable and useful as possible.

Led by Dave Greenberg and Yashodha Chaku, our group has tackled several bugs and limitations, yielding a number of improvements in just a couple of days.

Tobias Lounsbury has focused on an issue where reserved profiles, which are required by CiviCRM, had been required to be enabled as standalone forms.  It may seem innocuous, but depending upon your permissions for anonymous users to access profiles, it can make contact listings and/or creation forms accessible by anonymous users.

Bots can fill forms or scrape information, but you may need to have the permissions set that way for allowing other profiles to work.  Toby's solution will allow you to disable that requirement for the reserved profiles, letting them be enabled only for the internal features they're necessary for.

Dave helped a new community member get their new feature pushed into core: allowing admin-only price fields be visible for administrators using an event registration form.  He has also supported and reviewed many folks' work and closed over 10 issues.

Karin Gerritsen tackled the issue of recipients of forwarded bulk emails clicking the opt-out link and opting the original recipient out of receiving messages through CiviMail.  To avoid this mix-up and ensure the recipient's privacy, the opt-out form now displays a masked version of the original recipient's email address and requires the full address to be entered by the user.

Yashodha has been working on issues with scheduled reminders.  In addition to user interface improvements, she fixed an issue where the contact reference for scheduled reminders wouldn't carry over properly if the contact gets merged.

Finally, I've been working on duplicate matching for event registrations.  Through 4.4, event registration forms default to matching on email alone, regardless of what the Unsupervised duplicate matching rule says.  For events that don't collect email address, that means every single participant is a new contact.  Ironically, clicking "allow multiple registrations from the same email address" causes the primary participant to be matched by the Unsupervised rule, but it matches additional participants by the Supervised rule, which is counterintuitive and may be inappropriate.  

I'll blog separately about all the changes in duplicate matching for events because there are a range of situations affected, but the result should be clearer and more flexible for everyone.

Think this sounds interesting?  Join us at the next code and documentation sprint!  It's a great way to learn a lot, contribute to the project, and have fun.