Default Permissions Profile Error

[KittyGalore]

Hello I have this error when i go to the manage permissions edit profiles section here and click the Default group



I get this fatal error here.



I run PHP 8.2 when i drop it down to 7.4 the error goes away and i'm able to edit the permission in that profile but put it back and the error comes back.

Running  SMF 2.1.4 and i have these mods installed.


Has anyone encountered this? Whenever i change the PHP version it fixes it so not sure what's causing it. If this was mentioned before I apologize.

[Kindred]

Could be any mod that adds permissions ...

[Arantor]

Nope, this one is a PHP 8.2 bug.

ManagePermissions.php line 325-329 (and present in both 2.1.4 and 2.1-release)

Code Select Expand

while ($row = $smcFunc['db_fetch_assoc']($request))
{
if (isset($context['groups'][(int) $row['id_group']]) && (!empty($row['add_deny']) || $row['id_group'] != -1))
$context['groups'][(int) $row['id_group']]['num_permissions'][empty($row['add_deny']) ? 'denied' : 'allowed'] += $row['num_permissions'];
}

328 is the second to last here, and you're doing an addition on a string; earlier versions of PHP would correctly coerce the numeric string at this point, 8.2 does not.

Replace with:

Code Select Expand

while ($row = $smcFunc['db_fetch_assoc']($request))
{
if (isset($context['groups'][(int) $row['id_group']]) && (!empty($row['add_deny']) || $row['id_group'] != -1))
$context['groups'][(int) $row['id_group']]['num_permissions'][empty($row['add_deny']) ? 'denied' : 'allowed'] += (int) $row['num_permissions'];
}


[KittyGalore]

Nope, this one is a PHP 8.2 bug.

ManagePermissions.php line 325-329 (and present in both 2.1.4 and 2.1-release)

Code Select Expand

        while ($row = $smcFunc['db_fetch_assoc']($request))
        {
            if (isset($context['groups'][(int) $row['id_group']]) && (!empty($row['add_deny']) || $row['id_group'] != -1))
                $context['groups'][(int) $row['id_group']]['num_permissions'][empty($row['add_deny']) ? 'denied' : 'allowed'] += $row['num_permissions'];
        }

328 is the second to last here, and you're doing an addition on a string; earlier versions of PHP would correctly coerce the numeric string at this point, 8.2 does not.

Replace with:

Code Select Expand

        while ($row = $smcFunc['db_fetch_assoc']($request))
        {
            if (isset($context['groups'][(int) $row['id_group']]) && (!empty($row['add_deny']) || $row['id_group'] != -1))
                $context['groups'][(int) $row['id_group']]['num_permissions'][empty($row['add_deny']) ? 'denied' : 'allowed'] += (int) $row['num_permissions'];
        }


Thanks maybe move it to the bug section.

I tried changing the code you mentioned replace with but still get the error.

[Arantor]

The error must be different now. It literally cannot be giving you the error you had before on that line because the error says "string + string" and that code forces it to not be string + string...

[Arantor]

Though actually one other route occurs to me how this might happen and that's also in the camp of 'it shouldn't' but I could see a badly written mod causing it.

The way to tell would be to look at the database with the following query:

SELECT * FROM smf_board_permissions
WHERE (id_group = 1) OR (id_group = -1 AND add_deny = 1)

[KittyGalore]

Though actually one other route occurs to me how this might happen and that's also in the camp of 'it shouldn't' but I could see a badly written mod causing it.

The way to tell would be to look at the database with the following query:

SELECT * FROM smf_board_permissions
WHERE (id_group = 1) OR (id_group = -1 AND add_deny = 1)

This is what i see

[KittyGalore]

The error must be different now. It literally cannot be giving you the error you had before on that line because the error says "string + string" and that code forces it to not be string + string...

Yes i tried again it's giving sting+int instead of string+string

[KittyGalore]

On a brand new test forum on PHP 8.2 everything is ok. My forum originally was upgraded from 2.0.19 to 2.1.4 so it looks like an old mod somewhere in the database is messing with it the problem is i don't know which one as i installed the same mods exactly on the test forum copying from my main one as well and i don't get the error.

[Arantor]

Though actually one other route occurs to me how this might happen and that's also in the camp of 'it shouldn't' but I could see a badly written mod causing it.

The way to tell would be to look at the database with the following query:

SELECT * FROM smf_board_permissions
WHERE (id_group = 1) OR (id_group = -1 AND add_deny = 1)

This is what i see

You need to go to the query tab and copy/paste the bit of code I gave you. The structure is fine, but there's possibly some rogue data and that piece of code run in the query tab should identify what it might be.

[KittyGalore]

This was the results I hope i done this right.

[Arantor]

Ugh, those are some not so well behaved (if well meaning) mods.

So the issue you have is that you have board permissions set up in contexts where board permissions can't ever be accessed by the UI because they don't make sense (e.g. there's no universe in which it's possible to deny permissions to an admin, nor to deny board permissions to guests because of how guest permissions are constructed)

So let's fix that. More queries to run.

First, let's fix admin permissions; there's never a situation where any admin permissions are ever applied; group 1 is special and always automatically has all permissions, so there's no need to set board permissions of any kind.

Code Select Expand

DELETE FROM smf_board_permissions WHERE id_group = 1;
Second, let's ensure there aren't any guest permissions kicking around that shouldn't be.

Code Select Expand

DELETE FROM smf_board_permissions WHERE id_group = -1 AND add_deny = 0

[KittyGalore]

Ugh, those are some not so well behaved (if well meaning) mods.

So the issue you have is that you have board permissions set up in contexts where board permissions can't ever be accessed by the UI because they don't make sense (e.g. there's no universe in which it's possible to deny permissions to an admin, nor to deny board permissions to guests because of how guest permissions are constructed)

So let's fix that. More queries to run.

First, let's fix admin permissions; there's never a situation where any admin permissions are ever applied; group 1 is special and always automatically has all permissions, so there's no need to set board permissions of any kind.

Code Select Expand

DELETE FROM smf_board_permissions WHERE id_group = 1;
Second, let's ensure there aren't any guest permissions kicking around that shouldn't be.

Code Select Expand

DELETE FROM smf_board_permissions WHERE id_group = -1 AND add_deny = 0

So i ran the first code and it told me 11 rows got deleted and the second code told me 0 rows got deleted.

I then went into the section which was giving me the error and it's now fixed. Thank you so much Arantor.

Do i need to do anything else or check if it's all ok.

[KittyGalore]

Running that previous code this is the new result it's gotten much smaller.

[Arantor]

If you can go into the area that used to have an error, and it now works, it now works and is all good. You had some rows you shouldn't have had, and that was what was causing the problem.


On a broader note for the team's consideration: this isn't the first time rogue permissions have gotten into the system (and it's inevitably admins permissions rather than rogue guest deny permissions, exactly as it was here), perhaps some way to ignore that when building the UI and perhaps even cleaning it out if discovered.

[KittyGalore]

If you can go into the area that used to have an error, and it now works, it now works and is all good. You had some rows you shouldn't have had, and that was what was causing the problem.


On a broader note for the team's consideration: this isn't the first time rogue permissions have gotten into the system (and it's inevitably admins permissions rather than rogue guest deny permissions, exactly as it was here), perhaps some way to ignore that when building the UI and perhaps even cleaning it out if discovered.

Thank you yes the problem is now fixed.

[Sesquipedalian]

perhaps some way to ignore that when building the UI and perhaps even cleaning it out if discovered.

That's a good idea.