<p>Turns out this was a bug in Craft that's been fixed for the next (<a href="http://buildwithcraft.com/updates#build2629" rel="nofollow">post 2.3.2629</a>) release.</p>

CC BY-SA 3.0
2015-02-11T20:29:21.117Z
2015-02-11T20:29:21.117Z
Brad Bell
<p>I've got a plugin which creates an entry on user activation. I'm trying to extend the plugin so that after public registration the account is not activated (i.e., force an Admin to activate the account).</p>

<p>According to the documentation I'd expect this code block to stop activation:</p>

<pre><code>public function init() {
    craft()-&gt;on('users.beforeActivateUser', function(Event $event){
        // stop the user from being able to activate their account. Forces admins to do so.
        //if($event-&gt;params['user']-&gt;isInGroup('artists')){
            $event-&gt;performAction = false;
        //}
    });
}
</code></pre>

<p>But it doesn't. What am I doing wrong? Full plugin code here: <a href="https://gist.github.com/MattWilcox/1549fb9d5787288b3b84" rel="nofollow">https://gist.github.com/MattWilcox/1549fb9d5787288b3b84</a></p>

CC BY-SA 3.0
2015-02-09T18:16:45.237Z
Looks O.K. to me and can't reproduce locally. If you have xDebug installed, throw a breakpoint on `$event->performAction = false` and step through it to see what's happening.
Brad Bell
CC BY-SA 3.0
2015-02-10T09:14:20.037Z
I don't have that installed :/

Can I confirm I'm understanding what it should do correctly? It is creating the user after registration as Active (green) but with the code above it *does* stop the plugin's 'onActivateUser' block from running (and so no entry is created for the new user).

I expected it to not have a green active user immediately on registration due to that code above. If I set email validation as required, the user remains pending (orange). That's what I want (but without the email being required).
Matt Wilcox
CC BY-SA 3.0
2015-02-11T04:49:32.820Z
Yeah... kinda sounds like a bug. Will do some testing and update here with the results.
Brad Bell
CC BY-SA 3.0
2015-02-11T09:00:54.097Z
Thanks Brad, let me know if you'd like the file/database dump. Sorry I can't help track this down further; my PHP-foo is old and weak.
Matt Wilcox
CC BY-SA 3.0
2015-02-12T07:20:47.933Z
Per [Brad's comment](http://craftcms.stackexchange.com/a/7125/45), this is a bug and has been fixed for the next release. Closing as a bug report.
Lindsey D
<plugin-development><activation>
$event->performAction = false; doesn't stop action
# $event->performAction = false; doesn't stop action

(Asked by: username_0 on 2015-02-09)

I've got a plugin which creates an entry on user activation. I'm trying to extend the plugin so that after public registration the account is not activated (i.e., force an Admin to activate the account).
According to the documentation I'd expect this code block to stop activation:
public function init() {
    craft()->on('users.beforeActivateUser', function(Event $event){
        // stop the user from being able to activate their account. Forces admins to do so.
        //if($event->params['user']->isInGroup('artists')){
            $event->performAction = false;
        //}
    });
}

But it doesn't. What am I doing wrong? Full plugin code here: https://gist.github.com/MattWilcox/1549fb9d5787288b3b84

**Tags:** plugin-development, activation
> **Comments:**
> **username_1**: Looks O.K. to me and can't reproduce locally. If you have xDebug installed, throw a breakpoint on `$event->performAction = false` and step through it to see what's happening.  
> **username_0**: I don't have that installed :/  Can I confirm I'm understanding what it should do correctly? It is creating the user after registration as Active (green) but with the code above it *does* stop the plugin's 'onActivateUser' block from running (and so no entry is created for the new user).  I expected it to not have a green active user immediately on registration due to that code above. If I set email validation as required, the user remains pending (orange). That's what I want (but without the email being required).  
> **username_1**: Yeah... kinda sounds like a bug. Will do some testing and update here with the results.  
> **username_0**: Thanks Brad, let me know if you'd like the file/database dump. Sorry I can't help track this down further; my PHP-foo is old and weak.  
> **username_2**: Per [Brad's comment](http://craftcms.stackexchange.com/a/7125/45), this is a bug and has been fixed for the next release. Closing as a bug report.  

---

## 1 answers

### Answer by username_1 on 2015-02-11. Score: 2 | Accepted answer

Turns out this was a bug in Craft that's been fixed for the next ([post 2.3.2629](http://buildwithcraft.com/updates#build2629)) release.


---

