vBulletin since we have been using it, has had the concept of Usergroups. Each user in our site is in at least one of these. Admins, New User, Suspended User, etc. are examples. These groups are sometimes called "Permission Groups". They basically define what a user can do, or control, or see on the website. There are a built in set of Permissions that are used with vBulletin and they are very complex. I originally designed what our usergroups are and what permissions each would have a long time ago. They met our needs very well.
But since then we added many additional features and each of them may have even more permissions associated with them. Now with vb4, the CMS, social groups, blogging, the new chat, VaultWiki there are even more sets of permissions. The situation has gotten more complex and my original system of usergroups is showing its age.
In the beginning, our system was fairly simple. There were admins, mods, and registered users. As time went on we added DQ, BOD and many others. Most users are in multiple groups and one's effective permissions are some what complicated to predict.
Even before vb4, I started a process of subdividing our basic registered users in to more groups. Because, there would be more things that needed finer control. A simple example is our classifieds ads policy. It said that a user need 5 posts before being allowed to post an ad. Well, how do we enforce that? Well we could have moderators looking at every ad to be sure or we can have the system do it for us. So there is a usergroup that you are assigned to when you first register. That group does not have permission to post classifieds and the system enforces it rather than people. There are literally hundreds of cases like that, that we already have or could have.
Here I need to interrupt my monologue :gar-La; and explain a bit about "Groups". vB intended these to be social groups. But that is not what we want them for. We can and should use them for smaller "communities" to transact their stuff. For instance, someone mentioned geographical groups. Here the people in the group can plan shop crawls and lunches, etc.. Groups could also be "clubs". For instance there are 2 of these already in user groups, but they would be better served as "groups". instead. Some committees could work better in these groups. And finally, what will be the most important use of these groups, is for the Wiki. Wiki articles are collaborative. But we can't have 600 people all editing and comment on an article while in the development phase. So the wiki we using is designed so a Group can have control of an area. Those still self created group can control the development of an entry or related set of entries.
Yes we could do the same thing with the original Usergroups. But with these new groups. there is almost no additional work for staff. A user who is given permission by their Usergroup can create a group with a specified purpose. This group leader is allowed to decide who is in the group by invites or by join requests. They get their own discussion area, photo album, and some other things. It will be a very useful tool.
I set up a test group and started playing with it. That's were the reported post came from and the knowledge that our permissions in the usergroups, for groups, were not really any good. As I went to fix it, it became clear that the my original usergroup structure that is 6 years old and has had new requirements laid on it constantly, needs to be re-vamped. Otherwise I won't get groups working and the other features we want. The Admins will spend their time searching for incorrect permissions.
So, bottom line, I need to re-design the way the different usergroups are related to one another and which are primary and secondary. This sounds terrible, but it is not. To our users, the end result will not even be visible. But while I am doing it, there will be a lot "you don't have permissions" for that messages flying around. This will last for several hours. I will probably start this tomorrow , but when I do I will post a message about "Transient Problems: with permissions. Now you'll know why.
But since then we added many additional features and each of them may have even more permissions associated with them. Now with vb4, the CMS, social groups, blogging, the new chat, VaultWiki there are even more sets of permissions. The situation has gotten more complex and my original system of usergroups is showing its age.
In the beginning, our system was fairly simple. There were admins, mods, and registered users. As time went on we added DQ, BOD and many others. Most users are in multiple groups and one's effective permissions are some what complicated to predict.
Even before vb4, I started a process of subdividing our basic registered users in to more groups. Because, there would be more things that needed finer control. A simple example is our classifieds ads policy. It said that a user need 5 posts before being allowed to post an ad. Well, how do we enforce that? Well we could have moderators looking at every ad to be sure or we can have the system do it for us. So there is a usergroup that you are assigned to when you first register. That group does not have permission to post classifieds and the system enforces it rather than people. There are literally hundreds of cases like that, that we already have or could have.
Here I need to interrupt my monologue :gar-La; and explain a bit about "Groups". vB intended these to be social groups. But that is not what we want them for. We can and should use them for smaller "communities" to transact their stuff. For instance, someone mentioned geographical groups. Here the people in the group can plan shop crawls and lunches, etc.. Groups could also be "clubs". For instance there are 2 of these already in user groups, but they would be better served as "groups". instead. Some committees could work better in these groups. And finally, what will be the most important use of these groups, is for the Wiki. Wiki articles are collaborative. But we can't have 600 people all editing and comment on an article while in the development phase. So the wiki we using is designed so a Group can have control of an area. Those still self created group can control the development of an entry or related set of entries.
Yes we could do the same thing with the original Usergroups. But with these new groups. there is almost no additional work for staff. A user who is given permission by their Usergroup can create a group with a specified purpose. This group leader is allowed to decide who is in the group by invites or by join requests. They get their own discussion area, photo album, and some other things. It will be a very useful tool.
I set up a test group and started playing with it. That's were the reported post came from and the knowledge that our permissions in the usergroups, for groups, were not really any good. As I went to fix it, it became clear that the my original usergroup structure that is 6 years old and has had new requirements laid on it constantly, needs to be re-vamped. Otherwise I won't get groups working and the other features we want. The Admins will spend their time searching for incorrect permissions.
So, bottom line, I need to re-design the way the different usergroups are related to one another and which are primary and secondary. This sounds terrible, but it is not. To our users, the end result will not even be visible. But while I am doing it, there will be a lot "you don't have permissions" for that messages flying around. This will last for several hours. I will probably start this tomorrow , but when I do I will post a message about "Transient Problems: with permissions. Now you'll know why.
