UK Code sprint august 2011

[xavier]

Hi,

Are the dates finalised yet ?

As for ideas of things to improve, got a few things we can nail down around the usability (ajax+api)

1) modifying one existing ajax interface to use the api as the backend (been there for a while, will be easier F2F)
http://issues.civicrm.org/jira/browse/CRM-7970

2) add more in place editing (jeditable or simplier ones, eg changing status, adding a phone...)

3) add grid editing (as more powerful batch editing or for the simple list admin) jqGrid

4) move the quick search backend to the api

On the core, Activity with 3 tables to store various contacts has been proven a PITA. the API team would like to refactor to a single activity relationship.


Two other topics I'd like to start discussing/prototyping: replacement for qF & DBObject. and if Dave is up to it, would like to spend a few hours brainstorming on a clearer structuration of the admin part.

Over to you...

X+

[Donald Lobo]

a. Yes, the dates are aug 23 - aug 30

b. we'll be getting towards the mid / tail end of 4.1 development at that point, so major schema / architecture changes will go in 4.2 (i.e. DBTNG)

c. 1, 2, 3 and 4 are good candidates.

lobo

[Erik Hommel]

Agree on 1,2,3 of Xavier's points, I would also like to do some work on API documentation. Will probably be there for 2-3 days, do not know which ones yet.

[Eileen]

It might be worth exploring Tim's suggestion about a different way of managing the D6 vs d7 issue.

Personally I'd love to see a long term plan for getting the logic out of the forms into the BAO so that one-day we can ditch quick-form.

[Michael McAndrew]

I'd like to build on the great work that Erik B and I did (toot toot!!) on training resources.  Erik is up for doing a train the trainer for civicrm people to help us deliver better 'user and admin' and 'developer and implementor' trainings.  given that we have two trainings coming up after the sprints, it sounds like an ideal time to do that.

michael

[Michael McAndrew]

For the book sprint:

* civi campaign
* general update
* the 'why' as well as the 'what'. i.e. more "If you want to do X, then Y is good approach because....  But one downside of approaching it this way is A." as opposed to.  "To configure events click configure events and fill in the event configuration fields"
* more on CiviEngage with some PTP people.
* narratives/strategies (that may span modules) that explain clever ways to use CiviCRM in the real world
* chapter on duplicates handling
* make sure that everything from training is incorperated in book.
* make it easy to cross reference the book from training materials. i.e. for more information on importing, see ***
* audit that all subjects that aren't components are properly covered (e.g. mapping, duplicates, website integration)
* look again at structure.  It is pretty good at the mo, but always room for improvement

And I would like to avoid teaching non profits stuff they already know.  e.g. "face to face events are one of the best ways to meet your constituents in person"

[xavier]

While we are on the book topic: API v3.

[Eileen]

Another thought is this idea of having a way of recording relationships between CiviCRM entities & drupal nodes / entities. Either by used a cck field type or some other mechanism - we've talked a bit about this before.

I'm just in the process of writing a views relationship to make event data available on an organic groups view. I have linked them by having a cck field ending in civicrm_event with the event code in it so I will build a hook that exposed event data based on that but a more generic solution would be a good thing to discuss.

[xavier]

andreas has written a module for syncing. I'm checking with him.

X+

[Donald Lobo]

Drupal 7 has the concept of entities and an entity API. Can we expose a lot of the civicrm objects as an entity? which in turn would make a lot of linking nodes / civi objects a bit easier via entity relationship?

dont know a lot about the above to really comment, but might be worth investigating

lobo

[Eileen]

Perhaps we could tackle some of the killer queries that still cause problems. Contribution search + select 50 records & choose 'batch update by profile' takes 5 minutes to load on one of our DBs. 4 minutes + is this query.

