Goals for CiviCamp
Please add a few things we can accomplish as a group at CiviCamp. All attendees are expected to be fairly savvy with CiviCRM (from a user/admin perspective) and have a good idea of the CiviCRM schema. Understanding CiviCRM internals would be nice but not essential.
I'd also like to avoid getting into discussions about why CiviCRM does not do things the Drupal way etc
. Here are a few things on my mind. I've taken the liberty to add a few controversial topics
Drupal Modules to integrate with
- Views2
- Organic Groups Sync
- Fix bugs in og_civicrm_synch for trunk and get 2-way synch working
- Make the linkage between an OG and CiviCRM group conditional when the synch module is enabled
- Consider enhancing the CiviCRM buildForm hook so that it can also inject fields into standard form templates (use injecting OG synch prompts into Group Settings form as a test-case for this)
- Consider Rob Thoren's model for runtime synch - CiviCRM maintains group membership and passes that info to OG.
- CCK? (take a look at CiviNode?)
- CiviMember_Roles (http://drupal.org/project/civimember_roles). Pull this into CiviCRM core
- Quickform module (by David Strauss) and/or general better integration with Drupal Theming layer ?
CiviCRM API
- Goals and future of API
- How can we get developer community to help lead/participate in development/documentation/testing of this
- How should we structure things going forward so we are not duplicating a lot of code (and hence neglecting the ones the core team does not use)
Get YOUR Issue(s) Coded for 2.2
Some (all?) of you have client-requested enhancements / fixes "in the queue". We can do code sprints on these issues to make sure they get included in the next release (2.2). Examples include:
- No obvious way for the user to edit a profile at /user
- Usability Improvement: organizing dropdown select boxes that list fields
- Visibility control for event participant statuses
- allow admins to specify maxlength for text fields (built-in and custom fields)
- Drupal Calendar <-> CiviEvent and/or CiviCRM Activities integration
CiviCRM Unit Testing
- How do we get the community to help build unit tests.
- How do we "force" the core team to be more "religious" with regard to this
3rd party components being used
- Should we migrate to jQuery, if so why?
- Should 3.0 switch to using the Zend Framework
Performance of large sites and DB schema changes
- Any major schema changes needed to improve performance?
- Things we can / should do to make CiviCRM more extensible

4 Comments
Hide/Show CommentsSep 22, 2008
dave hansen-lange
"Things we can / should do to make CiviCRM more extensible"
I had this idea yesterday that a template pre-process layer would be great. kinda like theme functions in Drupal. A way to manipulate the display before it gets to the .tpl file. I often find myself needing to put a php section at the top of templates to remove a variable, do a minor manipulation or the like. It feels really wrong everytime I do it. In Drupal best practices say that you should never have anything more than an if statement in a .tpl file, maybe an else statement, anything more makes it difficult to maintain in the long run, not to mention the fact that it breaks the MVC pattern.
The new hook_civicrm_buildForm() is a move in the right direction. The problem being that it only works for forms. For non-form templates I'm still stuck with php blocks.
Sep 20, 2008
dave hansen-lange
+1 for migrating to jQuery.
It is quickly becomming the goto JS library. It's fast and lightweight. But its biggest strengths are in its ease of use and its big base of experienced people that dojo doesn't have. I find that everytime I want to do some extra JS work in CiviCRM I just end up using jQuery instead of trying to use dojo.
Oct 01, 2008
Matt Chapman
++1 for jQuery.
You might even be able to lighten the Drupal tarball since it's already included in Drupal ?
Oct 13, 2008
DharmaTech
Testing Views 2 as reporting mechanism.
Input: event, contribution, date range, amount range, include/exclude by: group(s).
Output: cid, display name, address, contribution (date, source, amount, max donation, max date).
If household, exclude associated household member individuals.