<p>It happens here (maybe intended, maybe a bug):</p>

<p><a href="https://github.com/craftcms/cms/tree/master-v2/src/controllers/UsersController.php#L1757" rel="nofollow noreferrer">https://github.com/craftcms/cms/tree/master-v2/src/controllers/UsersController.php#L1757</a></p>

<p>For news users <code>$groupIds</code> is an empty string, which means the expression <code>($groupIds !== null)</code> becomes true. At line 1780 <code>$groupIds</code> get passed to userGroups->assignUserToGroups() ... inside this method the <code>$groupIds</code> variable is casted to an array.</p>

<p>Eventually this overwrites the groups you've set by your onSaveUser event.</p>

<hr>

<p>Here is a (dirty) hack that works</p>

<pre><code>craft()-&gt;users-&gt;onSaveUser = function ($event) {

   craft()-&gt;userGroups-&gt;assignUserToGroups($user-&gt;id, $groupId);
   craft()-&gt;params['noGroupReset'] = true;           

};



craft()-&gt;userGroups-&gt;onBeforeAssignUserToGroups = function ($event) {

   $noGroupReset = (isset(craft()-&gt;params['noGroupReset']) &amp;&amp; craft()-&gt;params['noGroupReset'] === true);


   if (count($event-&gt;params['groupIds']) == 0 &amp;&amp; $noGroupReset) {
      $event-&gt;performAction = false; 
   } 

};
</code></pre>

CC BY-SA 3.0
2017-07-11T16:53:18.217Z
Thanks Oliver - that kinda makes  sense if not comfort :). 
It seems that $groupId can be set via onSaveuser from the front end, and I guess not overwriting the admins choices is a sound reason, but for new users maybe a check could be made. I cant really see a neat solution. Seems that general plugin development around saving users has quite a few gotchas. Thx
joomkit
CC BY-SA 3.0
2017-07-11T17:13:12.677Z
@joomkit I've added a workaround
Oliver Stark
CC BY-SA 3.0
2017-07-11T15:14:01.023Z
2018-02-21T23:45:13.543Z
2018-02-21T23:45:13.543Z
Oliver Stark
<p>I have a plugin that saves users into a registration group like:</p>

<pre><code> if (craft()-&gt;request-&gt;isSiteRequest()) {
  //etc 
  $groupId = '1';
  craft()-&gt;userGroups-&gt;assignUserToGroups($user-&gt;id, $groupId);
}
</code></pre>

<p>However if i listen for the user save event for the control panel:</p>

<pre><code>if (craft()-&gt;request-&gt;isCpRequest()) {
  //etc 
  $groupId = '1';
  craft()-&gt;userGroups-&gt;assignUserToGroups($user-&gt;id, $groupId);
}
</code></pre>

<p>This doesnt work. I also tried passing an array as groupId(s) but the group permission never gets ticked.</p>

<p>Is there another way of assigning a new user saved in the back end to a specific permission group?</p>

<users><permissions>
Save user group event in Control panel
# Save user group event in Control panel

(Asked by: username_0 on 2017-07-11)

I have a plugin that saves users into a registration group like:
 if (craft()->request->isSiteRequest()) {
  //etc 
  $groupId = '1';
  craft()->userGroups->assignUserToGroups($user->id, $groupId);
}

However if i listen for the user save event for the control panel:
if (craft()->request->isCpRequest()) {
  //etc 
  $groupId = '1';
  craft()->userGroups->assignUserToGroups($user->id, $groupId);
}

This doesnt work. I also tried passing an array as groupId(s) but the group permission never gets ticked.
Is there another way of assigning a new user saved in the back end to a specific permission group?

**Tags:** users, permissions

---

## 1 answers

### Answer by username_1 on 2017-07-11. Score: 2 | Accepted answer

It happens here (maybe intended, maybe a bug):
https://github.com/craftcms/cms/tree/master-v2/src/controllers/UsersController.php#L1757
For news users $groupIds is an empty string, which means the expression ($groupIds !== null) becomes true. At line 1780 $groupIds get passed to userGroups->assignUserToGroups() ... inside this method the $groupIds variable is casted to an array.
Eventually this overwrites the groups you've set by your onSaveUser event.

Here is a (dirty) hack that works
craft()->users->onSaveUser = function ($event) {

   craft()->userGroups->assignUserToGroups($user->id, $groupId);
   craft()->params['noGroupReset'] = true;           

};



craft()->userGroups->onBeforeAssignUserToGroups = function ($event) {

   $noGroupReset = (isset(craft()->params['noGroupReset']) && craft()->params['noGroupReset'] === true);


   if (count($event->params['groupIds']) == 0 && $noGroupReset) {
      $event->performAction = false; 
   } 

};

> **Comments:**
> **username_0**: Thanks Oliver - that kinda makes  sense if not comfort :).  It seems that $groupId can be set via onSaveuser from the front end, and I guess not overwriting the admins choices is a sound reason, but for new users maybe a check could be made. I cant really see a neat solution. Seems that general plugin development around saving users has quite a few gotchas. Thx  
> **username_1**: @joomkit I've added a workaround  

---

