Answers.Body: <p>The issue was, as Demerit rightly pointed out (thank you!) to do with Drush running as a user that did not have the privileges to create a submission for my particular webform.  The form was not a simple one, involving several contacts, a case and an activity all with custom fields.</p>
  <p>The solution, a total hack, was to elevate the Anonymous user by temporarily granting the following permissions:</p>
  <pre><code>CiviCRM: all CiviCRM permissions and ACLs
  Administer and use CiviCRM bypassing any other permission or ACL checks and enabling the creation of displays and forms that allow others to bypass checks. This permission should be given out with care
  </code></pre>
  <p>Clearly this is a very dangerous thing to do and you should not leave this on a production system or one exposed to the open internet.  The solution is to lock the site behind HTTP Auth and or put the site into Maintenance Mode to do your import, then immediately remove this permission when you have done your import.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-25T13:29:51.737Z
Answers.LastActivityDate: 2023-07-25T13:29:51.737Z
Answers.UserDisplayName: ChumKui
Answers.Body: <p>If you are running drush as anonymous civi won't have a source_contact it can use. As noted in comments it seems with recent drush versions you can no longer set a user id, but all drush commands are equivalent to just calling some function in the code. For this one it looks like it's</p>
  <p><code>\Drupal::service(&quot;webform.cli_service&quot;)-&gt;drush_webform_import($webform_id, $path_to_csv, [array of options]);</code></p>
  <p>so you can use <code>drush ev</code> to first set a user, then call that function, e.g.</p>
  <p><code>drush ev '\Drupal::service(&quot;account_switcher&quot;)-&gt;switchTo(new \Drupal\Core\Session\UserSession([&quot;uid&quot; =&gt; 1])); \Drupal::service(&quot;webform.cli_service&quot;)-&gt;drush_webform_import($webform_id, $path_to_csv, [array of options]);'</code></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-21T17:21:14.603Z
