XF 1.5 All users added as administrators when importing IPB4.2

[Dubbed Navigator]

Hello

I have recently performed a test import on my board from IPB 4.2, to XF1.5 then upgraded to XF2

Something I noticed fairly quickly, was that every user appears to have been added as an administrator.

For clarity, this is not to the administrative group, they are physically admins and by the look of it with all the permissions associated..

Any idea why this may have happened, and a bulk way of sorting it out please?

 

[Chris D]

If anything, this is not a bug in XF2 itself, but maybe a bug in the importer so the bug will exist in XF 1.5 code.

I don't think there's really any viable way to resolve this in bulk, so ideally we'd need to ascertain what the cause was and then rectify that and then you'd need to re-do the import.

It has been a few days since you reported this, have you taken any steps since to rectify the issue?

 

[Chris D]

There are basically two areas in the code where we assume a user in IPB is an admin.

The first is if the user's "member_group_id" value in IPB matches the admin group ID value which I believe defaults to 4.

The second is if the user is in a group which has some "admin_restrictions" set. I note that this code does appear to have changed since earlier versions of IPB and there was an additional check to see if the group had permission to access the admin CP via the "g_access_cp" permission, though this appears to have been removed from IPB 4.x. Is it possible that all of these members are in a group that has "admin_restrictions" (which I believe is IPB's equivalent of Admin permissions)?

 

[Dubbed Navigator]

To be honest I didn’t check this out prior to the upgrade to XF2, so I wouldn’t be able to tell you. Your assessment would seem appropriate however.

I’d assume admin_restrictions would need to be a manual change in permissions, so to have nearly 2k members having any alterations to that affect would be unlikely, I’ll grave a look though and report back.

 

[Chris D]

I did some further checks into how the permission system in IPB works, and the only way I can see this happening is if there was actually a group set up, such as the main "Members" group, under AdminCP > Members > Administrators.

That would be the only way a group would have a valid "admin_restrictions" entry in the "core_admin_permission_rows" table.

 

[Dubbed Navigator]

Hi @Chris D - I have verified that the main members usergroup is not added as an administrator.

 

[Chris D]

What is the user group ID of your main members group, and your main admins group in IPB?

 

[Dubbed Navigator]

Main members group is 3, admin group 4

 

[Chris D]

As it's supposed to be and as the code expects by default.

Right now the only logical explanation I can give for this is if these values changed on the config step. I'd like to think that if you did the import again, then this wouldn't happen but I can't be sure.

Is there any way we can view your old IPS database? If so, could you please submit a ticket and send log in details and we'll take a closer look.

 

[Dubbed Navigator]

I'll get my test DB over to you later, thats what the data was imported from anyway so would be best.

 

[Slavik]

I'll get my test DB over to you later, thats what the data was imported from anyway so would be best.

Ran into this earlier and Chris managed to track down the error:

At line 850

            foreach ($this->_getGroupsForUser($user) AS $group)
            {
                if (!empty($group['admin_restrictions']))
                {
                    $adminRestrictions = json_decode($group['admin_restrictions'], true);
                }

                return 1;
            }

Change to

            foreach ($this->_getGroupsForUser($user) AS $group)
            {
                if (!empty($group['admin_restrictions']))
                {
                   $adminRestrictions = json_decode($group['admin_restrictions'], true);
                   return 1;
                }

            }