Setting Permissions Not Working

Shaun Mason

Active member
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?
 
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:

Screen shot 2010-12-21 at 8.08.37 PM.webp

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.
 
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.
 
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.
 
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?
 
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.
 
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)
 
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
 
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...
PHP:
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)
 
yes, of course i'm calling it^^
PHP:
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
            );
        }
    }
 
Shouldn't the call to parent:: be outside the if conditional?

PHP:
$createrModel = new XenForo_Model_User();
$convModel = new XenForo_Model_Conversation();
And please, please, never instantiate models directly!
 
Shouldn't the call to parent:: be outside the if conditional?

PHP:
$createrModel = new XenForo_Model_User();
$convModel = new XenForo_Model_Conversation();
And please, please, never instantiate models directly!
PHP:
 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^^?
 
Back
Top Bottom