🇺🇸United States @markusa

This is merged and included in the 4.0.1 release

Ok this feature is reviewed and merged, included in 4.0.1 just released

Yes the permission problem can be avoided with a different View construction.
If you have a base table of Addresses, (or contacts with a relationship to Address)
and you add the "State/Province ID" field to the View, what this is adding the field handler for an Entity Reference field, and likely you're outputing the entity label, which is the State/Province name.
Outputting the label counts as "Rendering the entity" .. and anytime you render the entity then access control rules apply.
You'll find that if you output only the ID that you won't have the problem with the value not appearing.

So it is possible to add a Views Relationship "CiviCRM State/Province" to the View.

Now you will be able to add the "State Name" field which uses that relationship you added.

Since this is just outputting the field value, and not "Rendering the entity" then the access control rule doesn't apply.

Example:

langcode: en
status: true
dependencies:
  module:
    - civicrm_entity
id: address_demo
label: 'Address Demo'
module: views
description: ''
tag: ''
base_table: civicrm_address
base_field: id
display:
  default:
    id: default
    display_title: Default
    display_plugin: default
    position: 0
    display_options:
      fields:
        name_1:
          id: name_1
          table: civicrm_state_province
          field: name
          relationship: state_province_id
          group_type: group
          admin_label: ''
          entity_type: civicrm_state_province
          entity_field: name
          plugin_id: field
          label: ''
          exclude: false
          alter:
            alter_text: false
            text: ''
            make_link: false
            path: ''
            absolute: false
            external: false
            replace_spaces: false
            path_case: none
            trim_whitespace: false
            alt: ''
            rel: ''
            link_class: ''
            prefix: ''
            suffix: ''
            target: ''
            nl2br: false
            max_length: 0
            word_boundary: true
            ellipsis: true
            more_link: false
            more_link_text: ''
            more_link_path: ''
            strip_tags: false
            trim: false
            preserve_tags: ''
            html: false
          element_type: ''
          element_class: ''
          element_label_type: ''
          element_label_class: ''
          element_label_colon: false
          element_wrapper_type: ''
          element_wrapper_class: ''
          element_default_classes: true
          empty: ''
          hide_empty: false
          empty_zero: false
          hide_alter_empty: true
          click_sort_column: value
          type: string
          settings: {  }
          group_column: value
          group_columns: {  }
          group_rows: true
          delta_limit: 0
          delta_offset: 0
          delta_reversed: false
          delta_first_last: false
          multi_type: separator
          separator: ', '
          field_api_classes: false
      pager:
        type: mini
        options:
          offset: 0
          pagination_heading_level: h4
          items_per_page: 10
          total_pages: null
          id: 0
          tags:
            next: ››
            previous: ‹‹
          expose:
            items_per_page: false
            items_per_page_label: 'Items per page'
            items_per_page_options: '5, 10, 25, 50'
            items_per_page_options_all: false
            items_per_page_options_all_label: '- All -'
            offset: false
            offset_label: Offset
      exposed_form:
        type: basic
        options:
          submit_button: Apply
          reset_button: false
          reset_button_label: Reset
          exposed_sorts_label: 'Sort by'
          expose_sort_order: true
          sort_asc_label: Asc
          sort_desc_label: Desc
      access:
        type: none
        options: {  }
      cache:
        type: tag
        options: {  }
      empty: {  }
      sorts: {  }
      arguments: {  }
      filters: {  }
      style:
        type: default
        options:
          grouping: {  }
          row_class: ''
          default_row_class: true
          uses_fields: false
      row:
        type: fields
        options:
          default_field_elements: true
          inline: {  }
          separator: ''
          hide_empty: false
      query:
        type: views_query
        options:
          query_comment: ''
          disable_sql_rewrite: false
          distinct: false
          replica: false
          query_tags: {  }
      relationships:
        state_province_id:
          id: state_province_id
          table: civicrm_address
          field: state_province_id
          relationship: none
          group_type: group
          admin_label: 'CiviCRM State/Province'
          entity_type: civicrm_address
          entity_field: state_province_id
          plugin_id: standard
          required: false
      header: {  }
      footer: {  }
      display_extenders: {  }
    cache_metadata:
      max-age: -1
      contexts:
        - 'languages:language_content'
        - 'languages:language_interface'
        - url.query_args
      tags: {  }

One way to get these in Views is to make a Relationship and then add the state/country name field via the Relationship.

We've often done a small custom

/**
 * Implements hook_civicrm_alter_drupal_entities().
 */
function civicrm_tweaks_civicrm_alter_drupal_entities(&$civicrm_entity_info) {
  $civicrm_entity_info['civicrm_country']['permissions']['view'] = ['access content'];
  $civicrm_entity_info['civicrm_state_province']['permissions']['view'] = ['access content'];
}

Good argument with the permissions matching the API permissions .. makes sense.

Do you mind making a PR against the 4.0.x branch on github?

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

We have tests that run there, legacy of pre-Drupal-gitlab, and hadn't had the motivation to move here yet.

For feedback for this contribution, this is great!! Thank you.

I couple of things .. can you add PHP Attributes for the Plugins ?
We are trying to make new code as forward looking as possible.
Its a one line addition, example here: https://github.com/eileenmcnaughton/civicrm_entity/blob/4.0.x/src/Plugin...

I don't see any other issues, but I'll test when there's a PR. Thanks again!

We are aware of performance issue when there are alot of custom fields

We have a prototype PR : https://github.com/eileenmcnaughton/civicrm_entity/pull/531

But it is a draft and incomplete, and some features with Views fields/filters for custom fields may not work.

All the descriptions for Views relationships, etc.. are autogenerated via metadata gathered by the CiviCRM API.
This is nothing coded into CiviCRM Entity

You can look into contributing translations to CiviCRM
https://lab.civicrm.org/dev/translation/-/wikis/home

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.

markusa → created an issue.

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.

markusa → created an issue.

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.

markusa → created an issue.

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

markusa → created an 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.

markusa → created an issue.

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.

markusa → created an issue.

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

markusa → created an issue.

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.