Tiger's Tales

Permissions are all about allowing people and groups of people to do things. At least, that’s the model I’m using. There are two others… Allow everything then indicate restrictions (but that can have dangerous security issues), and mix permissions and restrictions together (but that can/will get messy and confusing).

So if you’ve been following the examples in this blog, you may have gotten the feeling that those dummy permissions I was using may not be so dummy. I did try to keep them self-consistant as I went along, even to the point of going back and tweeking them a bit. I’ve been trying to find a system of encoding permissions that is compact and clear, while retaining the ability to design-in more later. “More” both in number and in variety.

Here are a few that I’ve used so far (with small updates):

• Land Access – Unlimited
• Group IMs – Can Start and Use
• Group Inventory – Can See and Take Only
• Rez Objects – 100 prims
• Teleport Other Here

Notice that most are composed of two parts separated with a dash. The general idea is that some permissions will have extra parameters or settings that can be adjusted when the permission is added.

Oh, but first: adding permissions. You’ve seen the little symbol next to the Permissions header in the examples. Clicking that is how you add a new permission to the list, through a New Permission window that pops open. In it will be a list of all permissions in outline form. Why an outline and not just a bunch of fields and checkboxes? So new permissions to match new features can be easily added. Each entry in the list will have a sub-list of one or more options. Let’s try the examples from above:

• Land Access
• Unlimited
• With Ticket Only
• No Access (disabled)
• Group IMs
• Can Start and Use
• Can’t Start, Can Use
• Can’t Start or Respond
• Can’t See (disabled)
• Group Inventory
• Can See and Use
• Can See and Take Only
• Can See and Give Only
• Can See, Can’t Use
• Can’t See, Can Give (Drop Box)
• Can’t See (disabled)
• Rez Objects
• Unlimited
• Parcel Max
• Prim Limit: [ 100 ] prims
• Not Allowed (disabled)
• Teleport Other Here
• Can
• Can’t (disabled)

As I wrote the above example, I started with checkboxes instead of radio buttons. So Group Inventory had only three sub items: See, Take, and Give. The problem with that, however, is that certain combinations, namely “can’t see, can take”, are invalid. The list could be coded to gray-out the “take” if the see isn’t checked, but then you are putting interrelationships in there that aren’t visible to the user until they stumble across them.

Also, the general idea is that the title of the permission changes to reflect the options set within it when it closes. If checkboxes are used, then some internal mapping would have to create this string based on which options were checked. Then you have a dissimilarity between the collapsed and expanded permissions.

Overall, I thought radio buttons would be the clearer option, even if they can get to be a bit more wordy when expanded. What you see is what you get.

For the inline values, clicking them would either open a dialog box with an editable text field or edit the value in-line, depending on the whim of the interface coder. Accepting the changes in a dialog box changes the value in the outline.

The options are listed most-permissive to least-permissive, and the option marked with “(disabled)” is the one that will remove that permission completely. It will no longer appear in the Role we are editing in the Group or Land or Object permissions list.

Any permission that can’t be easily summed up in a single list of radio buttons would be split into several different permission entries. Hopefully, there won’t be any inter-related permissions that are too complex to be combined.

Now just to clarify the whole picture… You only see the non-“(disabled)” permissions in a Role. When you click the little to add a new one, the window that opens lists all of the permissions, including the ones that are already set. The ones that are set will have the same extended name (after the -) as they did in the Role’s list, and when expanded show that option as selected. The items that were not visible in the Role are red with no extended name. You would expand one of those and change its option selection to enable it. While in this dialog, you can edit any of the existing permissions or even add more than one.

I’m going to add the edit icon next to all future Role mock-ups along with the remove icon so the permission dialog window can be opened directly to that particular permission for editing (or removal), expanded.

That seems to cover how to add, edit, and remove permissions from a Role… At least, all that I’ve thought up so far. 🙂