Notes from CiviCRM 4.0 Brainstorm

The following notes were gathered from the CiviCon session on what the community would like to see in CiviCRM 4.0: * Goals * No new features * Framework switch * Not as major a rewrite as it looks * Don't want to change many of the private APIs * Want to switch away from pear * Test unit coverage * Better API hooks * What users would like to see * Continuous Integration * Hudson - as you submit code runs through suite of unit tests to see what's broken * Better decoupling * Drupal Forms API * * Better integration with Drupal DB layer * Scale better * Drush installation of managed hosting CRM * Support Aegir usage * * Better plugin architecture * Payment processors * Custom searches * Custom reports * * Better modularity * More custom modules directly to CiviCRM rather than rapid development in Drupal * Without making it harder to use the CMS's capabilities * REST architecture for all system, not just contacts * Adding formats * Lower system requirements * Hardware detection vs. actual usage * One click minor version upgrade * With backup * Scalability on de-dupe or import * Allows CiviCRM to enter new markets * GUI for the Dharmatech tool * Frozen API on release - standardize and then freeze * System modularity decoupling * Task focused admin layout * Problem with ordering of steps to achieve a task * Combine custom datasets and profiles * Being able to re-factor custom datasets into new * Cannot assume that CiviCRM is the only datastore of contact info (Facebook) * Core and Contrib "Componets" for better integration and modularity * Look at Features? - package configurations * Component is just a library * What can be done first? * Put up frameworks and allow people to provide feedback * Frameworks * Zend * Framework testing * Easy to develop * Scalability to multi-million records * Good documentation * Incorporating upgrades to the framework * Strong developer community * Forward thinking - not just catching up on technologies * Some level of database independence * Coding Style * Proper ORM with less raw SQL * CiviCRM object model * Right now you have to learn many different languages to develop on Civi * One single language would allow for less consultation on API docs * Some type of common underlying nodes * *** = better testing & scalability - these are also the top requests

Comments

One thing that was mentioned that made sense to me was that the priority should be placed on items that are hard to change later.

And I wanted to mention this but we ran out of time: The current use of autoincrement id's (which has some definite pluses) isn't cluster-aware. This may not be high on the list for the average organization, but it may be hard to change later, and wouldn't affect average organizations.

My big requests would be:
*ACL on Joomla (1.6)
*Integration with extended Joomla account data (1.6) - part of the Civi-isn't-the-only-data-store point
*Better account management by the user (more customisable dashboard/linked contacts/household addresses/membership purchasing for related contacts etc) and logging of what they have done.
...but I wasn't there, so maybe I don't get to ask!

This is a pretty substantial list & makes good reading. One thing I noticed is the reference to ORM vs raw SQL.

I have noticed that there are a bunch of integration methods including
- raw sql
- api
- using CiviCRM code base functions

and there doesn't seem to be any clear preference by the core team as to which approach developers use. At some level I feel that the API should be the method of choice for developers to interact with CiviCRM as this is the focus of testing & consistency but the documentation on the API indicates that there should be a direct relationship between tables & api functions which seems a bit limited to me at times? e.g. I would think there is a place for Chris's 'create transaction' api or APIs that are more BAO than DAO.

I may be completely wrong...

I'd like better integration with the drupal users system and contacts. Specifically on the side of turning contacts into users, and allowing admins to create a drupal user for the person at the same time as the contact in civicrm so they can login and update their details