(OR: How to Stand Out From a Barrel)
In my last entry, I used a lot of concepts that I might have mentioned in passing in one of my many forums posts, but never wrote down here in the blog in any detail. In fact, in the last entry I used a new term for something that I’ve given many names to over time. I can’t take credit for the final word choice, however. I first heard it from Linden lips in this week’s Groups/Covenants meetings.
The word is: ROLE
But what is it? If you read the last entry, you should have a good idea of the basics. (And if you haven’t, you probably should. I’ll wait.) But in short, a Role is a “special member” of a group. Well, not THAT special…
Right now, groups have only one special member type: the Officer. Everyone else is a Member. But needs change, and so will groups, so what follows is my take on Roles and how they will work…
Everyone in a group will now be a Member, forever and always, for so long as they are a part of that group. The Member list is everyone that has joined but not yet left the group, regardless of any Roles they may also take on. Roles are like job positions within the group.
When a new group is created, there is only one Role, which I’ll call “Founder”. I made the group, I’m in the Founder Role. I’m also in the Membership list. There’s always a Members list, and everyone in the group is always in it. And there is always a Founder Role, with at least one person in it.
For both these lists, there is a set of permissions. The permission set for the Founder(s) can not be changed. Founders have full permissions over everything in the group. Unless you truely trust someone, or are passing on the reigns, I’d suggest NOT putting anyone else in the Founder Role. You can remove yourself from the Founder Role only if someone else is in there. To do otherwise would be to disban the group.
If I invite someone to the group without specifying a Role in the invite, they just become basic Members when they join. (Though I can always add them to a Role later, as could anyone else that has the permission to do so.) If I do invite them to a Role, then they are part of the Member list AND the Role the moment they join.
The Members list, except for that fact that everyone in the group is in it, is otherwise just like a Role. It has a name, a description, a title, and a set of permissions as to what all members can do, just like a Role. The general idea is that this is the most restrictive class of permissions in the group. Any permission granted by a Role will override a lack of permission in the Members list. Meaning, if the Members can’t talk in the group IM window, but one of Bob’s Roles can, then Bob can talk in the IM window.
A player can be part of as many Roles as there are in the group. A player’s sum permissions are all the “Can”s from all their Rolls combined. Being removed from a Role will withdraw any granted permissions unique to that Role. When selecting a title to go over your avatar’s head, you pick from both Groups AND Roles. (Hmmm… It may be easier on the system if your current permissions were JUST of your active Role instead of a sum of all your Rolls in alll your Groups. It would be more confusing, though. Anyway, it’s just a thought.)
A Role can be empty, have just one member, or have many. Every member of the group could have his or her own private Role, though I’d hate to have to manage something like that for a large group. More often than not, a group will have just a few rolls, or even just the two you start with… If you are just making a book club.
Now that I’ve gone over Roles here, you might want to go re-read the last two paragraphs of the previous entry and see how the examples there feel, knowing what you now know about this system. Hopefully, it will feel simple and elegant. 🙂
Next: Stay Flat or Go Hier?
6 Comments
It does seem simple and elegant but requires a one-to-many end. What I’m reading is a system that allows me the ability to subgroup members into “roles” and assign permission sets to those roles. That’ll surely work.
But granting the ability to associate members with more than one subgroup opens a can of live grok. Unless we can create superroles that are named groups of roles to which someone can be assigned thus inheriting the rights of each subsubgroup. Did I miss that?
Here’s the kicker though. I love the idea of being able to share a parcel of land with GroupFoo:RoleFoo; that’s just plain brilliant and, coupled with the ability to formulate superroles, really should accomodate most, and I do mean most, organizational needs.
For clarity, I do understand that multiple members could be bridged to multiple roles in the database. But considering that LL works very strictly to maintain centralized systems, I’m thinking that only a hierarchical scheme will be considered if for no other reason, because it’ll vastly simplify the interface design. They tend to work from the UI backward or I am a monkey brain.
All of my designs prior to this one used a hierarchical arrangement of Roles. But it was while I started to write this up in detail that I found it would just be too complex to maintain easily. Finding things nested 5 levels deep (or more) would be a nightmare, and the only thing you get for it is the ability to inherit permission sets between Roles. Even that might be more trouble than it’s worth, what with issues of restrictions vs. permissions and whatnot. (I can explain what I mean by that if it’s not clear.)
No, I thought a flat list of Roles would be easier to maintain, and it can do any structure that a hierarchical arrangement can do. The final goal is to say: “Here is Role SuchNSuch, and here is what members of it are permitted to do.” A flat arrangement of Roles says that in the clearest way.
The nice thing about this system is that, while each Role has a set of permissions, and members can be in several Roles… Each member has just ONE permission map. An ideal interface for the group would have both a Role view (listing the Roles, each expandable to see the permissions they grant and its list of members), and a Member view (listing all members, each expandable to see what Roles they are in and what their final permission set is).
So if Bob was spamming the IM list with ads, I could bring up the Member view and scroll down to him. Toggle his entry open and I can read his total granted permissions and see that he’s in 3 Roles. I can expand each of the 3 Roles to see which is granting him IM privaleges, and then delete that Role from his entry, thereby removing him from it.
Or if I knew that only one Role grants IM privaleges, I could pick that Role from the list of them in the Role View, find Bob’s name and delete it there, removing him.
“I first heard it from Linden lips in this week’s Groups/Covenants meetings” 😉 and me I thought I saw a comment by you on my forum article regarding roles a few days before. 😉
“Roles” are nothing so terrible innovative, but a rather common solution in complex IT systems (have a look at http://en.wikipedia.org/wiki/Role-Based_Access_Control if you want to know more about basic theory behind it). The basic principle is much, much older even: it is “indirect definition”. That’s why the idea of roles is related to “style sheets” for example.
BTW 1: it is very uncommon to have a hierarchy of roles in such systems. This functionality carries much more problems with it than it solves. It is much easier to combine roles (give one person more than one role).
BTW 2: you mention somwhere the idea of roles “taking away” permissions. I hope thats not an integral part of your concepts. Its a bad idea and can lead to much confusion because it would make assigning roles a non-commutative operation (unnecessary complex and hard to grasp for most “normal” people).
Well, that explains why the Lindens were using the word. I’m glad the concept is already well established. Means I wasn’t barking up the wrong tree.
And no, I dropped the heirarchy idea as unworkable as mentioned in the “Stay Flat or Go Hier?” entry. As well, by keeping the arrangement flat, there is no need to mess with the mess of removing permissions.
Some people might get upset when they find out their idea has already been had by others in the past. Me, I’m always happy to hear it. It means I ain’t wrong… At least, no more wrong than everyone else. 🙂
I realise you’ve moved on from this post, but I had an alternative idea about it.
You define any number of roles, which may or may not be occupied. Your ‘Lot 1 tenant’ role and your caretaker role to use the examples that are running through here.
When Bob, the Lot 1 tenant becomes Bob the Lot 1 tenant AND caretaker you OR together the permissions to create the new Bob role. Both the old roles persist so if Bob leaves your land, or quits as caretaker he’s easy to move back to an old role. Computers are pretty efficient at manipulating flags in such a way, so it’s a quick thing for the servers to do. Setting up an interface to let you do it, in many languages, is pretty easy.
Of course applying all these permissions etc. may be harder, that’s where the struggle will be no doubt. How much extra load does it put into the system to check what each individual can do where they are? Some places that’s not too bad – in a whole sim plot for example, but in a sim full of 16sqm plots it’s going to be a nightmare.
I think we need a revisit of these things but I just might take a lesser option than this that meant I could build relatively easily on my own land and on other places where I’m allowed to and so on and so on.
Some of the other things – officers not selling land for example – are basically restrictions on the current system rather than a complete rewrite and might give us a system that, although sub-optimal, is a good balance between usability as a group system and usability as a resident experience.
I’m all for intermediate steps to get where we’re going. I just want to make sure we KNOW where we’re going so those small steps are at least in the right direction. 🙂