Products & Permissions

[Sarcoth]

I have the vbActivity and vbShout. One trend I am seing for these products is that to give permissions, I need to go into each Usergroup and apply permissions that way. Instead, can this be converted over to assign the permissions via the Setting Options area?

Personally, I like to set my Usergroup permissions when I first create a new usergroup and then I want to leave it alone unless something changes. I'd rather not have to go back into each usergroup every time I install a new product. I have a lot of usergroups. IMO, it would be much easier to go into a setting option for one of the products and then select all the usergroups I want to give certain permissions to. I like the fields on a lot of mods where you have to enter all the usergroup id's you want to give permissions to, but a more user friend way is where the admin has to highlight all the usergroups. A good example of this is in the EasyForm's mod.

Thanks for reading.

 

[Deceptor]

I completely agree, however extending the stock usergroup setup allows seemless integration with vBulletin such as Secondary Usergroup permissions. Personally I like IPBs Grid Permissions, fast and easy - but vBulletin have yet to make a user-friendly ACP

 

[Sarcoth]

I completely agree, however extending the stock usergroup setup allows seemless integration with vBulletin such as Secondary Usergroup permissions. Personally I like IPBs Grid Permissions, fast and easy - but vBulletin have yet to make a user-friendly ACP

I never noticed any problem with Secondary Usergroup permissions in the other way. What kind of problems does it have? I'll have to check out the IPBs.

 

[Deceptor]

Generally custom-made permissions (like entering IDs), only check the users primary usergroup. However secondary usergroups should override permissions of the primary if better. So if you have UsergoupA with a permission set to No, then UsergroupB with that same permission set to Yes, UsergoupB would override UsergroupA (assuming the users primary usergroup is UsergroupA and secondary contains UsergroupB).

This is why vB made the primary/secondary UGs, and to comply it is best to use their built-in system, not to mention not having to write additional code to repeat what vB is already doing (thus wasting resources).

When you add it all up, a better UI just doesn't topple the advantages of what's already available, even if I do hate the UI much like yourself

 

[Neo_Angelo]

I'd have to agree with you totally there, i know that the ACP can be a mish mash of repeated processes but a little effort goes a long way, plus i'd rather save on resources than have to take up valuable sources to make my life easier. i'm sure the majority of us all dislike the ACP's functionality for this but i'm sure if theres a better way to do it, it'll probably be done in future updates.

 

[Sarcoth]

Ahh, I see what you are saying Deceptor. My roster mod doesn't seem to have that problem though. My code doesn't seem to care whether they are in the primary or secondary group, but I also only use my permissions to give access. I don't have any permissions that prevent access; perhaps that's it. For my mod, whatever group you give access to, those members can get to the page and it doesn't care what other groups they are in.

 

[Deceptor]

Ahh, I see what you are saying Deceptor. My roster mod doesn't seem to have that problem though. My code doesn't seem to care whether they are in the primary or secondary group, but I also only use my permissions to give access. I don't have any permissions that prevent access; perhaps that's it. For my mod, whatever group you give access to, those members can get to the page and it doesn't care what other groups they are in.

Right, the mod is probably also checking the users secondary UG too (if your secondary UGs are getting in fine), which is emulating what vB does. No issue at all really, just a little extra resource to repeat what's already being done. You could argue that process is absolutely nothing, but a site I'm contracted to can recieve over 25,000 users online at the same time, that nothing can become a big something. So my attitude is always to do it the most optimal way, even if it is "overkill" in some situations.

 

[Sarcoth]

I'm not trying to be difficult or challenge anyone, but I'm still confused on what extra processing has to be done. I enjoy programming and I just want to understand.

What is the difference between something like this:

if (!$vbactivity->permissions['canview'])
{
// Can't view Activity
print_no_permission();
}

And something like this:

if (!is_member_of($vbulletin->userinfo, explode(',', $vbulletin->options['showroster_access_groups']))) {
print_no_permission();
}

I know the second one is longer, but I really don't see a resource problem, even if the site has 25,000 users.

 

[Deceptor]

The first code is pre-set by vBulletin, it autoloads all permissions into the users userinfo. Then like the original code, it can be checked with a simple condition. In vBActivitys case, the permission was referenced elsewhere (to the class interface), but it's still processed by vBulletin.

The second code however is executing a function, that function is scanning the Primary/Secondary usergroups to find a match within an array of digits. Sure by any means the processing required is pathetic - but don't under estimate what that iterated 25,000 times will do. Plus my point wasn't specific to "just this", the bigger picture is if you waste these tiny resources all over, they come back to bite you.

 

[Sarcoth]

Damn, you are fast. Okay, now I understand what you are saying. I know you said it before, but I guess it just didn't click about the pre-sets. I didn't realize the difference there. Thank you for clarifying.

Here's another question then. How about using a permission setup like the Arcade mod? That mod puts all the permissions on the same page and is only one page for all usergroups. That uses a preset too doesn't it? I think that's a bit easier than going through every usergroup.

 

[Deceptor]

Damn, you are fast. Okay, now I understand what you are saying. I know you said it before, but I guess it just didn't click about the pre-sets. I didn't realize the difference there. Thank you for clarifying.

Here's another question then. How about using a permission setup like the Arcade mod? That mod puts all the permissions on the same page and is only one page for all usergroups. That uses a preset too doesn't it? I think that's a bit easier than going through every usergroup.

Like I said before, asthetically and in a UI sense it's better to make your own permission control instead of vBulletins - I don't disagree there, my only point was in didn't run through vBs stock system and is a little extra resource. I'd love it if we could mix the two

However, when you make things generally you want them to be "Future proof", now consider vBulletin made massive revamps to the Usergroup architecture that broke all those custom interfaces for handling perms, while those piggy-backing on the stock system worked fine (not that I believe such will happen, just a point).

 

[Sarcoth]

Oh well, I tried. I have some other suggestions for it, but it really doesn't matter I guess since I already set them. Hopefully I won't have to do it again.

Thanks for the replies.

 

[Deceptor]

Oh well, I tried. I have some other suggestions for it, but it really doesn't matter I guess since I already set them. Hopefully I won't have to do it again.

Thanks for the replies.

You're more than welcome - your idea did remind me of something I made in the 3.0.0 series for a little test, a Mass Usergroup Perm setter. It would basically allow you to select an "area" of the permissions (say, Posting), then assign the Posting perms, and a selection of the usergroups you wanted to assign it to.

Worked pretty well too, and worked with any custom permissions added through vBs system. Might bring it back to life

 

[Fillip H.]

You're more than welcome - your idea did remind me of something I made in the 3.0.0 series for a little test, a Mass Usergroup Perm setter. It would basically allow you to select an "area" of the permissions (say, Posting), then assign the Posting perms, and a selection of the usergroups you wanted to assign it to.

Worked pretty well too, and worked with any custom permissions added through vBs system. Might bring it back to life

Do it fgt.

Usergroup permissions, Options and Plugin / Product Management are 3 areas in vB that really and desperately need an update.

 

[Deceptor]

Do it fgt.

Usergroup permissions, Options and Plugin / Product Management are 3 areas in vB that really and desperately need an update.

Maybe when I've finished with the other project Priority ftw.

 

[Sarcoth]

BTW, I updated all the programs I have the other day and I really like how a lot of the options can now be set in the options area. Just a couple things to click in the usergroups.