Answers.Body: <p>OK - it was data related.  I had a case type that had an additional role defined but for some reason was not visible on the UI.  When I used the API explorer to view all details of the case type, there was an additional 'caseRole' defined, but it was not visible.  I have no idea how the data came to be in that state, but I am guessing that when the list of case types is generated on the form, it goes looking for the relationships, cannot find it and this causes the issue.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-04-11T16:09:04.137Z
Answers.LastActivityDate: 2022-04-11T16:09:04.137Z
Answers.UserDisplayName: ChumKui
Answers.Body: <p>Our automated testing builds D9 x 5 versions of CiviCRM on every push/PR/merge -&gt; here are the details of the build:</p>
  <p><a href="https://github.com/colemanw/webform_civicrm/blob/6.x/.github/workflows/main.yml" rel="nofollow noreferrer">https://github.com/colemanw/webform_civicrm/blob/6.x/.github/workflows/main.yml</a></p>
  <p>Note automated tests include Existing Contact element lookups. So your D9/CiviCRM set up is either missing something or something is running interference.</p>
  <p>Have a good look at that main.yml file to spot any differences with your composer config/set up.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-04-10T19:51:08.143Z
Answers.Text: Much appreciated- I’ll take a look at my settings and also try from a blank database with test contacts i case it is somehow data related. Everything seems fine data wise in production, but you never know.
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-04-11T14:48:30.417Z
Answers.Text: Hi Karin - I have made progress, it appears to be data related (worrying...) I did a completely fresh install using demo data and all is fine when I set the form for one case.  The moment I use my own data, setting a form to using a single case causes a crash with the same error (Expected one RelationshipType but found 0).  I disabled all my own case types and enabled Housing Support and it works... I'll keep digging
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-04-11T15:43:58.910Z
Answers.Text: Tracked it down to one particular case type, if it is enabled, setting the the number of Cases from 0 on the form to 1 causes nothing to be displayed (normally you get the drop down of Case types to choose from) and an error in the logs of 'CiviCRM_API3_Exception: Expected one RelationshipType but found 0 in civicrm_api3() (line 135 of /var/www/html/vendor/civicrm/civicrm-core/api/api.php).'  Saving and using the form will cause a crash. Any ideas greatly appreciated!
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-04-11T18:40:21.240Z
Answers.Text: Ah ok - good work! So is this Case Type a custom one? I checked our automated tests for Case Type we’re just using a native one (Housing Support) at this point -> https://github.com/colemanw/webform_civicrm/blob/6.x/tests/src/FunctionalJavascript/CaseSubmissionTest.php
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-04-11T20:06:28.270Z
Answers.Text: Yes it is a custom case and clearly the data has been corrupted in some way. That’s a job for this week (…) but the main thing is I can continue the build in D9 and learn the new webform. Thanks for providing us all with a fabulous module, I’m looking forward to seeing what more we can do with it.
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-04-11T21:29:14.257Z
Answers.Text: Best of luck! I hope you figure out what went sideways with your custom case type.
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-04-09T14:28:23.940Z
Answers.LastActivityDate: 2022-04-09T14:28:23.940Z
Answers.UserDisplayName: KarinG - Semper IT
Body: <p>I am asking this question before I raise an issue in the hope that this a simple config problem - my simple testing has shown such fragility, it must be my end!</p>
  <p>I've started the journey to port our CiviCRM on Drupal 7 to Drupal 9.  All has gone really well (the porting guides are great)  - everything basically 'works' and yesterday I got to looking at the forms.  Reading, it seemed like the best approach was to just recreate the existing Drupal webforms that were integrated using webform_civicrm - this way you learn the new Webform approach and clear out the stuff the you do not need.</p>
  <p>I created the simplest of forms by duping the template Contact form and then trying to add an 'existing contact' and a single Case to it - it immediately crashed:</p>
  <p><code>The website encountered an unexpected error. Please try again later.</code></p>
  <p>The log message was:</p>
  <p><code>CiviCRM_API3_Exception: Expected one RelationshipType but found 0 in civicrm_api3() (line 135 of /var/www/html/vendor/civicrm/civicrm-core/api/api.php).</code></p>
  <p>I've played around, using no template, using another template etc and also get other crashes at various points:</p>
  <p><code>Drupal\Component\Plugin\Exception\PluginException: Plugin (webform_location_places) instance class &quot;Drupal\webform\Plugin\WebformElement\WebformLocationPlaces&quot; does not exist. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 97 of /var/www/html/web/core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php).</code></p>
  <p>This sort of stuff is in the logs:</p>
  <p><code>Notice: Undefined index: #form_key in Drupal\webform_civicrm\Plugin\WebformElement\CivicrmContact-&gt;wf_crm_contact_fields() (line 464 of /var/www/html/web/modules/contrib/webform_civicrm/src/Plugin/WebformElement/CivicrmContact.php) </code></p>
  <p>The thing is I'm not trying (yet!) to do anything tricky. On Drupal 7 I use Webform extensively to create and update cases and activities and have never seen these types of crashes.  Just want to know if there is any fragility I should be aware of, or an approach where you must do X first then Y if using the integration?</p>
  <p>Drupal 9.3.9 with CiviCRM 5.48</p>
  <p>In the composer file (I believe as recommended):</p>
  <p>&quot;drupal/webform&quot;:&quot;^6.2@beta&quot; with &quot;drupal/webform_civicrm&quot;: &quot;^6.2.0&quot; and &quot;wikimedia/composer-merge-plugin&quot;: &quot;^2.0&quot;</p>
  <p>Many thanks</p>
  