I can get it down to 30 seconds by adding an index (ALTER TABLE `civicrm_contribution` ADD INDEX(  `is_test`,`receive_date`) if I remove 'contact_a.is_deleted = 0' but that isn't a solution.

At the point this query happens I haven't actually selected the profile to use ...

Code: [Select]

SELECT DISTINCT(civicrm_contribution.id), contact_a.id as contact_id, contact_a.contact_type as `contact_type`, contact_a.contact_sub_type as `contact_sub_type`, contact_a.sort_name as `sort_name`, contact_a.display_name as `display_name`, civicrm_contribution.id as contribution_id, civicrm_contribution.currency as `currency`, civicrm_contribution.receive_date as `receive_date`, civicrm_contribution.non_deductible_amount as `non_deductible_amount`, civicrm_contribution.total_amount as `total_amount`, civicrm_contribution.fee_amount as `fee_amount`, civicrm_contribution.net_amount as `net_amount`, civicrm_contribution.trxn_id as `trxn_id`, civicrm_contribution.invoice_id as `invoice_id`, civicrm_contribution.cancel_date as `cancel_date`, civicrm_contribution.cancel_reason as `cancel_reason`, civicrm_contribution.receipt_date as `receipt_date`, civicrm_contribution.thankyou_date as `thankyou_date`, civicrm_contribution.source as `contribution_source`, civicrm_contribution.amount_level as `amount_level`, civicrm_contribution.is_test as `is_test`, civicrm_contribution.is_pay_later as `is_pay_later`, civicrm_contribution.check_number as `check_number`, civicrm_contribution.campaign_id as contribution_campaign_id, civicrm_contribution_type.id as contribution_type_id, civicrm_contribution_type.name as contribution_type, civicrm_contribution_type.accounting_code as `accounting_code`, payment_instrument.id as instrument_id, payment_instrument.label as `payment_instrument`, civicrm_product.id as product_id, civicrm_product.name as `product_name`, civicrm_product.sku as `sku`, civicrm_contribution_product.id as contribution_product_id, civicrm_contribution_product.product_option as `product_option`, civicrm_contribution_product.fulfilled_date as `fulfilled_date`, civicrm_contribution_product.start_date as `contribution_start_date`, civicrm_contribution_product.end_date as `contribution_end_date`, civicrm_contribution.contribution_recur_id as `contribution_recur_id`, civicrm_note_contribution.note as contribution_note, contribution_status.value as contribution_status_id, contribution_status.label as contribution_status, payment_instrument.name as contribution_payment_instrument, civicrm_contribution.check_number as contribution_check_number, civicrm_value_contribution_source.id as civicrm_value_contribution_source_id, civicrm_value_contribution_source.campaign_source_code as custom_46, civicrm_value_contribution_source.campaign_method as custom_47, civicrm_value_advocate_contribution_data_26.id as civicrm_value_advocate_contribution_data_26_id, civicrm_value_advocate_contribution_data_26.cnt_restrc_100 as custom_100, civicrm_value_advocate_contribution_data_26.cnt_promo_101 as custom_101, civicrm_value_advocate_contribution_data_26.cnt_dept_102 as custom_102, civicrm_value_advocate_contribution_data_26.worker_103 as custom_103, civicrm_value_advocate_contribution_data_26.worker_reference_120 as custom_120, civicrm_value_contribution_source.worker_contact_127 as custom_127 FROM civicrm_contact contact_a LEFT JOIN civicrm_contribution ON civicrm_contribution.contact_id = contact_a.id INNER JOIN civicrm_contribution_type ON civicrm_contribution.contribution_type_id = civicrm_contribution_type.id LEFT JOIN civicrm_contribution_product ON civicrm_contribution_product.contribution_id = civicrm_contribution.id LEFT JOIN civicrm_product ON civicrm_contribution_product.product_id =civicrm_product.id LEFT JOIN civicrm_value_advocate_contribution_data_26 ON civicrm_value_advocate_contribution_data_26.entity_id = civicrm_contribution.id LEFT JOIN civicrm_value_contribution_source ON civicrm_value_contribution_source.entity_id = civicrm_contribution.id LEFT JOIN civicrm_note civicrm_note_contribution ON ( civicrm_note_contribution.entity_table = 'civicrm_contribution' AND civicrm_contribution.id = civicrm_note_contribution.entity_id ) LEFT JOIN civicrm_option_group option_group_payment_instrument ON ( option_group_payment_instrument.name = 'payment_instrument') LEFT JOIN civicrm_option_value payment_instrument ON (civicrm_contribution.payment_instrument_id = payment_instrument.value AND option_group_payment_instrument.id = payment_instrument.option_group_id ) LEFT JOIN civicrm_option_group option_group_contribution_status ON (option_group_contribution_status.name = 'contribution_status') LEFT JOIN civicrm_option_value contribution_status ON (civicrm_contribution.contribution_status_id = contribution_status.value AND option_group_contribution_status.id = contribution_status.option_group_id ) WHERE ( civicrm_contribution.is_test = 0 ) AND (contact_a.is_deleted = 0) ORDER BY receive_date desc LIMIT 0, 50

[xavier]

Some kind of small that have been a pain for quite a while (not sexy, but probably will be done much faster being around the same table)

1) put a context to the token hook (so you don't calculate a token that is never used by the template)
2) move the register now to the top of the info page for events
3) put a link/some links (for admins) in the info page for events
4) instead of just one title, have both a title and a label for the profiles (so you can have something readable in the back office and user friendly in the front office

And I would leave with a solution on how to send event invitations from civicrmail without having to copy paste everything (token with |event_id or something). Still not clear about how to do it.

X+

[Eileen]

One gap I'm aware of in the testing is the need for people to be able to run tests against their own site. I seem to get fatal errors when I upgrade due to specific configurations, or DB size, or enabled modules - the thing is that if I could run the standard tests on my DB then they would fail & bugs would be picked up earlier.

[totten]

Ditto on:

• DB_Query / DBTNG
• D6/D7 issue (e.g. making the two UF's coexist)

And to toss in a couple pet projects; these definitely require some justification:

• Reconcile "hook"/"component" models -- CiviCRM has several ways of using the "pub/sub" or "event/listener" concept to achieve loose coupling between different software components. Some of this is easy to understand (e.g. Drupal and Joomla hooks are different, but they use the same names and signatures). In the case of CRM_Utils_Hook and CRM_Core_Component, they do the same thing -- except that they do it all differently. It feels like this complexity in the pub/sub layer would tend to increase complexity, make the learning-curve steeper, and discourage adoption of robust pub/sub.
• Implement RFC822-over-HTTP email return channel -- This is a model that I've used to pass email into other Drupal modules. It's probably not as performant as the SOAP/API-based channels, but it's more maintainable -- easier to port and less coupling to the VERP strings
• Web-editable templates, esp. profile templates -- I would like to enable implementors with basic HTML skills to tweak the layout of forms (esp. profile forms). This can currently be done by writing a new .tpl and dropping it in the right directory, but it presents more issues with training, maintainability, user-management, etc. In my mind, a good solution would:
  
  • Include an "Edit" link for each profile form; this would be populated by some default "tpl" code which imitates the main file
  • Include a validation tool which probes user-supplied .tpl files to identify missing/invalid form elements
  • Be consistent with the file-naming conventions in "civicrm/templates" and "custom templates".
  • Be optional - so that admins can disable it if it's required for their security posture

[Donald Lobo]

I've copied most of the ideas (along with the owners) that i understood to the page here:

http://wiki.civicrm.org/confluence/display/CRM/Code+Sprint+Plan+-+London+August+2011

Please do add stuff that i missed that YOU would like to accomplish and work on during the sprint to the wiki page. I'd like to have a good handful in each group, so we have a good list of things that we can knock off

We should also flush out the details of the other sprints on the wiki. I'll allow the leads on those sprints to do the needful. Lets use the wiki and edit things there going forward

lobo