Answers.Body: <p>For anyone's future benefit - this happens due to the fact I'm adding the user in the <code>sproutForms.saveEntry</code> hook. That happens after it messes around with the <code>fieldContext</code> and <code>contentTable</code> options for the Entry. As such, the user is getting saved to the wrong context, so it won't appear...</p>
  
  <p>A quick workaround for this is to move the following lines in <code>SproutForms_EntriesService.php:133-135</code> to lines 120. This resets the field context back before the hook is called.</p>
  
  <pre><code>if ($transaction !== null)
  {
      $transaction-&gt;commit();
  
      SproutFormsPlugin::log('Transaction committed');
  }
  
  // Reset our field context and content table to what they were previously
  craft()-&gt;content-&gt;fieldContext = $oldFieldContext;
  craft()-&gt;content-&gt;contentTable = $oldContentTable;
  
  Craft::import('plugins.sproutforms.events.SproutForms_OnSaveEntryEvent');
  
  $event = new SproutForms_OnSaveEntryEvent(
      $this, array(
          'entry'      =&gt; $entry,
          'isNewEntry' =&gt; $isNewEntry,
          'event'      =&gt; 'saveEntry',
          'entity'     =&gt; $entry,
      )
  );
  
  craft()-&gt;sproutForms-&gt;onSaveEntry($event);
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-28T17:03:29.193Z
Answers.Text: This has been fixed in Sprout Forms v1.0.1
Answers.UserDisplayName: Ben Parizek
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-07T00:51:04.763Z
Answers.LastActivityDate: 2015-05-07T00:51:04.763Z
Answers.UserDisplayName: crawf
Body: <p>I'm trying to programatically create a user (once the user submits a form through Sprout Forms). The user doesn't seem to appear in the Users section of the CP.</p>
  
  <p>I've ensured the user is being added correctly - I can even see a row in the craft_users database table. Going directly to admin/users/349 (the ID of the newly added user) shows all the user details.</p>
  
  <p>It's been suggested that I need to index the new element data - but not sure how to do this.</p>
  
  <pre><code>$content = $entry-&gt;getContent();
  
  $user = new UserModel();
  $user-&gt;username         = $content['email'];
  $user-&gt;email            = $content['email'];
  $user-&gt;unverifiedEmail  = $content['email'];
  $user-&gt;firstName        = $content['firstName'];
  $user-&gt;lastName         = $content['lastName'];
  $user-&gt;newPassword      = $content['password'];
  $user-&gt;pending          = true;
  
  $success = craft()-&gt;users-&gt;saveUser($user);
  
  if ($success) {
      craft()-&gt;search-&gt;indexElementAttributes($user);
  
      // Assign them to the default user group
      craft()-&gt;userGroups-&gt;assignUserToDefaultGroup($user);
  
      // Send the activation email
      craft()-&gt;users-&gt;sendActivationEmail($user);
  
      // Update the Element Index
      craft()-&gt;search-&gt;indexElementAttributes($user);
  }
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-05T19:16:30.120Z
Comments.Text: FWIW, `craft()->search->indexElementAttributes()` shouldn't be necessary here. If you look at the `id` column for the user in the `craft_users` table, do you have a matching `elementId` in `craft_elements_i18n` and `id` in `craft_elements`?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-05T23:13:22.160Z
Comments.Text: Hey Brad - yeah I didn't think I'd need it. I have a matching row in both `craft_elements_i18n` and `craft_elements`. Both have `enabled` set to 1.
Comments.UserDisplayName: crawf
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-05T23:44:36.130Z
Comments.Text: Probably worth glancing through `craft\app\controllers\UsersController->actionSaveUser()` just to make sure you're not missing a piece of info before `craft()->users->saveUser()` gets called.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-05T23:58:22.410Z
Comments.Text: @BradBell, yep, thats where I started. Will have another look through!
Comments.UserDisplayName: crawf
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-06T08:38:00.920Z
Comments.Text: @BradBell I've just copy/pasted the code from `actionSaveUser()`, even adding the private methods, and still the same result. Very strange. Are there any caches to be emptied or something?
Comments.UserDisplayName: crawf
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-06T23:09:33.620Z
Comments.Text: I just tried your example virtually line for line (minus `$content = $entry->getContent();` and `indexElementAttributes`) and it's working fine for me.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-07T00:44:03.687Z
Comments.Text: @BradBell - Ah, figured it out...
Comments.UserDisplayName: crawf
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-07T00:47:12.400Z
Comments.Text: Ahh... nice catch.  Probably worth adding as an official answer?
Comments.UserDisplayName: Brad Bell
Tags: <plugin-development><users>
Title: Programatically creating a user not appearing in Users index table
ThreadText: # Programatically creating a user not appearing in Users index table
  
  (Asked by: username_0 on 2015-05-05)
  
  I'm trying to programatically create a user (once the user submits a form through Sprout Forms). The user doesn't seem to appear in the Users section of the CP.
  
  I've ensured the user is being added correctly - I can even see a row in the craft\_users database table. Going directly to admin/users/349 (the ID of the newly added user) shows all the user details.
  
  It's been suggested that I need to index the new element data - but not sure how to do this.
  
  ```
  $content = $entry->getContent();
  
  $user = new UserModel();
  $user->username         = $content['email'];
  $user->email            = $content['email'];
  $user->unverifiedEmail  = $content['email'];
  $user->firstName        = $content['firstName'];
  $user->lastName         = $content['lastName'];
  $user->newPassword      = $content['password'];
  $user->pending          = true;
  
  $success = craft()->users->saveUser($user);
  
  if ($success) {
      craft()->search->indexElementAttributes($user);
  
      // Assign them to the default user group
      craft()->userGroups->assignUserToDefaultGroup($user);
  
      // Send the activation email
      craft()->users->sendActivationEmail($user);
  
      // Update the Element Index
      craft()->search->indexElementAttributes($user);
  }
  
  ```
  
  **Tags:** plugin-development, users
  
  > **Comments:**
  > **username_1**: FWIW, `craft()->search->indexElementAttributes()` shouldn't be necessary here. If you look at the `id` column for the user in the `craft_users` table, do you have a matching `elementId` in `craft_elements_i18n` and `id` in `craft_elements`?  
  > **username_0**: Hey username_1 - yeah I didn't think I'd need it. I have a matching row in both `craft_elements_i18n` and `craft_elements`. Both have `enabled` set to 1.  
  > **username_1**: Probably worth glancing through `craft\app\controllers\UsersController->actionSaveUser()` just to make sure you're not missing a piece of info before `craft()->users->saveUser()` gets called.  
  > **username_0**: @username_1, yep, thats where I started. Will have another look through!  
  > **username_0**: @username_1 I've just copy/pasted the code from `actionSaveUser()`, even adding the private methods, and still the same result. Very strange. Are there any caches to be emptied or something?  
  > **username_1**: I just tried your example virtually line for line (minus `$content = $entry->getContent();` and `indexElementAttributes`) and it's working fine for me.  
  > **username_0**: @username_1 - Ah, figured it out...  
  > **username_1**: Ahh... nice catch.  Probably worth adding as an official answer?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2015-05-07. Score: 2
  
  For anyone's future benefit - this happens due to the fact I'm adding the user in the `sproutForms.saveEntry` hook. That happens after it messes around with the `fieldContext` and `contentTable` options for the Entry. As such, the user is getting saved to the wrong context, so it won't appear...
  
  A quick workaround for this is to move the following lines in `SproutForms_EntriesService.php:133-135` to lines 120. This resets the field context back before the hook is called.
  
  ```
  if ($transaction !== null)
  {
      $transaction->commit();
  
      SproutFormsPlugin::log('Transaction committed');
  }
  
  // Reset our field context and content table to what they were previously
  craft()->content->fieldContext = $oldFieldContext;
  craft()->content->contentTable = $oldContentTable;
  
  Craft::import('plugins.sproutforms.events.SproutForms_OnSaveEntryEvent');
  
  $event = new SproutForms_OnSaveEntryEvent(
      $this, array(
          'entry'      => $entry,
          'isNewEntry' => $isNewEntry,
          'event'      => 'saveEntry',
          'entity'     => $entry,
      )
  );
  
  craft()->sproutForms->onSaveEntry($event);
  
  ```
  
  > **Comments:**
  > **username_2**: This has been fixed in Sprout Forms v1.0.1  
  
  ---
  
  