Body: <p>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</p>
  <p>This may or may not be intended behaviour so asking the question here.</p>
  <p>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.</p>
  <p>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.</p>
  <p>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'.</p>
  <p>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.</p>
  <p>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.</p>
  <p>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.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-11-28T06:08:25.957Z
Comments.Text: Were you getting any errors in drupal logs?
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-11-30T09:52:45.340Z
Comments.Text: 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.
Comments.UserDisplayName: ChumKui
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-11-30T09:53:23.007Z
Comments.Text: 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!
Comments.UserDisplayName: ChumKui
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-11-30T09:56:46.100Z
Comments.Text: 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)
Comments.UserDisplayName: ChumKui
Tags: <webform-civicrm>
Title: Drupal Webform Filter fails when a contact has more than one sub Contact Type against it
ThreadText: # Drupal Webform Filter fails when a contact has more than one sub Contact Type against it
  
  (Asked by: username_0 on 2023-11-10)
  
  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.
  
  **Tags:** webform-civicrm
  
  > **Comments:**
  > **username_1**: Were you getting any errors in drupal logs?  
  > **username_0**: 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.  
  > **username_0**: 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!  
  > **username_0**: 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)  
  
  ---
  
  ## 0 answers
  
  