Answers.Text: Thanks Demerit, I'm definitely running as anon.  Tried your suggestion but I'm getting  'The "--uid" option does not exist'  - running Drush version 10.6.2.  I did not think you could run Drush with a user anymore?  I know I've done it on D7 in the past (--user=[username]) , but rarely have had to use it.
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-21T18:22:54.683Z
Answers.Text: Oh that's weird. Ok will update answer.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-24T10:07:24.367Z
Answers.Text: HI Demerit - so close...  So in summary it fails with 'The "entity-type" option does not exist'. Thanks for this as an admin/needs must developer, it is great to be introduced to the lower level of Drush and how it can be used.  I ended up using the debugger, not a natural country for me.  It fails at line 427  - $entity_type = $this->drush_get_option('entity-type'), but stepping in, ultimately fails on a Symphony getOption($name), where $name = entity-type.  A bit low-level for me all this, but nearly there? I've learned a lot along the way.  Many thanks again.
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-24T15:19:08.143Z
Answers.Text: Ok not sure. Maybe for some reason it needs `--entity-type` specified on the command line?
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-25T10:01:48.917Z
Answers.Text: Have tried but cannot see a way of adding this parameter! It might be a red herring in any case as if I run a plain wfi it goes past the point it was failing on with the ev command, but still ultimately ends up with the same error.  I'll report an issue as it is a bit of a limitation for anything connected with CiviCRM if you need to run Drush in this way!
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-25T13:22:08.577Z
Answers.Text: It is definately a permissions issue - if I allow anonymous users access to CiviCRM with elevated permissions, the import works.  I have raised an issue for the webform module (https://www.drupal.org/project/webform/issues/3376837).  Non dev users would definately not want ot start to create custom modules to do this sort of thing.
Answers.UserDisplayName: ChumKui
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-21T16:43:35.173Z
Answers.LastActivityDate: 2023-07-21T18:25:45.637Z
Answers.LastEditDate: 2023-07-21T18:25:45.637Z
Answers.UserDisplayName: Demerit
Body: <p>I am converting D7 webforms for D9 and importing data (latest webform 6.1.x and Drupal 9.5.x, CiviCRM 5.63.1).</p>
  <p>To do a basic test I created an import file with a single entry and used the UI to import, treating all warnings as errors to be sure. This was successful (thanks Jacob Rockowitz for the video on this <a href="https://www.youtube.com/watch?v=AYGr4O-jZBo" rel="nofollow noreferrer">Import Webform Submission</a>)</p>
  <p>The forms are linked to CiviCRM.</p>
  <p>I have a fair few to import so switched to the command line to avoid any time out issues and I can also script this way.  I ran into a strange problem where an identical import fails using the CLI.</p>
  <pre><code>Drush webform:import myform /my_path/my_file
  </code></pre>
  <p>If I swtich back to the UI all 100 were imported without issue? The submissions look OK in the UI and I checked a few at random against the current D7 system and they are fine. All I see in the dblog is a load of warnings about unserialize(), but that's it.</p>
  <p>Here is what I am seeing when I try to use the CLI:</p>
  <p><a href="https://i.sstatic.net/PKXTt.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/PKXTt.png" alt="Command line output" /></a></p>
  <p>Here is an example of one of the numerous deprecated function debug messages (I am using PHP 8.1 so that's probably it):</p>
  <p><a href="https://gist.github.com/chumkui/59d56ccdbc2aaa3c3fef78204e52e9f0" rel="nofollow noreferrer">Deprecated function warning</a></p>
  <p>Just in case, I have experimented with using --treat_warnings_as_errors and --skip_validation to no effect.</p>
  <p>I can do it all via the UI, but would rather not!  Any thoughts on this welcome.</p>
  
Tags: <webform-civicrm>
Title: Webform import command line fails but import via UI is OK?
ThreadText: # Webform import command line fails but import via UI is OK?
  
  (Asked by: username_0 on 2023-07-21)
  
  I am converting D7 webforms for D9 and importing data (latest webform 6.1.x and Drupal 9.5.x, CiviCRM 5.63.1).
  To do a basic test I created an import file with a single entry and used the UI to import, treating all warnings as errors to be sure. This was successful (thanks Jacob Rockowitz for the video on this Import Webform Submission)
  The forms are linked to CiviCRM.
  I have a fair few to import so switched to the command line to avoid any time out issues and I can also script this way.  I ran into a strange problem where an identical import fails using the CLI.
  Drush webform:import myform /my_path/my_file
  
  If I swtich back to the UI all 100 were imported without issue? The submissions look OK in the UI and I checked a few at random against the current D7 system and they are fine. All I see in the dblog is a load of warnings about unserialize(), but that's it.
  Here is what I am seeing when I try to use the CLI:
  
  Here is an example of one of the numerous deprecated function debug messages (I am using PHP 8.1 so that's probably it):
  Deprecated function warning
  Just in case, I have experimented with using --treat_warnings_as_errors and --skip_validation to no effect.
  I can do it all via the UI, but would rather not!  Any thoughts on this welcome.
  
  **Tags:** webform-civicrm
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2023-07-25. Score: 3 | Accepted answer
  
  The issue was, as username_1 rightly pointed out (thank you!) to do with Drush running as a user that did not have the privileges to create a submission for my particular webform.  The form was not a simple one, involving several contacts, a case and an activity all with custom fields.
  The solution, a total hack, was to elevate the Anonymous user by temporarily granting the following permissions:
  CiviCRM: all CiviCRM permissions and ACLs
  Administer and use CiviCRM bypassing any other permission or ACL checks and enabling the creation of displays and forms that allow others to bypass checks. This permission should be given out with care
  
  Clearly this is a very dangerous thing to do and you should not leave this on a production system or one exposed to the open internet.  The solution is to lock the site behind HTTP Auth and or put the site into Maintenance Mode to do your import, then immediately remove this permission when you have done your import.
  
  
  ---
  
  ### Answer by username_1 on 2023-07-21. Score: 1
  
  If you are running drush as anonymous civi won't have a source\_contact it can use. As noted in comments it seems with recent drush versions you can no longer set a user id, but all drush commands are equivalent to just calling some function in the code. For this one it looks like it's
  
  `\Drupal::service("webform.cli_service")->drush_webform_import($webform_id, $path_to_csv, [array of options]);`
  
  so you can use `drush ev` to first set a user, then call that function, e.g.
  
  `drush ev '\Drupal::service("account_switcher")->switchTo(new \Drupal\Core\Session\UserSession(["uid" => 1])); \Drupal::service("webform.cli_service")->drush_webform_import($webform_id, $path_to_csv, [array of options]);'`
  
  > **Comments:**
  > **username_0**: Thanks username_1, I'm definitely running as anon.  Tried your suggestion but I'm getting  'The "--uid" option does not exist'  - running Drush version 10.6.2.  I did not think you could run Drush with a user anymore?  I know I've done it on D7 in the past (--user=[username]) , but rarely have had to use it.  
  > **username_1**: Oh that's weird. Ok will update answer.  
  > **username_0**: HI username_1 - so close...  So in summary it fails with 'The "entity-type" option does not exist'. Thanks for this as an admin/needs must developer, it is great to be introduced to the lower level of Drush and how it can be used.  I ended up using the debugger, not a natural country for me.  It fails at line 427  - $entity_type = $this->drush_get_option('entity-type'), but stepping in, ultimately fails on a Symphony getOption($name), where $name = entity-type.  A bit low-level for me all this, but nearly there? I've learned a lot along the way.  Many thanks again.  
  > **username_1**: Ok not sure. Maybe for some reason it needs `--entity-type` specified on the command line?  
  > **username_0**: Have tried but cannot see a way of adding this parameter! It might be a red herring in any case as if I run a plain wfi it goes past the point it was failing on with the ev command, but still ultimately ends up with the same error.  I'll report an issue as it is a bit of a limitation for anything connected with CiviCRM if you need to run Drush in this way!  
  > **username_0**: It is definately a permissions issue - if I allow anonymous users access to CiviCRM with elevated permissions, the import works.  I have raised an issue for the webform module (https://www.drupal.org/project/webform/issues/3376837).  Non dev users would definately not want ot start to create custom modules to do this sort of thing.  
  
  ---
  
  