thanks, glad to hear that, I'll try it

Hi Kirby, just 1 quick question if I may.

What is an "appropriate Bitfield XML file"? Do you have a template of what one should look like?

Thanks,
Alan.

Therer was an apparent restructuring of the file class_dbalter.php changing the class and functions used in Kirby's uninstall example.

fetch_table_info has now changed to fetchTableInfo and drop_field has changed to dropField and lastly table_field_data has changed to fetchFieldInfo.


new coding
Lastly TABLE_PREFIX is no longer needed...

I did everything the tutorial said and I can see the radio button in the admin permissions but when I click "yes" and save it, it goes back to "no".

Do I change customadminperms?

Yes, same problem for me...

This thing doesn't actually work. (3.5.3)
After the first check of permissions, the static $adminpermissions; takes over, to which the custom permissions are not added.

Therefore an alternative solution is required.
I will look deeper into it tomorrow.

You're right. Must have missed that issue as I only had one custom navgroup - and it was the first one.

I tweaked the code a bit to get around this.

Allow me to point out two facts:

1. static doesn't work through eval(). Believe me, I tried. I worked with this for 3 hours straight yesterday XD
2. You might not actually have to run a new query:
   
   PHP Code:

   ---

   global $admin;

if (isset($getperms['customadminperms']))
{
    $admin = $getperms['customadminperms'];
}

if (!isset($admin))
{
    // must get our perms
    $getperms = $vbulletin->db->query_first("
        SELECT `customadminperms`
        FROM " . TABLE_PREFIX . "administrator
        WHERE userid = " . $vbulletin->userinfo['userid']
    ); 
    
    $admin = $getperms['customadminperms'];
}

foreach ($do AS $field)
{
    if ($admin & $vbulletin->bf_misc_customadminperms["$field"])
    {
        $return_value = true;
    }
} 


   ---

   I tested this code on localhost yesterday, and it works like a charm, no extra queries involved unless for some reason it won't work like it should without :)

EDIT: This randomly doesn't seem to work for OLD administrators, and only in the ACP menu.
In my custom menu it works fine, it just doesn't work in the cpnav_ menu.
EDIT #2: I fixed it now. Made it so it doesn't query unless for some reason it didn't fetch the permissions properly. Also I replaced the * in the query for a slight load decrease =P

Well ... as of vBulletin 3.5.4 $admin is there by default :)

The following code might work cross-version?

It might, but due to the fact that I don't actually use the $admin variable, I don't know if I need to change the code.
I don't really see how changing the variable name would help in solving the original problem, though. I just tested the new plugin with some slight alterations and it works.
I cba to "remake" it into your "customadminperms" format so Ill just give it like I use it:
Tested to work on 3.5.3 and 3.5.4.
I think that's a pretty efficient way of doing it, as it only runs 1 additional query for ONE admin (out of the ~10 I tested it on, non-superadmins that is).
So yeah, tis odd, but meh =P