13 May, 2009
By jalama
Filed under CiviEvent, v2.3, CiviCRM, Drupal

With CiviCRM 2.2.3 and a patch to the Drupal Date API CiviCRM will be adding integration with one more Drupal Module, Calendar. This means you will be able to display CiviCRM events in Drupal calendars and decide what events are displayed by using Views filters in the same manner as you would any View.

As with the Calendar module in Drupal the same dependencies exist meaning the latest version of the following modules must be installed; Views, Date API and Calendar. Once you install CiviCRM and the other modules a disabled CiviCRM events view, formatted as a calendar, will be available under Site Building | Views. You will need to enable this calendar, at which point a calendar will be available at http://www.example.com/events. As with the Calendar module the best practice is to clone the default CiviCRM events calendar in order to create any custom Calendars, be...

Read more
08 May, 2009
By lobo
One of the reported shortcomings of CiviCRM has been the perceived "lack of reporting functionality". This is true to a large extent, but our hope was that most folks would either use
  • Traditional reporting solutions: BIRT, Jasper Reports and/or Crystal Reports. We demoed an integration with BIRT a few releases back, but this did not get any traction. There are a couple of larger deployments that have built custom reports using BIRT and Jasper.
  • Views2 and CiviCRM integration. However the lack of grouping / sub-total functionality has prevented this from being a complete reporting solution. This is also a drupal only solution
  • Custom Drupal modules / Joomla components. Quite a few folks have gone down this path, but there has not been a lot of sharing of these reports within the community
Based on the success of Custom Search, we decided that shipping CiviCRM with a few good... Read more
07 May, 2009
By jalama
Filed under CiviEvent, v2.3, CiviCRM

At the Developer camps on the 28th and 29th of April, 2009 (ie last week) one of the major tracks for all the breakout sessions was usability. Which is a major theme of the 2.3 version upgrade. In two of the groups I participated in we talked about the usability of the CiviEvent module from a an administrators perspective. One frustration that we decided need addressed was the 5 step wizard to create an event.

The items we discussed were the ridigity of the event creation wizard, adding simple events shortcuts and event templates. The Event creation wizard gives the impression that you have to go through all 5 steps to create and event even if you only need the first one or two steps (basic event description & location). In order to speed up the process of creating simple events we proposed creating shortcuts for 3 different common event types. Finally we...

Read more
17 April, 2009
Filed under CiviCase, v2.3, v2.2, CiviCRM
Several members of our core team just got back from a 3 day CiviCase meetup in beautiful Vancouver, Canada - hosted by Physician Health Program - BC (PHP-BC). Our main goals were:
  • Get face-to-face feedback from PHP staff who are using CiviCase about what's working and what needs improvement in the existing implementation.
  • Do some code sprints to get some quick wins for implementation within the current release cycle (2.2.3)
  • Review the list of candidate features for Phase 2 in order to get a better understanding of the requirements, and discuss a range of implementation "solutions".
  • Prioritize the Phase 2 list and come up with a scope of work and specifications for the 2.3 release.
The PHP-BC staff did a fantastic job of welcoming us, arranging logistics for housing and meeting space, and keeping us well fed (they hosted several incredible lunches and dinners)! We built an agenda that allowed... Read more
15 April, 2009
By michal
Filed under v2.3, CiviCRM
A major focus for the next version of CiviCRM (v2.3) is improvement and optimisation of the user interface and its usability. During the last few weeks, together with our Advisory Group, we've been busy investigating different options for changing the way CiviCRM looks and behaves. This project will has quite a large scope, and will span over at least two versions. For version 2.3, one goal is to unify the way different functions are being handled from a user interface perspective. We'd like clean up the HTML and CSS for as many templates as possible, and introduce stable standards for building user interface elements. From a technical point of view, one of the efforts is to make heavy use of jQuery and jQueryUI, but that seems like the easy part. Much more difficult is figuring out how to make our user interface easier to use, provide solutions that will allow people to perform everyday CiviCRM tasks quickly and... Read more
25 March, 2009
By shot
Filed under CiviEvent, v2.3, CiviCRM, Drupal, Joomla

We’ve just finished describing some of the new CiviEvent features we’d like to put in CiviCRM 2.3, including waitlisting and optional admin approval of participants. Please take a look at the CiviEvent - New Features for 2.3 wiki page and voice your opinions.

19 March, 2009
Filed under v2.3, CiviCRM
There are many places in CiviCRM where lists of records are presented... when you search for contacts, you get a list of contact records; when you go to manage events, you get a list of events; etc. Kurund blogged recently about prototypes for improving usability for these record listings (we call them "selectors" internally)... and we got a lot of good feedback from that post. Kurund and Amit on our team have now put up another iteration - which we'd love to have folks look at and comment on: » Contact Listing The new version incorporates these changes: * The listing now has "sticky column headers" - so when you scroll down the page "past the fold", the column header moves down with you. This feature seems like a no-brainer good thing to do - so the plan is to use that for all listings. * Context menu "actions... Read more
13 March, 2009
Filed under v2.3, CiviCRM

I'm putting this together to help the next version of civicrm. We needed a waiting list for events once they are full. Our needs will perhaps differ from a generic version but you have to start somewhere.

We started by detecting the state of the event with eventFull(). If it's full and the user is not already a participant OR in the waitinglist table, we give them a simple link which will add them to the waitinglist table.

We use a first in first out system so when a participant is deleted, removed (status) or otherwise changed, we trigger a checking script that checks the maxParticipants and total to see if there is now a space. If there is we take the top one from the waiting list and add it to the participant list as a specific status (we used 'added by waiting list'). Our system isn't quite finished yet but we're thinking of auto removing people from the civicrm_participant table when they've not confirmed for a while.

At the point mentioned above, we email...

Read more
15 January, 2009
By lobo
Filed under v2.3, Drupal

Some personal info to set the background: I have two kids who started kindergarden and pre-k earlier this year. We've also been involved with the KidZone Museum (in truckee, ca). Small schools and museums have a large part of their annual budget come in via live auctions. I did a bit of digging around and could not find any open source software that addresses this sort of fund raiser auctions. However there are quite a few commercial providers with software that addresses this market. I had a pretty detailed conversation with Spin from Auction IT Wizard who's built a good PDA based system to make auction management and ticketing much easier and signficantly faster at the site. He was interested in building a PHP/MySQL backend to collect and manage the data pre/post auction.

Based on his requirements i figured Drupal/Joomla/CiviCRM did a fair amount of this already and with the additional...

Read more
22 December, 2008
By shot
Filed under v2.3, Architecture

As the various localisations of CiviCRM get traction, the first localised versions of documentation pages begin to show up – and this brings us to the issue of how to internationalise these of the CiviCRM strings (texts) that contain links to documentation pages so that when a given string is translated to, say, German, it also refers to the German version of the documentation page (if such is present).

For previous and current CiviCRM versions (including the upcoming CiviCRM 2.2), when we internationalised a string, we wanted to leave the link to the documentation page outside of the string, like this: {ts 1=http://wiki.civicrm.org/…}Read more at %1{/ts}.

This approach has two major benefits:

  • The translators are not bothered to retype the link letter-to-letter in their translations (any errors here would mean that the link stops working), and
  • if the link ever changes, the string (‘Read more at %1’) doesn’t, and...
Read more