News:

Looking for a good read? Check out the SimpleDesk Team Blog.

Main Menu

The new permissions system in SimpleDesk 1.1

Started by Gruffen, May 12, 2010, 01:35:50 PM

Previous topic - Next topic

Gruffen

Before I begin explaining what we've done, I'd like to open this with a thought, because I also want to cover *why* we did it.

Should you accept what is there because it's how everyone else does it? Should you accept how other packages do things because that's what's expected?


I suspect many of you will already know my answers to these questions, being no to both. I'm a believer in innovation, doing things differently not because you can, but because you should. Nothing is perfect, if it was it would put others out of business.

It was (and is) a constant source of frustration to me that people wanted things "like xyz". Not how they actually want it, not how it would work best for them, but out of some possibly misguided view that what works for someone else would work for them.

And I suspect you'll find that motif running through SimpleDesk in plenty of ways, in its code, in its approach to how it makes changes (for example, most mods make changes to what actions (index.php?action=...) by modifying the master list where it's set up - we never, ever did that and did it afterwards in a manner that was more compatible with other mods)

Doing something the same way everyone else does it is boring, and doesn't give you the imagination to do something a little different even if it works better.

And so on to permissions. It's a dull subject at the best of times, since really all you're doing is ticking a set of boxes as to what people are allowed to do. But while it's dull, there's no need to present the user with page after page of options unless you really have to.

As such, we refitted the entirety of SimpleDesk's permissions outside of the main SMF permissions area and in the own menu inside SimpleDesk's admin area. It's not a change done for the sake of change, though, it's a necessary change that - while we were at it - we figured we'd do something a bit different in the process.


1. Usability / aesthetics

Don't get me wrong, I've been using SMF for years and its permissions dialogue is functional. I even still use Classic instead of Simple in 2.0 because I'm that happy with it.

Except that it's ugly, especially if you have to cram a lot of permissions in it.



It works. You can set all the permissions. But there's a lot of wasted space. It's also not really that intuitive.

And if you have to set permissions for multiple groups, it's a pain - so much so that one of our beta testers actually asked for "permissions all on one page for the groups".

It's very effective if you set permissions up right from day one, but most people don't, and in reality it's probably more confusing than not (even in simple mode) to someone new to forums.

Part of our mission, then, was to do something less ugly, hopefully more intuitive (or at least, no less intuitive) and be able to scale up over time as we add more permissions.


2. Functionality

We used SMF's permissions for 1.0, it was convenient and easy to expand one-dimensionally (more permissions). But one thing we knew we'd be adding later is support for departments, which potentially means permissions will be different in different departments (it normally will be).

