Blogues

I attended a one day user camp in London, UK last Thursday. The experience level ranged from people wanting to know more about CiviCRM and if it would be a good fit for their organization, to people who have decided to use it and were now keen to get more training.

This is a follow up to our last post proposing a new architecture for CiviCRM. Much appreciation for everyone's patience. Following from our last post we want to go over the use of Doctrine, a PHP implementation of the Active Record design pattern made popular through Ruby on Rails. The Doctrine Project has done a great job of maintaining detailed documentation and has a lot of features that we believe everyone will find useful when working with CiviCRM objects. We have posted some of our working code for the new ORM and REST API here at git hub.We have given this code set the working name civiBASE.

We want the ability to sell tickets. CiviCRM has a maximum participants feature but this applies to the whole event. We want it to apply to each individual ticket. This will be particularly useful when related to a floor plan which can be uploaded.

In the Price Sets. In the Page Edit a price set. Next to Price will be another column called "Number" (people can suggest something better) where the number of tickets can be set. I thought this should not be in "Edit price numbers" so that different groups could still pay different amount but would deduct from the remaining tickets.

My name is Jamie and I'm a student of Physics with Philosophy at the University of Manchester. I used to work with a bunch of people on a community-based church website. Recently we've been employed by a Thai Boxing company to build a community-based website as the hub of the various things this company will try and achieve. (So yes, currently we don't work with non-profits!). Currently its just a CMS but the community side of things will come (hopefully)

Version 2.2.7 was released today with CiviReport ("the return") phase 1. This version includes fourteen report templates with coverage for contact data, activities, contributions, events and memberships. Folks in the community who have had a chance to preview the functionality have been quite excited - and we think this is a significant step forward for CiviCRM. First, a few concepts... CiviReport is delivered with a set of report templates. Each template covers a general reporting area - for example: Donor Report (Summary), LYBUNT (Last Year but not this Year), etc. Administrators can then create one or more report instances from a template - with specific display columns, filters and grouping rules. Users go to the CiviReport menu to see a list of report instances, and run the reports.  

The team has released version 2.2.7 today. This release includes an important security update - and we recommend that you upgrade sites to this release as soon as possible. 2.2.7 also includes phase 1 of CiviReport - with 14 built-in report templates with coverage of contact data, contributions, events and memberships. Stay tuned for a separate blog post with lots more details on the new reporting features.

Last week Kurund, Michael, Mari, Xavier and I spent 2 days in the UK training camp and 1 day at the user camp. We had a great turnout at both camps with a 18 participants in the training camp and 8 participants in the user camp. Training Camp The training camp was held over two days. Similar to our other camps this was also in an unconference format. The topics were decided by the participants and we split the day up into 5 sessions on both the days. Some takeaways from the user meetup: The UK NGO's rely more on government funding than on donations. Reporting and managing gift aid is important. We sketched out an implementation and a custom report for this on the wiki. More code on this coming soon Folks were quite excited about CiviReport and the reporting framework. Quite a few discussions on effectively supporting multi-org installations (n drupal installs, 1 shared civicrm db) A good discussion on how to make CiviCRM get around the "not built for UK (insert your favorite country here)" discussion. At some point in the future we should set better defaults given the installation country rather than only one set of defaults worldwide. How to extend and modify CiviCRM via hooks was a popular topic. We definitely need to post more examples and add even more support for this in future versions.

Those that missed out on the last three days of CiviCRM fun in London (and those for whom three days just wasn't enough) will be pleased to hear that this July's London Net Tuesday will be focused on CiviCRM. Nic Rodgers from Enable Interactive and I will be there to answer your questions and talk about how organisations in the UK and further afield have been using it.

Two key usability goals for the upcoming 2.3 release are: Reduce the number of "clicks" needed to move around in CiviCRM Allow sites to optimize CiviCRM navigation for the way they use it We've been working hard on the new navigation system - and it's now ready for folks to try it out on the 2.3 sandbox. Login as usual with: user = demo password = demo ... and click CiviCRM on the Drupal navigation block.

Here at raSANTIAGO we are entering our third year with CiviCRM and still find ourselves struggling to make desired changes to the codebase. Too often we have expressed desired to re-architect and re-factor the CiviCRM. Recently we have completed two major projects that had us deeper in the codebase then before and realizing that we had to stop complaining.