Database Driven Bitfield (Usergroup Management)

[consolegaming]

I'm getting ready to re-release my mod for 4.0 which allows for the online user list (on forum home) to be split up into certain groups/categories (currently up to 3 of them). i.e. so your staff can be listed separately from your normal users.

And in the usergroup editing screen you currently have these 3 selectable groups each with a Yes and No option. i.e. if the usergroup is a staff usergroup you'd select Yes. These groups are currently VIP, Staff and Premium User (uses phrases so changeable names).

This is currently handled using a bitfield in an xml file for my product. Now this is pretty inflexible and the main thing that was requested for my product was to be able to have as many of these definable groups as you want. i.e. completely flexible.

I understand I'd have to create a separate db table and a admin screen to edit these 'groups'. That I don't think I'd have too much trouble with or at least there's sufficient information around to find out how (the custom screen part lol). The part I'm struggling with is how I could then use this custom db table to populate a bitfield that I could then use on the usergroup management screen rather than having it manually defined in the xml file.

For the first 4.x version I intend to just expand it to 5 manual groups/categories in the xml file but I can see the benefits in letting people define however many they want. Am I looking at this the wrong way? If so could I be pointed in the correct direction lol. i.e. should I be looking at moving the settings elsewhere and trying to handle things myself?

Sorry if any of any of my questions were silly. I'm still fairly new to Product/Mod Development and the one I have released so far was a re-release of someone elses (with permission of course) so there are probably some things that I didn't pick up because of that.

[Dygear]

Bitwise operations (http://www.php.net/manual/en/language.operators.bitwise.php).

Your variables will have to be inside of a signal integer for this to work correctly.

$flags =
000 = 0 = None
001 = 1 = VIP
010 = 2 = Staff
011 = 3 = VIP & Staff
100 = 4 = Premium User
101 = 5 = VIP & Premium User
110 = 6 = Staff & Premium User
111 = 7 = VIP & Staff & Premium User

if ($flags & 1)
# User is VIP
else if ($flag & 2)
# User is Staff
else if ($flag & 4)
# User is Premium User
else
# User is a Plain Old Member

[consolegaming]

I know how bitfields work. Or at least have a basic understanding of them. That's all already working. But at the moment they're restricted to those three categories/groups. People were requesting to be able to create extra categories/groups.

My current version uses bitfields (set of 3) but they're defined in an XML Product file and currently appear on the Usergroup Management page. I was wondering if there was a way to make it dynamic by using a database table. II like how it currently works but would like for the categories/groups to be dynamic and not having to define them manually in the xml file.

In theory I could handle it all manually i.e. in a custom admincp page and setting up/saving the bitfield values in that but I'd have thought there'd be an easier way than that. And I would prefer it if the setting stayed on the usergroup management screen. Just using a dynamically (database) defined list of groups/categories rather than the current manually defined (xml file) list of groups.

[Dygear]

Ok, yeah, you could use a database table, or continue to use the XML file, just assign a number to it based off line number raised by the power of two.

pow(2, $lineNumber);

As you said that you don't want to use the XML file any more, then just use a database table, and on each result do the same thing with the pow function to show them what the value needs to be.

<?php

$sql = new mysqli(
'localhost',
'username',
'password',
'database'
);

if ($result = $sql->query($query)) {
$i = 1;
while ($row = $result->fetch_assoc()) {
printf ("%d, %s\n", pow(2, $i++), $row['level']);
}
$result->close();
}

$sql->close();

?>

Something like that ...

[consolegaming]

I'm not sure if you know how the product bitfield xml files work i.e. how you make the extra options or bitfields in my case appear on the usergroup management screen. But as far as I know it doesn't read the xml file each time.

It uses the xml file to build up the bitfields and from what I know if you make any changes to the xml file (i.e. any extra options) you need to use a tool called rebuild bitfields (If someone knows better please correct me lol). So it only really uses it when you first install the product.

Your suggestion may well be possible though I presume I would need some way of making it rebuild the bitfields when the groups are changed. Though whether this is the best way to do it or not I don't know. I'm not sure how intensive the rebuilding of the bitfields is or if I can make it just rebuild the bitfields for my product alone.

[Dygear]

I'm not sure how intensive the rebuilding of the bitfields is or if I can make it just rebuild the bitfields for my product alone.

Ideally the math should be done once only. Because, 500 users concurrently on your forum might just make the pow function the straw the broke your poor server. So, it should be done once and then stored somewhere for future use. If you wish store it in the database, or store it along with the XML file.

I have no idea about the rebuild bit fields myself, I'm not a plugin author for vB. But should I stumble across the answer, I'll be sure to post it back here. Until then, I'll leave you in the capable hands of the community.

[consolegaming]

Ideally the math should be done once only. Because, 500 users concurrently on your forum might just make the pow function the straw the broke your poor server. So, it should be done once and then stored somewhere for future use. If you wish store it in the database, or store it along with the XML file.

I have no idea about the rebuild bit fields myself, I'm not a plugin author for vB. But should I stumble across the answer, I'll be sure to post it back here. Until then, I'll leave you in the capable hands of the community.

Well the usergroups can only be edited by the admins so I was more meaning to rebuild the bitfields at the time of editing the categories/groups. i.e. if someone wants to add a new grouping. So it would need to recalculate it just once but whenever the groupings are saved.

Like I said though for my current version I'm just expanding it to 5 groupings (titles can be altered through phrases) and I was just trying to see how much trouble it would be to make it database driven. And it seems it would be quite hard lol.

[Dygear]

Like I said though for my current version I'm just expanding it to 5 groupings (titles can be altered through phrases) and I was just trying to see how much trouble it would be to make it database driven. And it seems it would be quite hard lol.

Just do a vb conditional check on the group they are in.

(I have no idea, how this works for finding grouping, but something like this)
<vb:if condition="$group==1">Look @ Me in Group 1</vb:if>

[consolegaming]

Nah I don't think you follow me now lol. It's ok you've given me some good input on the xml/database side of things. That's all I really needed at this point.

[Dygear]

If your editing the user's environment then this is queryable though the vb conditional system. So, if your making it a user custom field, if your setting a user group for that user or anything of that nature then you can use this data inside of a vb conditional, and display data accordingly.

--

I'm sorry, when I read your post, it was not quite clicking on what you where trying to do.

Yes, a database would be hands down the best option for allowing the user to edit the settings in real time. However you do this is up to you, I would recommend a separate database table that you will store your data in. Then once you have your table set up you can do a simple JOIN from one table into another and do a GROUP BY. Very simple to do, I'm sorry for not understanding you earlier. I was very sleepy and I did not read you whole post.