With that alone in mind, and knowing that we would be adding more permissions than are in 1.0 already (even as it is for 1.1, there's at least 6 new permissions that aren't on the above screenshot (IP visibility, view/create/delete relationships between tickets, split ticket, merge ticket) and that's without even finishing other stuff we have.

SMF does have some features for dealing with more specific permissions - board level permissions, but really, hacking department support into the board level permissions system is ugly, inefficient and quite simply unprofessional in my opinion. (While I've used similar hackish approaches to things before, for something the size and complexity of SimpleDesk, to rely on abusing an existing system, it's just wrong)

So we knew we'd have to do something about this.


3. Mindset

Here's the really big thing that made us do this fancy new system. SMF groups just don't translate well to a helpdesk. Let me explain the problem.

In SMF, you have this idea of membergroups. They're ways of grouping users and dishing out permissions, but at the end of the day they're just groups of people.

I think most people understand what the Administrator group and the Moderator group are about and why they're not just regular groups. True, they are groups, but they're *also* roles. They have permissions that tie into the role, by default. Sure, you can turn almost any other group in to something almost the same, but they're not going to be the same, because they're different on another level.

It never sat right with me about how permissions did/didn't work in SMF for this reason, at least in the helpdesk. I always thought it was kind of lame we defined who was 'staff' based on a permission that the forum admin sets, though I couldn't really see a better way of doing it. (The fact that, right now, that's how it's done internally is entirely a different story, but heck it's convenient)

So what we've done is separate SimpleDesk permissions from being directly attached to membergroups and in the middle inserted roles. In reality this actually makes more sense for most helpdesk installations.

You have three basic types of role: helpdesk users, helpdesk staff and helpdesk administrators, and with the new system you create a role based on one of those three base types (which comes preloaded with a set of default permissions, which you can customise to your liking)

Once you've created the role, you attach membergroups to it from there.

Let's say, just for the sake of argument, we installed it here and allowed donaters to use it. (That's not the plan, don't get excited :P) But for the sake of argument, let's say we did that.

We only really need two basic roles: helpdesk users and helpdesk staff, since there's no real need to split the permissions up or anything.

So all we'd do is create a new role, called Users, based on the Helpdesk Users template, and a new role called Staff based on the Helpdesk Staff template (you get to pick your own role names, of course).

All we then do is say that the User role applies to Charter Members, and Staff applies to Developer, Support, Globaliser, Doc Writer, Quality Assurance, and so on.

We manage two basic sets of permissions (user and staff) and have it assigned to groups how we want it without making it more complicated.


*deep breath* That probably sounds like an awful lot. It is, really.

And without further ado, I present to you the two screens of interest, the main page and the permission selector.

Here's where you can see the templates (which form the basis for your roles) and the roles you currently have defined. The icons relate to the permissions a user has, and each has a tooltip to explain what the permission is.



Once you edit a role, you're taken to the main role editing area.

Firstly, you have the permissions that can be given:



We've tried to use the space a little better, and we think it's more intuitive than the normal permissions screen generally.

And you can tie membergroups to roles at the foot of the page:




And that's what we have coming in 1.1. We think it suits SimpleDesk better to do it this way, we find it easier to set up, easier to use generally and quicker to set up than 1.0's was.


Someone suggested that all big mods should do their permissions like this, and while on one level that would be amazing, on another it doesn't work. Not all mods need the same structure, or have the same requirements - this is just one way it could have been done, and it's one that we think works for SimpleDesk; I'm all for people trying new things, to find what works for them, that's all we did for this, after all, and that's something we'll continue to do in the coming versions of SimpleDesk.

MultiformeIngegno

#1
Great great great work! Simple and powerful!!!
I hope that it will be taken as example by others... and also by smf devs! :o ;)

Thanks men!!
RockCiclopedia (wiki - forum - tv)
Tutta la storia del rock, scritta da voi ...

...iscriviti al feed di RockCiclopedia dedicato alle ultime news del mondo della musica!

~DS~

All I have to said is...welcome and thank you for making SimpleDesk what it is today especially for 1.1  :)
"I was given the wardrobe of a nobleman, and so I played the part, a puppet ever dancing for the amusement of patrons unseen. This wretched world does not reward endeavour. It is the patron and his troupe who are receipt, maggots grown fat on endeavour's corpse. Most men but play the part they're given. Most live and die not knowing they play a part at all. But I am past all that now. I am their unwitting puppet no longer! No more! I will extract from them the price of their gluttonous feast! ~ Delita Heiral

[FailSafe]

Wow, that UI for the permissions system looks so beautiful. You guys really take every little thing into account which is awesome for a such a large mod like this. I mean, in order to see what Template the Role is based off of you have clear images that tell you instead of just having text that take up space. SD Devs really love to use their space wisely. ;)

This is a great site to see. Thats for posting it Arantor. :)

Gruffen

Well, I'll let you into a little secret on this one; normally, designing SD is fairly jointly done, we discuss it, thrash it out then we go build. That was mostly how the UI happened - Nas laid out the general design and we thrashed it around as we jointly implemented.

Sometimes what'll happen is I'll lay the foundations for something and we'll jointly thrash it out how it should look and feel; the post interface look and feel happened this way; I kicked off building it, Nas and I cleaned it up afterwards since I normally make it work first then worry about it being pretty after.

This time marks pretty much the only time in SD where I've done something mostly solo without getting too much in the way of feedback; once I knew how I thought it had to work, I explained the concept (not so well) in the beta tester's board, and the idea was greeted with a lukewarm reception, because I knew I wasn't explaining it so well.

It was tweaked from initial drafting to final implementation, but its structure never really changed that much from when I just sat down and started making, and the feedback really served more to confirm my own ideas rather than change direction.

What I think you'll notice is that Nas, who's designed more of the UI code than I have, tends to be a little more into polishing details - like the icons on the left of the ticket description page, as a trivial example - while I'm generally more minimalist, as the API docs tend to demonstrate.

What you see in the first screenshot of our permissions, with the two columns and headers and images, didn't always start out quite like that, though it carried through the sense of minimalism from my original idea:


Step 1: I wants pretty icons. Also a tech test of the base template system.


