How does Usergroup permission work?
 

Hey,

I need to understand how vB's general permissions work that you change from the Usergroup Manager?

How does vB's script check whether it's a Yes or No value? I've been trying to figure this out for a while and thought maybe someone here has an answer.

Thank you
Johnny

anyoooone

it uses bit system, 1,2,4,8,16,32,64,128, etc...

You might want to take a look at init.php

How does that system work really? i don't understand how it works.

I've successfully added a new Yes/No options to Usergroups but now afterwards how do I write my scripts to detect if it's a Yes or No value?

thanks

it'd be nice with an answer.

If I knew id tell you, you will either have to wait or go read documentation, sorry.

I gotta bump this thread as I am having issues with the init.php file..

i have add more usergroup options and I gotta Understand how these work. How long does it take until they populate the new $usergroup array so I can start using them for checking permissions etc..

anyone? please...

okay, i figured it out.. wow. i'm good :p

Great, can you share the info :) ?

The coding of permission is tight but makes life hard for hackers.

when you understand how it works you see it's easy.

This one is also the same. I may make a tips thread for this soon.

Can anyone explain this thing? I can't get my head around the concept.

Explain what exactly ?

This part. There are numbers for each permission. How does that work? What is the bit system? How can you figure out permissions? Why is this system chosen? Etcetar

Hmm a lot of questions in 1 sentence:
- Why is this system chosen?
I don't have the faitest idea, but i guess one consideration mught have been that you can store a lot permissions inside a releative small row.
- There are numbers for each permission. How does that work? How can you figure out permissions?
They are defined in your includes/init.php. You can check there for the value of each permission.
- How does that work?
Well already said it is a bit-system. In a bit system (or binary) you only write number as a combination of 0 and 1.
Just a small example:
The decimal number 1 would be a 1 in binary.
The decimal number 2 would be a 10 in binary.
The decimal number 3 would be a 11 in binary.
The decimal number 4 would be a 100 in binary.
The decimal number 5 would be a 101 in binary.
etc... search on the net for more basic info on how to work with binary calculations

If we now use every bit of that binary number to indicate 1 permission, we could build up a number like:
Binary: 1101001 (decimal 105)
We can now store this in database as a decimal 105 in only 3 positions. But we got 7 bits (permissions) we can set or retrieve.
Now we can test this number to see which bits are set, if a bit is set, we consider this a yes permission, otherwise a no.

So permissions 1101001 could decode like (reading the number from right to left, starting with bit 0)
bit 0 == 1, so permission 1 is set
bit 1 == 0, so permission 2 is set
bit 2 == 0, so permission 3 is set
bit 3 == 1, so permission 4 is set
bit 4 == 0, so permission 5 is set
bit 5 == 1, so permission 6 is set
bit 6 == 1, so permission 7 is set

thank you. It does help a bit. I wanted to know this in case of adding a new permission to the system without messing up the existing permissions and scared of conflicting with future permissions vb might assign in the future. I'm scared adding a permission will mess up some code somewhere because of not understanding the system too well.

If I get you correctly, this new usergroup system makes hacking permissions much more questionable for future compatibility. If they are up to 256 and we add one, it isn't like naming a variable $mydwhhackedvariable. You have to go with their numbering and are likely to collide unless you choose a very high number. But do you lose flexibility by choosing a high number?

Well you could use a high number, as long as it is a multiple of 2, thus reducing the risk of a future clash. Best would be to let the user who is installing calculate the next free number himself, but this would still mean there is a risk if a new standard permission is used somewhere in the future that there are already permissions set for this new option in the database (consider S'Admin would be a new permission based on this system, using a number you previously used for a custom "Can use PM", a lot of user would suddenly turn into S.Admin, but this would be worsed case scenario).

A better way is to create a new custom permission group in the init.php. Now you can create a group only for you and your hacks to use, without ever interfering with others. It will take a bit more coding though, but not so much.

Search in your includes/init.php for:
and after that add some lines like:
Then you will have to add the field 'myhackpermissions' to the usergroup table, so the value can be stored (no coding needed for that i think).

Thank you. Do you think the extra field in usergroup might cause performance issues?

No that will not cause performance problems.

It would be different if you wanted to create a new table for storing your own permissions. Tehn you would need extra queries.

what a handy thread, this will come in very handy next week.

Best advice for usergroup permissions:
Don't extend existing bitfields!

Sooner or later this will cause problems.

Yes that is why i gave advice to create your own group.
Made that error on my first hack (never released), it was so easy to just extend an exisiting group. :D

Understood later that what might look easy to start with, could bring you into troubles later.

Unfortunatly i see most coders of smaller hacks just extend the existing ones.

I have found this and other information useful. I thank all that have contributed. Now that I have my permissions set up and able to be modified via usergroup.php. My new problem is how to read the permissions and interpret their state. I have created a new field in the username table and the information is an on/off (Yes/No) option. How do I retrieve the permission state?

Can anyone assist with this? It is the only piece I am having trouble grasping when it comes to assigning and checking permissions I think.

To access the new field, assuming the name of the new field is "newfield" you simply go $bbuserinfo[newfield]

This does not return any value. The current value should be 1 and it is returning null. This new field is dealing with usergroup permissions... the same general permissions that you would check for "Can delete own posts" or "Can move own threads". If I hard-code a value of 1 to my variable, the script works correctly. I tried $canviewtwice = $usergroup[canviewtwice];, but that did not give a result either. canviewtwice is the name of the usergroup bitfield assignment.

EDIT: I found it. It was $permissions[canviewtwice]; that was needed. How stupid do I feel now? :o

Thanks, guys, for the assist. I am learning a LOT through this process thanks to you all!

I misunderstood the question but glad you figured it out.