32-role limit

Linc

I just ran my first test import of usergroups from vBulletin and hit a limitation of Garden. Because the RoleIDs scale by 2 (1,2,4,8,16,etc) and the column is int(11) you can never have more than 32 roles.

In a base install with 5 roles that probably doesn't seem like a big deal, but in a complex community with almost a decade-old history we've had more than 50 created over the years (we have less than that total currently, but I'm not clear if Garden will ever reuse RoleIDs - I assume not).

I can certainly parse back our total number of usergroups before importing (and would have been doing this anyway) but still expect to have up to 20 (especially since I'm integrating it with 3 Wordpress blogs), which leaves a significant amount of worry in my mind about the extensibility of this model moving forward.

Mark

@Todd set up the roles - we should get his feedback on this one.

Todd

The intent of the base 2 roles is to be able to represent all of a user's multiple roles as one int. This is an optimization that I do want to be able to eventually have and I thought that assigning a user to multiple roles would give the flexibility that having a huge number of roles requires in other systems.

In the case of imports I'm not sure here. I suppose we could have a config that determines how roles are used. Any feedback here would be appreciated @Lincoln.

Linc

I totally get storing multiple roles as one int and have done projects that way myself.

Here's an example of my issue with it, though: Say I have a group of 50 event attendees that need to have many private discussions. OK, I put them in a new role with special permissions for one category, done. But in the meantime I happen to make another role (which gets the next-highest roleID). When the event is done, I delete the first role... but since the second role is a higher index value, I've permanently used up one of my 32 roles for all time.

I really like the simplicity of the all-in-one int value to express roles, but I'm not sure it scales well enough for a platform that you're supposed to be able to extend with anything you can dream up.

Maybe it could at least look for gaps in the sequence and fill them in so you can at least get up to 32 at any given time instead of all-time?

It'll probably work for now... but I'd be willing to plunk a fiver down that someone else is going to come along in the next year or two with a problem because of this (and the fact that it's undocumented and that it'll throw an error when you try to add the 33rd role).

Linc

Just for the sake of argument, here are some of the usergroups on my site currently (beyond the 5 default) that all have different permissions:

Moderator: Tech

Moderator: Gaming

Moderator: Life & Community

Editor: Tech

Editor: Gaming

Editor: Life

Staff

Event Staff

Event Attendee

Supporter

Gamer

And that's after I culled/condensed 15 other groups that I'd accumulated over the years to make sure I could do the migration to Vanilla. On a big community site, the number of potential roles grows pretty quickly. So that's half my roles used up before I've even written a single Garden app or addon myself.

Todd

I think for now I will take your suggestion of looking for gaps. I kind of want to keep the ability for the caching in the future, but I will have to think of something for people with a lot of roles. You're right that this will probably have to be revisited in the future.

Thanks so much for your input @Lincoln.

Linc

Sounds good, thanks @Todd

S

Spirit of Vanilla says:

"Vanilla = Easy & Simple. Who needs more than 32 roles then use plugin. Don't build extra "role tables" in my core!"

P.S. GDN_Role RoleID int(11)

If we change RoleID type to BIGINT unsigned we obtain 63 roles (theoretically). I think, it is more than enough : )

samanime

I like the idea of having extra roles added via a plugin. I haven't looked at the specifics for creating plugins (yet ), but I wouldn't think it'd be too much trouble to wrap it up in a plugin.

JosephCalzaretta

Todd, I'd like to vote for allowing more than 32 roles.

In Vanilla 1, a user could only have one role, but the number of possible roles was very large (was it a 32-bit integer also? if so, then we're talking four billion.) Each role could have a completely independent set of permissions, so it was possible for each user to have a completely independent set of permissions (i.e., assign each user a unique role).

In Vanilla 2, you cannot do this anymore. Sure, a user can have multiple roles, but the set of permissions a user can have is severely constrained... essentially there are at most 32 "eigenroles" of which any user's permissions must be a simple combination. To make this clear: in Vanilla 1, you could have billions of roles, each of which you could specify independently. In Vanilla 2, you can have billions of role-sets, only 32 of which can be specified independently. The other four billion of them are essentially chosen for you.

We at MIT are looking to provide a (single) forum solution for our academic classes... each with its own private discussions. Let's say we have a thousand classes, and each student is a member of less than five classes. Ideally, each class would map to a role, and each student would have a few roles. But there's essentially no way to represent this level of granularity in Vanilla 2 (well unless you allow RoleIDs to be general numbers), since there are more than 32 classes. Less than ideally, each student would map to a role. But we can't do that either, since there are more than 32 students.

I don't think the possible optimization of representing a set of roles as a single 32-bit integer is all that compelling (although I have obvious motivations for seeing it this way), since it implies that the performance of doing SQL queries against properly indexed tables will be too slow, but bitwise operations on integers won't be. If the performance is that sensitive, I'd be worried. (I mean, it's not implemented that way now, is it?) But maybe I'm not thinking about it right.

Oh, and as for the plug-in idea, is that really feasible? How much of the core functionality would have to be overridden by the plug-in to get this done?

S

@JosephCalzaretta

> (i.e., assign each user a unique role).

Obscurantism.

Look at the GDN_Permission table. It has columns JunctionTable, JunctionColumn, JunctionID. Number of permission sets for some application can be much more than number of roles (Example is Vanilla - Categories). Normally, any work with web-application can be organazied with 3-4 (max) REAL roles. If you need more... so seriously ask yourself: do I organized properly structure of my application..? Probably not.

JosephCalzaretta

S, the number of permissions per role is not at issue for me... it's the number of roles. Presumably your background in webapps has only presented a need for a handful of roles, but in a large community site with many private areas, one needs arbitrary groups/roles to handle permissions. I agree to spend some time introspecting about whether I'm doing it all wrong, as you suggest, if you'll do me the favor of considering the possibility that the issue of authorization might be more subtle than you're allowing.

Mark

Just mentioning @Todd on this one so he knows to come back and catch up...

tonyamazing

@JosephCalzaretta
Did you end up figuring out a work-around for this 'feature'?

@Todd & @Mark
Is there still a 32 role limit? Are deleted RoleIDs being reused?

@Todd
You mentioned "representing all of a user's multiple roles as one int." Is that currently in use? Would it be blasphemous for me to hack at the core such that the RoleID isn't in base2?

Tim

Reading this ... it seems like a lot of these comments indicate a possible misunderstanding of what Roles are, and what they're for.

Roles are permission groups. The only time you should be adding new roles is when you want to create a new and unique set of permissions. Roles are not labels, or ranks.

So I was thinking... would this issue go away if we made a plugin or core feature that allowed the use of traditional forum ranks / labels? So you could label users with some sort of system that had nothing at all to do with permissions?

@Lincoln ?
@JosephCalzaretta ?
@S ?
@Todd ?

tonyamazing

@Tim

The forum I am integrating has a need for very strictly controlled forums allowing read / write access to only select groups of people.

Imagine having a separate, private forum for each of the 52 states in the U.S. which can only be viewed and commented on by people who live in those states. Add to that separate, private forums for each county in each state.

Someone who lives in Orange County will only be able to view two forums: Orange County, and New York state.

This is not an actual example of what I need (I live in Australia) but it does outline some of my requirements.

My approach to this situation is to have a category to every private group and to assign a specific role to that category (and any moderator roles).

I can't see any other way to achieve those requirements.

Would a Rank / Label plugin achieve the results I'm after?

S

@tonyamazing
You need:
1. Additional table, for example
UserState (UserID, StateID)
2. Plugin which can set CUSTOM permission name for user's after log-in, like:

public function Base_AfterGetSession_Handler(&$Sender) {
	$User =& $Sender->EventArguments['User'];
	$User->Permissions = Gdn_Format::Unserialize($User->Permissions);
	$User->Permissions['Plugins.Vanilla.USA.View'] = array(1, 5, 20, ...);
	// current user can view only states 1, 5, 20, ...
}

2.1. and check permission before any private data shows.
Like this.

$Session->CheckPermission('Plugins.Vanilla.USA.View', True, '', $StateID);

And of course you need custom backend to fill "UserState" table.

@Tim, am I right?

tonyamazing

@S

Thanks for the info but states was merely an example.

There will be other interest groups that will have nothing to do with where a user lives and nothing to do with their profile.

The long-short of it is: There is a need for private forums whereby users subscribed to those forums are the only people who can view and comment on them.

Tim

When Todd gets back from his trip I'll talk to him about Roles. Sadly, even though I can see this is a problem for you, we have to focus on our 2.0 release right now, which means less features and more bug squashing. This will have to wait a bit.

tonyamazing

@Tim,

I understand that this situation of mine is a rare one and that for most set-ups, 32 roles is more than adequate.

I don't believe that there is a need for this to be fixed in any release.

What I'd like to know is: Would it be blasphemous for me to hack at the core such that the RoleID isn't in base2? Or, will it break anything?

Tim

@tonyamazing,

I don't think anyone at Vanilla will ever have a problem with people in the community taking a hacksaw to the code and bending it to their will -- that's why it's open source! On the other hand, once you start down this road, the amount of help we can provide drops off sharply. I probably won't be able to devote much / any time to troubleshooting a problem with code we don't need to support.

As for whether or not this change will break things... you'll need to check into that yourself. In theory it should be as easy as changing how the role management methods work and incorporating your new algorithms into them. On the other hand, perhaps @Todd went into a code dervish while making this feature and it might be crazy complicated. It was before my time. I think if you were going to run into a problem it would be with the way multiple roles are stored. As @S suggested, you'll need some sort of middle table and a good (fast) way to query it and build a representation of the user's roles from that data.

I wish you luck! If you end up doing a very good job and it works as a drop in replacement for the way we do it now, you may want to think about submitting it back to the core for us to check over and possibly pull into the codebase.

Happy hacking!

Tim