It looks like some funding might be coming through for us, and a good chunk of it will be able to be spent on CiviCRM Entity development.

The motivation for the clients' funding is to improve Drupal integration, especially in the realm of Drupal interfaces to CiviCRM data. This would build on the existing edit/add/delete form capability

The big items:
1) Rock solid and automated native Drupal form validation
2) Improved metadata
2) Widgets and formatters for FK fields especially, and all fields in general
3) Better custom field support
4) Open up all entities supported by the API
5) Integration of https://github.com/jackrabbithanna/civicrm_entity_inline
6) bug and issue fixes such as this issue: https://www.drupal.org/node/2669818

@Eileen
Would you like to see these kinds of features going toward the 2.0 branch
Would it be appropriate to start a 2.5 or 3.0 branch?

Keep in mind that soon we'll be wanting to start a 8.x branch as well, but would want to base it on apiv4 maybe?
Food for thought: https://www.drupal.org/project/external_entities

@Everyone
Any good ideas from the community for further features?
Now's a good time to have your voice heard, and even better, put your money in the hat.

Comments

markusa created an issue. See original summary.

markusa’s picture

markusa commented
Related issues: +#2676668: Custom field handling architecture discussions
markusa’s picture

markusa commented

Additional future ideas:
Profiles integration
Contribution View pages that load profiles and actually process transactions, can handle membership registrations
Event registration pages, that load profiles and actually process event registrations

sonicthoughts’s picture

sonicthoughts commented

Fantastic!

I know you listed "external entities" but wonder if there is a more generic way to integrate D7 + D8 entities with a REST API ? Deal with things like caching, batch over remote database, etc. I looked at some a while back: #2385785: Civicrm Entity property field formatters. not sure if Remote Entities could be useful. Also, might want to look at how the Salesforce Suite is approaching things. They are doing some sync into native drupal objects (which may have some use cases for civicrm) but might be worth looking at. They allow custom mapping too which might be handy. No need to pull the entire object if you don't need it. I saw some memory issues (esp with custom fields.)Also this found this https://2015.badcamp.net/sites/default/files/session-files/Remote%20Enti... ... just a thought .

BAdcamp session video might be worth checking out: https://2015.badcamp.net/session/remote-entities-past-present-and-future

markusa’s picture

markusa commented

External entities is fairly generic, but its a D8 project only. The reason I posted that here was to look at an approach that was used already in D8 to do something that is similar to what we are doing with CiviCRM Entity.

The D8 version of CiviCRM Entity will be a complete rewrite from the ground up, and there are some fundamental architectural differences between D7 and D8 that actually make it HARDER.

I was actually at the BADCamp presentation you reference, and I've investigated that module as well. CiviCRM Entity could be updated to make remote REST calls to CiviCRM installations not directly embedded with the Drupal installation, and that's not a bad idea for a feature addition. Views would be the most difficult thing to get a grip on with that scenario, but its not impossible.

I've used the Salesforce Suite as well a number of times. I found it painful to develop against. Perhaps I could rinse the bad taste out of my mouth enough to give it another look, it was several years ago. The idea of mappings is interesting, but seems very edge case to me, and would only be developed if somebody was willing to put in a significant monetary investment. I really want to get it working with "everything", then think about adding options to pare it down.

I haven't run into any memory issues myself with CiviCRM Entity, how many custom fields did it take to get a memory error?

I could integrate EntityCache as well, its not hard to do.

I do think there is good code in each module, and lessons that can be learned from each project. Thanks for bringing these projects to our attention.

sonicthoughts’s picture

sonicthoughts commented

Great - guess I'm not sharing any Epiphany but thought it was worth mentioning. Also, good chance to leverage / provide input for API v4: https://wiki.civicrm.org/confluence/display/CRM/API+v4+Spec . Hopefully Core Team is starting to see the importance of this module which could provide a unified drupal integration and consolidate/refactor all the drupal specific code....

as for memory I logged an issue: #2607026: high memory usage

sonicthoughts’s picture

sonicthoughts commented

Any thoughts about processing payment...especially recurring payments which webform cannot do. Using a contribution page to process paid contributions or likewise for events would be spectacular.

Also wondering about connecting entity relationships, would that be done using a module or in civientity?

markusa’s picture

markusa commented

The goal is to do it all, what comes first, and when will be decided by client demands.

We want the connecting entity relationships, both on the objects, and in Views.

We look forward to having a full fledged drupal native contribution page one day as well, and we're considering having the option to use a Drupal commerce workflow, as well as the native CiviCRM processing.

demonde’s picture

demonde commented

I really love the idea to base the drupal 8 branch on the external entities module.

markusa’s picture

markusa commented
Status: Active » Closed (outdated)