CiviCRM Community Forums (archive)

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

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.

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"

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.

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

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+

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