Blogs

Some recent discussions and debates about Active Record and Data Mapper have popped up in the context of new architectural proposals for CiviCRM from Dharmatech and raSANTIAGO. We think it is important that the differences between each is known and to clarify what are some erroneous perceptions. This is not to claim that either design pattern is above criticism. It is to say, that there are some misperceptions that prevent a more intelligent discussion of the trade-offs between these two design patterns. Our hope is to bring some clarity to this discussion.

Current CiviCRM architecture pitfalls rasantiago has proposed a new CiviCRM architecture with details of the ORM layer. Torenware commented on the latter and mentioned some particular scalability issues.  Our own experience with the Active Record design pattern proposed by rasantiago is that it works well for small projects but doesn't scale well.  We believe that CiviCRM is now facing serious scaling problems in several areas, to wit:

You might want to display more information that those that are assigned by default in the template. My goal was to have a simple way of retrieving more information from civicrm than the ones available in the template, without having to modify the php code . For instance, I used it to display all the employees of an organisation from the profile that displays the organisation, or to display a list ofother contacts that live in the same country than the contact you're viewing. In London in the last training, we discussed about displaying the activities directly in the contact summary tab for instance.

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.