I just uploaded the first version of the Perl client module for the CiviCRM REST API. You can download it from CPAN here. This means you can now create, edit, delete, and retrieve (most of) your CiviCRM data from Perl scripts and programs. I'm using it to provide integration between the Perl CMS WebGUI and CiviCRM.
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.
- Here's a report back from Sacha Stanton
The New York Meetup was a great success last night, as 33 people got a glimpse into upcoming releases, several case studies, and great open floor discussions. Dave Greenberg, core contributor, joined in via Skype video to provide insight into upcoming features and answering questions.
The second SF Bay Area User Meetup was hosted last night by Wikia and Wikimedia Foundation folks (big claps). We had an excellent turnout (the room was packed) - with a nice mix of backgrounds ranging from prospective users to experienced folks and a few developers.
The first part of the meeting featured 3 presentations:
Case Study: Chez Panisse Foundation - Evaluating a CRM solution and the process of migrating to CiviCRM (Max La Riviere-Hedrick : futurepruf.com)
Case Study: Generations Community Wellness: Donate Your Fat - Building a rich community engagement site on top of CiviCRM (Roberto Santiago : raSantiago.com). You can download Roberto's slides here.
What's coming up in v3.0 (yours truly - with a great slideshow created by Brian Shaughnessy - Lighthouse Consulting and Design)
The day has come! We are excited to announce that our 3.0 ALPHA release is now available for download. You can also try it out on our sandbox site. Please remember it's an ALPHA release and it shouldn't be used on production sites.
This release introduces many new features, some of them really important, that's why we decided to start a new major number series in CiviCRM versioning. One of the most important new features is CiviReport, which is a completely new component for advanced reporting on your constituent data. Second significant change is a major user interface redesign with a goal of increasing usability. CiviEvent was also improved with waitlist functionality, pending status expirations, and an option for administrator approval for participants. A full list of changes, improvements and bug fixes in this release is available on the wiki and in the issue tracker.
This post started out as a reply to Eileen's "Banking Screen?" comment on my previous post on this topic, but by the time I was done, I thought that this warranted its own post.
I think that the core "Accounts" or "Banking" functionality that could be helpful to Civi users without getting too out of control, is:
The team has released version 2.2.8 today. This release includes an important security update for sites which use CiviCRM Profiles to collect and / or share contact data. We recommend that all sites install this upgrade as soon as possible. Details here:
Affects Joomla! sites only
Affects all sites using Profiles
2.2.8 also includes fixes for IE8 compatibility, some improvements in Views2 integration and approximately 30 other minor bug fixes. You can review a complete list of 2.2.8 changes on the issue tracker. Note that the IE8 fix causes the browser to run in IE7 compatibility mode for all CiviCRM pages.
We are finding that CiviCRM/accounts issues are becoming increasingly important for our clients, and Eileen's recent blogs and the discussion they are generating are a fantastic step towards helping find the best way for Civi to deal with financial transactions.
For example, I think it could be useful for Civi to ultimately develop functionality for maintaining simple bank accounts within CiviCRM, so that small organisations can maintain basic accounts without the headaches of integration with an external package.
This is my second blog on the topic of integrating with CiviCRM with an accounting system. Those of you who haven't just run screaming from the room or suddenly discovered an urgent need to polish the inside of your car exhaust, re-organise your tupperware or push needles into your eyes ... read on.
One of the areas that occasionally hits the forums is whether CiviCRM integrates with accounting systems. I've been giving a little thought to accounts integration lately and have now spent a bit of time poking around the Xero API and thinking about what I would do if I were to spent time trying to get CiviCRM talking to Xero. The content of this blog is mostly non-technical so if you can safely ignore the stuff about APIs if it doesn't mean anything to you.
I'm working on deploying CiviCRM for my kids school website. Part of the project requires us to expose the parent <-> child relationship information on the website and allow parents to edit their child information.
I accomplished this using a combination of civicrm hooks, custom templates, permissioned relationships and custom code in a drupal module. You can access the module and template code here.
The broad steps are:
Implement hook_civicrm_pageRun for the profile view page (CRM_Profile_Page_Dynamic). Only implement this hook for the specific profile id's you want relationship information. In this case we have two profiles, a Parent Profile (gid=3) and a Student Profile (gid=4)
The pageRun hook also adds the module's template directory to the smarty include path, so we dont have to set it globally. This also allow multiple modules to append different template directories to the template include path (check the function _sfschool_initialize)
The hook gets either the parent or the child information using a custom query. We ensure that only permissioned parents can see their child information (in case of some complicated family structures). The queries are relatively simple at this stage, i suspect they will increase in complexity over the next few weeks
The hook exposes the information gathered from the database to the smarty template
The custom template (templates/CRM/Profile/Page/3/Dynamic.tpl) uses that information to display the relationship data on the page. I also edited the View.tpl template to eliminate the "Back to Listings" link.
