One of the mini-projects that we worked on during our San Francisco meetup / code sprint was improving the way name and address data is handled during payment transactions (e.g. online contributions, membership signup and event registration). Our goals were:
Prevent name, email address and postal address information collected during a payment transaction from over-writing existing "non-billing-related" data.
Store the billing name and address info for EACH transaction - so that it can be retrieved for audit / reconciliation purposes.
Set a foundation for a more "shopping-cart" style interface where logged in users can select from a set of previously used billing locations.
Blogs
Keep up-to-date with blogs from the core team, working groups, developers, users and champions worldwide. Subscribe to our newsletter to receive regular updates by email. We also have an RSS feed.
November 9, 2008
By Andrew Clarke Filed under CiviCaseAs I've said elsewhere, it's been a real pleasure working closely with the CiviCRM team on the CiviCase project. The work we're doing is exciting, and has at least a hope of offering some efficiency to the large number of service providers whose work is organized into "cases", however that term is locally defined.
November 3, 2008
By Dave Greenberg Filed under CiviCase, CiviCRM
CiviCase is a new component for CiviCRM targeted at organizations who provide case management services. It is being developed In partnership with the Physician Health Program of British Columbia (PHP-BC). In addition to providing funding for this project, PHP-BC is providing invaluable domain expertise and the current plan is for their staff to start using CiviCase in January 2009. You can learn more about how this project got started and the project goals from these blog posts and the requirements overview.
CiviCase Phase 1 is a major part of the upcoming 2.2 release - and several members of the core team are gathered in San Francisco this month working on bringing it to life. Last week we had a two day "in-person" meetup with PHP-BC folks (Andrew Clarke, Claire Sauve, and Dave D) where we reviewed work in progress and got detailed feedback on the basic workflows and screens, as well as the data model and configurability of the component. That meeting resulted in some key refinements and additions to the phase 1 specification - and provided a good reality-check for the project!
November 3, 2008
By shot Filed under Drupal
The idea of creating a Drupal block containing a subscription form for a specific CiviMail mailing list (or for all of them) comes regularly on the forum, so I decided to try out how much work would it be to create one.
It turns out this task is fairly simple, if one knows the proper URLs for CiviMail subscription pages. The URLs are of the form …civicrm/mailing/subscribe?reset=1 (for all mailing lists) and …civicrm/mailing/subscribe?reset=1&gid=X (for a mailing list with group id of X). For example, these two URLs point to subscription pages on our Drupal demo installation: http://drupal.demo.civicrm.org/civicrm/mailing/subscribe?reset=1 (all mailing lists), http://drupal.demo.civicrm.org/civicrm/mailing/subscribe?reset=1&gid=2 (the Newsletter Subscribers list).
If having a separate page is not really the best outcome, there’s a possibility of creating similar Drupal blocks. The simplest(?) way of doing this is to look at the sources of the above pages, strip them down as much as necessary and then create an HTML Dupal block from the resulting code.
November 2, 2008
By lobo Filed under Architecture, CiviCRMThe CiviCRM core team is currently meeting in San Francisco. We tend to meet 2-3 times a year. These meetings help us crank out a few large projects as a group and also help improve our communication when we return to our respective home bases.
October 27, 2008
By lobo Filed under Architecture, CiviCRMImplementing support for multiple organizations with hierarchy is one of the main themes of the phase 2 part of the CiviCRM / The Public Interest Network (PIN) project. PIN has a fairly complex structure. It is a federation of organizations which include US PIRG, Environment America and others.
October 21, 2008
By shot Filed under CiviMail, CiviCRMI’m happy to report a PHP counterpart to imap2soap is coming in CiviCRM 2.2, so the handling of CiviMail’s return channel should be much easier in the future (ideally as simple as setting up a cronjob).
There are also other CiviMail improvements and changes in 2.2 (kudos to U.S. PIRG for their sponsorship!) which I plan to unveil in upcoming post(s), but let’s concentrate on the return channel for now.
October 21, 2008
By Dave Greenberg Filed under Training
We've begun our planning for CiviCRM trainings and meetups for 2009 - and we'd love to get feedback from folks in the community about interests and availability for these events ...
We're considering three different types of events for the calendar:
Advanced User Training - We held several 2-day sessions this year - focused on the skills needed to configure, customize and use CiviCRM advanced features. These sessions were well received - so we're planning on doing several more in 2009. Fees for these sessions are based on operating expenses.
User Group Meetings - Half or full-day meetups where folks can share experiences and learnings, network, and discuss the future of the platform.
Developer Camps - These 1 or 2 day sessions are "learn by doing" events where developers can work together with core team members on specific projects
October 19, 2008
By kurund Filed under ArchitectureLately there has been lot of confusion using Name, Title/Label and Value. There is also a lot of inconsistency in code and database, hence we are planning to fix it in CiviCRM v2.x release.
Lets take an example of Participant Status, 'Registered'. In this case Name will be 'Registered', value will be an integer from 1..N (this depends on each install) and Label/title can be "Registered" or "I will come" etc. (or a localized version of the word/phrase).
Basic rules are:
October 17, 2008
By loboFiled under The API was a big topic at CiviCamp. We had a good discussion on the mistakes we made in the past and things we can do better going forward. Due to a variety of reasons (internal and external), the API migration between 1.9 and 2.0 was a disaster. We resolved to not let this happen in the future. Here are a few things we agreed upon
