Using Drupal 10.1.5, CiviCRM 5.66.2 and Drupal Webform 6.2.0-rc4, Webform CiviCRM 6.2.4 and CiviCRM Entity 4.0.0-alpha6

This may or may not be intended behaviour so asking the question here.

We have a form that users fill out and we widely use filters to improve usability on the autocomplete. e.g. If they are just choosing a sub contact type of 'School' only Schools are displayed. This has worked well for years.

This might be an edge case, but today a user could not enter a value, even though it existed on the database and was of the sub contact type that the filter was set on.

On investgation it turns out that this particular contact had two contact types against it; we'll call them 'type_a' and 'type_b'. The filter on the field was correctly set to contact type 'type_b'.

We use custom fields to capture certain types of information and occasionally two contacts may have more than one contact type against them, so it is something that is necessary for us.

My immediate work around has been to add these contacts to a Smart Group so that any created are added to this group by default regardless of what other contact types are assigned to them.

So is filtering on Contact Type 'by design' on a single type? I notice that it is possible to filter on multiple groups, but not multiple contact types, so perhaps that is what is intended? In our case, type_a comes before type_b when the contact is displayed (its alphabetical by the looks of it) and seems to take precedence - if I create a dummy field and filter on type_a, it works as intended. This implies whatever Contact Type is found first is the one that is used from a filtering perpective.

  • Were you getting any errors in drupal logs?
    – petednz - fuzion
    Nov 28, 2023 at 6:08
  • I've just run some tests locally and cleared the Drupal log. I enabled full logging with backtrace. Loading a webform that should have that field populated (the contact ID is supplied via a View in the URL) the field is just blank with -not found-. There are no errors, just warnings about an undefined array key "#allow_create". I seem to get this whether the field finds a match or not.
    – ChumKui
    Nov 30, 2023 at 9:52
  • Too many chars to fit i n one comment - However when I look at the contact record that has two contact types against it, the backtrace gives me CRM_Custom_Form_CustomData::preProcess message about using a deprecated seperator. No idea how all this hangs together but maybe causes issues further down the line. Having the backtrace on is hideous in terms of deprecation warnings!
    – ChumKui
    Nov 30, 2023 at 9:53
  • User deprecated function: Using a CRM_Core_DAO::VALUE_SEPARATOR separated subType deprecated, use a comma-separated string instead. Caller: CRM_Contact_Form_Contact::preProcess in CRM_Core_Error::deprecatedWarning() (line 1123 of /var/www/html/vendor/civicrm/civicrm-core/CRM/Core/Error.php). CRM_Core_Error::deprecatedWarning('Using a CRM_Core_DAO::VALUE_SEPARATOR separated subType deprecated, use a comma-separated string instead. Caller: CRM_Contact_Form_Contact::preProcess') (Line: 138)
    – ChumKui
    Nov 30, 2023 at 9:56


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.