Aller directement à la fin des métadonnées
Aller au début des métadonnées
Étiquette
  • Aucun
  1. Apr 25, 2013

    shawn holt dit :

    Create Drupal Entities for CiviCRM objects

    I've tried making noise about this - I believe this could be truly transformative for CiviCRM - opening up far more capability to non-programmers and other drupal intiiatives.   Work is already underway:

    http://drupal.org/sandbox/eileen/1923028

    https://github.com/eileenmcnaughton/civicrm_entity/

    https://github.com/bangpound/civicrmentity

    Basic advantage of Entity API:

    * Consistent and extensible Drupal architecture with entity properties, callbacks, data wrappers, fieldable, revisionable, exportable, Feature integration, token support
    * Very strong Drupal support with over 200K active users and over 1M downloads.
    * Drupal core only provides an EntityController for loading entities
    * Administrative UI
    * ...

    2. Single, consistent data layer integration for Drupal

    * Ctools based modules (Panels, context, etc.)
    * Great ways to manage display (Panels Fields, Display fields, stylizer, etc.)
    * Caching of civicontent via Remote Entity API http://drupal.org/project/remote_entity
    http://drupal.org/project/remote_entity
    * Ability to expose civicrm via Services integration
    * Consistent drupal module access via entity_metadata_wrapper http://bit.ly/116E1KL

    3. Can (perhaps) retire other integration utilities / approaches and simplify / lower costs

    * Views
    * Webform
    * Entity Views Attachment (http://drupal.org/project/eva) can add any Civi content to a drupal node
    * many more I haven't thought of ....

    4. Ability to leverage to over 700 D7 drupal modules that support or extend entitieshttp://bit.ly/116zVCs

    * rules
    * views
    * display suite
    * Form extensions
    * Many more

    5. Upgrade path to D8 support for Entities

    http://previousnext.com.au/blog/understanding-drupal-8s-config-entities
    http://drupal.org/node/1346204
    http://hojtsy.hu/blog/2013-feb-07/learn-drupal-8-now-helping-make-it-mor...

    6. Leverage Drupal debug tools (ie. http://drupal.org/project/devel_entity)
    7. Might include read and write support and allow for tighter drupal integration
    8. Many Drupal Distro's (Commerce, Open Outreach, etc.) and other tools (Calendar) have Event capability via Entity. OpenOutreach and other modules are integrating with RedHen via Entities, A solid CiviCRM Entity integration may allow for alternate CiviCRM support.

     There are several posts I will reference and excerpt:

    http://forum.civicrm.org/index.php/topic,27227.0.html

    the nice thing about exposing the civicrm entities as drupal entities is the general ability to use them throughout drupal. Chaos tools (panels, display suite, rules, webform, commerce, views, etc.)  I realize there are many approaches to this integration, and I'm not a programmer, so I may be really off base, but these approaches (services or directly via entity API) seem like a generalized and extensible approach. 

    https://github.com/eileenmcnaughton/civicrm_entity/issues/1

    http://forum.civicrm.org/index.php/topic,27871.15.html (another approach to Mailchimp API)

    There is work by Eileen and others to have civicrm work as a bona-fide entity in drupal.  This would allow us to use many drupal modules that operate on civicrm fields.  Obviously this is hypothetical since the civicrm-entity work is still in progress, but it seems to me on the surface that we may have much more bang for the buck if we could get the entity thing nailed and let the drupal-mailchimp module (or other drupal mail integration modules) manage the mail process logic but rather than work on drupal profile entities and groups, it can work on civicrm groups and update unsubscribes, sync lists, etc. I realize that this is a very different approach than we have traditionally taken, but it would open the door to far more integration with drupal modules and dramatically reduce the duplication of effort.  Furthermore, we could benefit from the contribution of the much larger drupal audience.  

    I am aware of several projects that are working on this.  See this thread for more details:
    http://forum.civicrm.org/index.php/topic,27227.0.html

    and some discussion on github:
    https://github.com/eileenmcnaughton/civicrm_entity/issues/1
    https://github.com/bangpound/civicrmentity

    There has already been some work done using the views-entity / token integration (http://drupal.org/node/1253612) .

    I'm convinced that this type of integration can transform druapl-civicrm architecture and open it up to a the broader drupal community.  RedHen has had a lot of success by integrating as a drupal entity and making it much easier to work with in new distributions (OpenOutreach, Drupal Commerce, etc.)  We could avoid many of the drupal-integration band-aids in views, calendar, etc. and take advantage of all the drupal displays like DisplaySuite, Panels Fields, etc.  Any civicrm entity could be viewed in Drupal as a Bean, for example and have additional Drupal or civicrm fields associated with it

     

  2. May 02, 2013

    Could some of the unfunded phases of CiviAccounts be launched as a new Make-It-Happen?  Such as the phase to allow multiple transactions ( check/cash/credit card(manual)/credit card automated recurring or a mixture) to be used to pay one contribution?    This should allow the expected payment schedule to be specified, o that cash flow can be predicted. ( ie a contribution of $1000 that the donor has agreed to pay by check monthly for 12 months)

     

     


Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.