We addressed this via https://github.com/eileenmcnaughton/civicrm_entity/pull/514 and this was in beta7
A proximity filter exists! :)
its included in the CiviCRM Entity module
If you have a View listing contacts, you need to add a Views Relationship to the Address entity type.
Then you will have a filter available "CiviCRM Address (CiviCRM Entity): Proximity"
It uses CiviCRM's geocoding capabilities to derive long/lat from user input
https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/Plugin...
We merged https://github.com/eileenmcnaughton/civicrm_entity/pull/527 for this issue
Some short term options:
Try installing Views Bulk Operations module.
I'm not sure why Feeds in particular is causing that, perhaps it is trying to discover all Action plugins differently than Core or in some different context.
If you're not using that Action, you could just patch out the entire file.
We're reviewing this PR https://github.com/eileenmcnaughton/civicrm_entity/pull/525 which should fix it.
I don't think we need to set NULL anymore for those 2 constructor parameters, but we're testing to make sure.
This is merged, and will be out in a new release soon
Just merged a PR for this: https://github.com/eileenmcnaughton/civicrm_entity/pull/521
you can patch your system with composer,
https://patch-diff.githubusercontent.com/raw/eileenmcnaughton/civicrm_en...
until I make a release. Waiting on one fix for another issue to do that.
@allen
See this line: https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/Hook/Q...
Wanna try putitng a "\" in front of CRM_Core_I18n_SchemaStructure::columns();
$columns = \CRM_Core_I18n_SchemaStructure::columns();
I think it maybe that simple.
Its probably this: https://github.com/eileenmcnaughton/civicrm_entity/pull/515
We'll be working on a patch for this.
Actually the first patch doesn't work, it doesn't empty the fields. I trying this
diff --git a/js/conditional_fields.js b/js/conditional_fields.js
index 61e0bbd..b73d9be 100644
--- a/js/conditional_fields.js
+++ b/js/conditional_fields.js
@@ -70,6 +70,9 @@
if (e.effect) {
if (e.value) {
this.value = e.effect.value;
+ if (typeof e.effect.value === 'undefined') {
+ this.value = '';
+ }
} else if ($(this).data('conditionalFieldsSavedValue')) {
this.value = $(this).data('conditionalFieldsSavedValue');
}
Probably a better/different way to solve this maybe module maintainers know.
This was easier to do: https://www.drupal.org/project/civicrm_reroute_mail →
Thank you!!!
I merged the PR, and pushed to Drupal gitlab
Will be in beta6 soon!
if possible please make a PR against 4.0.x branch here: https://github.com/eileenmcnaughton/civicrm_entity/
I created a PR https://github.com/eileenmcnaughton/civicrm_entity/pull/514
This adds configuration settings to disable pre/post hooks per entity type.
Will be in 4.0.0-beta6
Fix for this in 4.0.0-beta5
This is merged and part of 4.0.0-beta5
Yes, we push from github to gitlab periodically as we feel ready. Soon to push a set of changes actually.
composer pulls from the d.o gitlab repo unless the developer specifies the github repo in the "repositories" section.
Primary development actually happens here: https://github.com/eileenmcnaughton/civicrm_entity/
That's where we accept PRs and code contributions.
I did change the default branch though.
@sadashiv
There is a setting to disable pre/post hooks on the settings page already.
I'm considering adding another to disable pre/post hooks if the entity type is not "enabled"
"Enabled" only means that CE provides Manage Fields, Manage Forms, Manage Display configurations for an entity type, and the possibility of Drupal based versions of add/edit/delete forms and view pages.
Pre / Post hooks fire to trigger Drupal based entity CRUD hooks/events, which some people may want. For instance Rules integration depends on this.
We're thinking this over.
This was resolved.
I resolved this via this change:
https://git.drupalcode.org/project/civicrm_entity_leaflet/-/commit/c90cf...
Added Drupal 11 support and require leaflet 10.2.25 in a new alpha3 release
Thanks for the heads up Seamus. Would you or JMA like to create a PR in the github repo https://github.com/eileenmcnaughton/civicrm_entity for the 4.0.x branch, and we'll review and think about it.
@nubeli
Can you provide me some instructions for setup to be equivalent to your instance?
Are you enabling French (France) here: /civicrm/admin/setting/localization?reset=1
Also French (Canada) ?
Any other configuration additional to default Civi setup?
Is your Drupal installation also setup as multi-lingual, and does that matter for CiviCRM or this case?
Afterwards, what path is it to set the translations for French (Canada) for an event?
Alan would you like to try this PR in combination with 497?
https://github.com/eileenmcnaughton/civicrm_entity/pull/502/files
The line causing the reported error came in here:
https://github.com/eileenmcnaughton/civicrm_entity/commit/f10bb4204fdd24...
https://github.com/eileenmcnaughton/civicrm_entity/pull/487
Thanks Alan, you said, "Before I added the patch 497, I was getting a different error. I wonder if that patch is incomplete in some way?"
Do you happen to have documented the error you were getting before applying the patch?
Well, we upgraded this module and the View config changed, and the View didn't update, so that's why the patch was needed. I guess people may find this, and could use the patch, if they want to keep the old View config
I made a patch that gets the logged in user's id and passes it to the url generation function. I can make another one with dependency injection if on the right track.
I've read the front page before. None of those methods work for my use case, its not nimble or specific enough.
I've patched this module and webform_civicrm to use drupal_static() to make a conditional decision on whether to allow config_readonly programmatic config updates for a very specific use case, for a particular .
This may evolve into a patch that could be used for general usage.
We've been thinking about it actually. The big thing that is missing is API3 had a "validate" action, of which I don't see any equivalent in API4.
We do think this does need to be done, and plan on chipping away at it over time.
Other than "validate" .. I don't think its a huge lift to just replace civicrm_api3() with civicrm_api4() calls, and then from there go through each entity type in detail looking for differences.
The guts are here: https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/CiviEn...
And most API calls use the CivicrmApi service.
https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/CiviCr...
So swapping out civicrm_api3() with civicrm_api4() calls is "easy" to do, to see what works, and what doesn't
If you happen to have or can get a backtrace, that could help diagnose this.
I'm going to guess the error is thrown from here: https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/Suppor...
But perhaps the entity type does get set there and no error, but later there is an error because its not a real entity type or has a matching database table.
Definitely this hasn't be tested, nor developed by Skvare:
https://docs.civicrm.org/user/en/latest/the-civicrm-community/localising...
perhaps its due to the change from fr_FR to fr_CA ..
Do tables / MySQL Views get created that include the fr_CA or are they all fr_FR in the database?
Noting other multi-lingual code:
https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/civicrm_en...
There were fixes in newer versions of the module, if you're still using beta1, I recommend upgrading to latest.
nginx fastcgi caching was the culprit. Nothing with this module wrong for this issue
Created PR for this. https://github.com/eileenmcnaughton/civicrm_entity/pull/489
Replicated the condition with Metatag 2.0
Similar fix was for viewing entities: https://github.com/eileenmcnaughton/civicrm_entity/pull/481/files
I dug into this a bit.
I found that the civicrm api call used to retrieve the contact values from the database, does not return addressee_custom in the result.
In Core, this function determines fields to exclude:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/BAO/Cont...
Normal CiviCRM API3 Contact.get calls are the same. So it would take something different than what we do to retrieve and populate this field.
It will work for saving a value from the /civicrm-contact/[id]/edit form, as the contact.create API accepts the value.
We could do a separate direct db query, or perhaps a DAO sql query, and then populate the values. This has been this way for a long long time, and this is the first request for it.
Thanks for reporting. The error is a symptom and not a one-line bug.
This is challenging.
https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/Entity...
That plugin works for simple things, but when conditions are condition groups, it does not.
I'm not aware of being able to do condition groups in CiviCRM APIv3
This maybe possible in a future update when we upgrade CiviCRM Entity to use APIv4, we haven't used APIv4 in this module yet. It maybe possible to attempt in only this plugin, and not modifying the API service, quicker
I'm calling this a feature request due to the complexity and effort of the solution.
If you need a solution for your site in the near term, I'd suggest not using the EntityQuery at all, but APIv4 Directly
https://docs.civicrm.org/dev/en/latest/api/v4/usage/
\Drupal::service('civicrm')->initialize();
// APIv4 code here
I've created a PR that will be included in a release shortly:
https://github.com/eileenmcnaughton/civicrm_entity/pull/488
We've made this module, works in D10 and now D11
https://www.drupal.org/project/civicrm_reroute_mail →
The MR was merged
MR is merged.
Confirmed the MR works with both 10.2.13 (before change) and 10.2.14 (after change)
I'm not sure how far back that fix will work for, the create() method we're adding to the extended object, from the original, has been in its current form for 4 years, other than the change from "static" to "self"
Should actually work for much older versions then.
I'm inclined to merge this MR
Merged, and this will be in next release
We've created a PR with this change in the github repo: https://github.com/eileenmcnaughton/civicrm_entity/pull/486
Good to reference this: https://civicrm.stackexchange.com/questions/39989/drupal-9-views-rich-te...
Should be able to rewrite the field value in Views, and use a twig "raw" filter
Replace "description__value__value" with the machine name of the Views field.
We merged this: https://github.com/eileenmcnaughton/civicrm_entity/pull/478
PR merged and will be included in 4.0.0-beta3
PR in Github has been created here: https://github.com/eileenmcnaughton/civicrm_entity/pull/477
Looking to merge and put in upcoming release
Made PR in github repo to run tests: https://github.com/eileenmcnaughton/civicrm_entity/pull/479
I'm looking to see if this change would cause problems in any older versions of CiviCRM.
Merged to 3.x and 4.0.x https://github.com/eileenmcnaughton/civicrm_entity/pull/476
PR Merged in github, going out in next release
I think this is a leaflet issue.
Leaflet integration was pulled out into a separate module:
https://www.drupal.org/project/civicrm_entity_leaflet →
Did a custom template recently and the custom fields were available and showed values when the template was rendered.
Views relationships from Events to price sets, then to price field, then to price field values entity types was made in the past and merged. This feature is supported now.
This was fixed with this PR: https://github.com/eileenmcnaughton/civicrm_entity/pull/371
PR was merged and is going out in new release soon.
I've seen this error in a number of situations. This error bubbles up if there is a CiviCRM error when CE invokes the alter entities hook. I've seen a number of different errors cause this, like missing extensions, a PHP compatibility bug in extensions.
There is nothing to fix in CE for this.