Setting Permissions Not Working

[Shaun Mason]

I am running XenForo Beta 5 on my site live. When a new member registers, they are placed in the "Registered" user group. I have the forum restricted so you have to post an application and have it approved before you can post everywhere.

When that approval occurs, someone changes the members permission group to "Approved".

What is occurring is in the 'xf_user' table the 'user_group_id' field is set appropriately, but the 'display_style_group_id' and 'permission_combination' fields are not being set to the same value.

AFAIK, this is new since Beta 5, or perhaps is related to an Add-On.

Anyone have any ideas before I start digging through the code?

 

[Paul B]

Are you moving them from the Registered group to the Approved group, or just adding the Approved group as a secondary?

 

[Jake Bunce]

When you moderate new accounts the system doesn't change their usergroup. Rather it sets the user_state field. You can edit a user in the Admin CP to see this field:



When you approve a user through normal means:

Admin CP -> Users -> Users Awaiting Approval

...then it changes their user_state to Valid. But it sounds like you are shortcutting this process and changing their group manually while the user_state is still Awaiting Approval. The user will have guest permissions (regardless of their group) until their user_state is changed. I think that is the nature of your problem.

 

[Shaun Mason]

When you moderate new accounts the system doesn't change their usergroup. Rather it sets the user_state field. You can edit a user in the Admin CP to see this field:

View attachment 8036

When you approve a user through normal means:

Admin CP -> Users -> Users Awaiting Approval

...then it changes their user_state to Valid. But it sounds like you are shortcutting this process and changing their group manually while the user_state is still Awaiting Approval. The user will have guest permissions (regardless of their group) until their user_state is changed. I think that is the nature of your problem.

Jake,

I actually have email confirmations OFF, so as soon as they register they are set to user_state = Valid. I do not have approval enabled, because I want them to post once (an application to be reviewed) before they are accepted.

 

[Shaun Mason]

Are you moving them from the Registered group to the Approved group, or just adding the Approved group as a secondary?

I am moving them from Registered to Approved via the main combo box in admin.php?users/username.user_id/edit screen.

 

[Paul B]

I just tested it with a test user on my local install (Beta 5).

Originally they were in the Registered users group:
user_group_id 2
display_style_group_id 2
permission_combination_id 2

I then changed their primary group to a new Premium users group and the fields updated to:
user_group_id 6
display_style_group_id 6
permission_combination_id 17

Changing their primary group reset all fields back to 2.

I'm not seeing the problem with my install.

 

[Jake Bunce]

In that case what is the problem you are having?

What is occurring is in the 'xf_user' table the 'user_group_id' field is set appropriately, but the 'display_style_group_id' and 'permission_combination' fields are not being set to the same value.

Is there a problem on the forum that leads you to believe those database fields are to blame? Are there steps to reproduce the problem?

 

[Shaun Mason]

In that case what is the problem you are having?



Is there a problem on the forum that leads you to believe those database fields are to blame? Are there steps to reproduce the problem?

I'll walk you through our approval flow.

1. User registers and are assigned the 'Registered' usergroup. This usergroup is restricted to posting in a forum called 'New Member Lounge'
2. User posts and submitts an application. If they are approved, the moderator goes to the Admin CP and changes their usergroup from 'Registered' to 'Approved'.

The issue occurs when this happens. The user can still post in the 'New Member Lounge' but no where else (effectively the still have 'Registered' permissions). On investigation, I found that when the user is saved, it DOES change the 'user_group_id' field, so they show up as 'Approved', but the 'permission_combination' field is still consistent with a 'Registered' member.

It happens everytime we approve someone, the only way I can fix it is by manually updating the tables via MySQL. I'm not sure if something occured when I upgraded to Beta 5, or if it is Add-On related, because I have installed a few since the upgrade.

 

[Jake Bunce]

I can't reproduce this on my test forum. In my testing the xf_user.permission_combination_id field does update when I change a user's group.

Yes, it could be an addon. It is worth troubleshooting that.

Admin CP -> Home -> List Add-ons -> Disable (in the Control menu for each addon)

 

[Shaun Mason]

I can't reproduce this on my test forum. In my testing the xf_user.permission_combination_id field does update when I change a user's group.

Yes, it could be an addon. It is worth troubleshooting that.

Admin CP -> Home -> List Add-ons -> Disable (in the Control menu for each addon)

It was an add-on. After systematically disabling, it was

ragtek New User Conversation

 

[ragtek]

It was an add-on. After systematically disabling, it was

ragtek New User Conversation

Are you sure?
My add-on doesn't make anything on usergroup-change.

It only checks the datawriter if it is a insert, if yes, it sends a conversation...

class Ragtek_NUC_DataWriter_User extends XFCP_Ragtek_NUC_DataWriter_User
{
    protected function _postSave()
    {
        if ($this->isInsert())
        {...}

So it doesn't make anything, if it is no insert (no new user)

 

[Mike]

Ragtek, are you calling parent::_postSave() ? If not, that's wiping out all of the post-save behaviors.

 

[ragtek]

yes, of course i'm calling it^^

protected function _postSave()
    {
        if ($this->isInsert())
        {
            parent::_postSave();
            $createrModel = new XenForo_Model_User();
            $createrId = XenForo_Application::get('options')->NUC_convCreater;
            $creater = $createrModel->getFullUserById($createrId);

            $phraseArray = array(
                        'boardname'    => XenForo_Application::get('options')->boardTitle,
                        'username'     => $this->_newData['xf_user']['username']
            );

            $subject = new XenForo_Phrase('ragtek_NUC_Subject', $phraseArray);
// stuff to init & send the conversation
....
...

$conversationDw->save();
            $conversation = $conversationDw->getMergedData();
            $convModel = new XenForo_Model_Conversation();
            $convModel->markConversationAsRead(
                $conversation['conversation_id'], $createrId, XenForo_Application::$time
            );
        }
    }

 

[Shadab]

Shouldn't the call to parent:: be outside the if conditional?

$createrModel = new XenForo_Model_User();
$convModel = new XenForo_Model_Conversation();

And please, please, never instantiate models directly!

 

[Mike]

Shouldn't the call to parent:: be outside the if conditional?

That's it exactly.

 

[ragtek]

So, i have to call it always?

Ups, then all my "new user - " mail/conversation/thread add-ons are broken
F*ck

thx guys

 

[ragtek]

Shouldn't the call to parent:: be outside the if conditional?

$createrModel = new XenForo_Model_User();
$convModel = new XenForo_Model_Conversation();

And please, please, never instantiate models directly!

 parent::_postSave();
        if ($this->isInsert()) {

            /** @var $userModel XenForo_Model_User */
            $userModel = XenForo_Model::create('XenForo_Model_User');
            $createrId = XenForo_Application::get('options')->NUC_convCreater;
            $creater = $userModel->getFullUserById($createrId);

Better^^?

 

[Shadab]

Yes.