Step 2: The icons aren't just pretty, but actually functional.


Step 3: You can actually be too minimalist.


Step 4: Space may be big, really big, and you may think it's a long way down to the chemist... but there's no excuse for wasting half the screen like that.


That said, even the dropdowns was something I didn't implement immediately, since I wasn't sure whether to run with radio buttons, or tickboxes, or dropdowns, so initially I tried it without, to just get a feel for it.


Step 1: Yes, you've spared the translators yet more work, well done.


Step 2: Decision made. Except it looks kinda ugly. Maybe this wasn't such a bright idea.


Step 3: Ah, that's tidier, and look, playing with browser specific coding! ;D


Step 4: Almost there. It looks even usable now. Sadly the browser specific code had to go since it was Firefox only :(


Step 5: Spit and polish and we're good. Text strings are shorter, icons are smaller and better spaced, the columns are better spaced.


For better or for worse, I think this has been the one UI I've fully implemented from scratch. Every other change to UI I've made so far has been to build on what's already there, or extend it, or fix bugs in it, ranging from extending the display template with ticket relationships, or making the post template as based on the ticket template, or adding then refitting attachments, but here I mostly flew solo. I'm not overly comfortable doing it, generally - I much prefer us to work closer together and talk about things before implementation, but this had been sat in me for weeks, even before I opened the discussion on it.

Unlike just about anything else in SD, I had to build it all in one go as opposed to building it in stages, which I think is mostly why it was autonomously developed, or with me saying "This is how I'm doing it, and here's what I'm doing next..." knowing full well I couldn't do it in bits.

It's definitely been an interesting experience, not only in terms of approaching an existing problem from a new angle, but also with how I see my own skills; I don't normally get into UI because I don't see myself as a designer, to the point of actively avoiding it where possible (it's no small part as to why I hated writing mods with theme edits)


Oh, for the record: this took a total of 9 days from starting to draft the first code through to final implementation where we are today, and that includes not only making the UI but rewriting major parts of how SimpleDesk is initialised to ensure permissions are loaded at the right time. I think that's the longest spent thus far on any individual component of SimpleDesk, even attachments didn't take that long.

Niko

Looks very nice. Maybe I can use this to improve my mods too.

Gruffen

Hey Niko :)

All the code's BSD, so you're good to use it, but it's kinda messy under the hood :( Not really sure how best to fix that though, because this isn't just an interface to the normal permissions tables, but a totally different system that runs parallel.

The one thing it doesn't actually allow is the case of denying an 'any' permission while allowing the matching 'own' permission but that's something that could be worked in if people really really wanted it (and to be honest, it's not exactly a major oversight in practical terms, since this naturally tends towards being less permissive than SMF's system when applied)

Let me know if there's anything I can help with on it.

Bᵃ

Love it. :) Kudos, Arantor. This is definitely an improvement.

B

Conquer Club - Free Global Domination Game
Think the board game Risk on steroids!

Gruffen

I just wanted to add, actually, there's one more bit I just committed to SVN - where you can see the permissions a user has.

This is a slightly contrived example, but it illustrates how it works (and shows off some of the new profile stuff we have :P)



This shows you the permissions structure for user 2, test. He's a member of the GMod group, which I've assigned to be both the Users and Staff roles (which are just based on the templates for testing purposes)

Key thing here is that a lot of the user permissions are 'missing'. Well, actually, they're not, they're deliberately removed to avoid clutter.

In SMF's 'Show Permissions' area, you get two entries when a permission applies to 'own' and to 'any', e.g. 'Post replies to topics - Any topic' and 'Post replies to topics - Own topic'. While that might be reassuring, it's actually fluff, and possibly even confusing; a user that has post to own topic denied, would still be able to post in their own topic if they have post replies in any topic, since own and any are independent, rather than linked.

Here, 'Reply to tickets - any tickets' is granted by Staff. The Users role does grant reply to own ticket, but since reply to own ticket is covered and replaced by reply to any ticket, there's no need to state both, since I take the view that if you're establishing a user's permissions, you really want to know the extent of their permissions, not all the stages leading to it. (E.g. for a bank, if you have loan approval permission, does it matter if you can sign off £25,000, or £50,000, if your limit is £100,000? You're only interested in that £100,000 cap - is it that obvious that I used to work for a bank as an approver?)

If the exact same permission is granted by multiple roles, that's shown too.

Anyway, that's it from me for now on permissions!