Tags: <webform-civicrm><forms>
Title: webform_civicrm on Drupal 9 issue with case type
ThreadText: # webform_civicrm on Drupal 9 issue with case type
  
  (Asked by: username_0 on 2022-04-09)
  
  I am asking this question before I raise an issue in the hope that this a simple config problem - my simple testing has shown such fragility, it must be my end!
  
  I've started the journey to port our CiviCRM on Drupal 7 to Drupal 9. All has gone really well (the porting guides are great) - everything basically 'works' and yesterday I got to looking at the forms. Reading, it seemed like the best approach was to just recreate the existing Drupal webforms that were integrated using webform\_civicrm - this way you learn the new Webform approach and clear out the stuff the you do not need.
  
  I created the simplest of forms by duping the template Contact form and then trying to add an 'existing contact' and a single Case to it - it immediately crashed:
  
  `The website encountered an unexpected error. Please try again later.`
  
  The log message was:
  
  `CiviCRM_API3_Exception: Expected one RelationshipType but found 0 in civicrm_api3() (line 135 of /var/www/html/vendor/civicrm/civicrm-core/api/api.php).`
  
  I've played around, using no template, using another template etc and also get other crashes at various points:
  
  `Drupal\Component\Plugin\Exception\PluginException: Plugin (webform_location_places) instance class "Drupal\webform\Plugin\WebformElement\WebformLocationPlaces" does not exist. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 97 of /var/www/html/web/core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php).`
  
  This sort of stuff is in the logs:
  
  `Notice: Undefined index: #form_key in Drupal\webform_civicrm\Plugin\WebformElement\CivicrmContact->wf_crm_contact_fields() (line 464 of /var/www/html/web/modules/contrib/webform_civicrm/src/Plugin/WebformElement/CivicrmContact.php)`
  
  The thing is I'm not trying (yet!) to do anything tricky. On Drupal 7 I use Webform extensively to create and update cases and activities and have never seen these types of crashes. Just want to know if there is any fragility I should be aware of, or an approach where you must do X first then Y if using the integration?
  
  Drupal 9.3.9 with CiviCRM 5.48
  
  In the composer file (I believe as recommended):
  
  "drupal/webform":"^6.2@beta" with "drupal/webform\_civicrm": "^6.2.0" and "wikimedia/composer-merge-plugin": "^2.0"
  
  Many thanks
  
  **Tags:** webform-civicrm, forms
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2022-04-11. Score: 1
  
  OK - it was data related. I had a case type that had an additional role defined but for some reason was not visible on the UI. When I used the API explorer to view all details of the case type, there was an additional 'caseRole' defined, but it was not visible. I have no idea how the data came to be in that state, but I am guessing that when the list of case types is generated on the form, it goes looking for the relationships, cannot find it and this causes the issue.
  
  
  ---
  
  ### Answer by username_1 on 2022-04-09. Score: 0
  
  Our automated testing builds D9 x 5 versions of CiviCRM on every push/PR/merge -> here are the details of the build:
  
  <https://github.com/colemanw/webform_civicrm/blob/6.x/.github/workflows/main.yml>
  
  Note automated tests include Existing Contact element lookups. So your D9/CiviCRM set up is either missing something or something is running interference.
  
  Have a good look at that main.yml file to spot any differences with your composer config/set up.
  
  > **Comments:**
  > **username_0**: Much appreciated- I’ll take a look at my settings and also try from a blank database with test contacts i case it is somehow data related. Everything seems fine data wise in production, but you never know.  
  > **username_0**: Hi Karin - I have made progress, it appears to be data related (worrying...) I did a completely fresh install using demo data and all is fine when I set the form for one case.  The moment I use my own data, setting a form to using a single case causes a crash with the same error (Expected one RelationshipType but found 0).  I disabled all my own case types and enabled Housing Support and it works... I'll keep digging  
  > **username_0**: Tracked it down to one particular case type, if it is enabled, setting the the number of Cases from 0 on the form to 1 causes nothing to be displayed (normally you get the drop down of Case types to choose from) and an error in the logs of 'CiviCRM_API3_Exception: Expected one RelationshipType but found 0 in civicrm_api3() (line 135 of /var/www/html/vendor/civicrm/civicrm-core/api/api.php).'  Saving and using the form will cause a crash. Any ideas greatly appreciated!  
  > **username_1**: Ah ok - good work! So is this Case Type a custom one? I checked our automated tests for Case Type we’re just using a native one (Housing Support) at this point -> https://github.com/colemanw/webform_civicrm/blob/6.x/tests/src/FunctionalJavascript/CaseSubmissionTest.php  
  > **username_0**: Yes it is a custom case and clearly the data has been corrupted in some way. That’s a job for this week (…) but the main thing is I can continue the build in D9 and learn the new webform. Thanks for providing us all with a fabulous module, I’m looking forward to seeing what more we can do with it.  
  > **username_1**: Best of luck! I hope you figure out what went sideways with your custom case type.  
  
  ---
  
  