Wedge
Public area => The Pub => Features => Topic started by: Arantor on March 26th, 2013, 02:03 AM
-
So, I've been noodling around with this, and nothing I'm happy enough with to provide screenshots of yet, but let me explain where I'm going and see what you think.
There are a great many issues with the permissions UI and structure.
First up, regular group permissions. I'm still working with what I proposed in http://wedge.org/pub/feats/7662/permissions-ui/ - namely a single big table with all the groups along the top, the permissions down the side, and all the permissions shown there.
There are several bits I'm not entirely sure about, like exactly how you set the permissions. I don't really want to present a minefield of buttons to the user, nor do I want to present a minefield of <state> <button to change> Maybe I'll have it click to change the permissions for a given group <-> permission, but that could get clunky if there's a lot of changes you want to make. Maybe it should be a dropdown for each one to select the state.
This makes me wonder other things. I'm not averse to exposing 'deny' permissions generally. However, what I am concerned about is the mentality. A/D/X is confusing. Elsewhere (board access) we use Yes/No/Never to represent that states, and we need to get a bit more consistent - I'd be happy dragging Yes/No/Never over to permissions too.
Another system I'm liking has two checkboxes, rather than radio buttons - one for allow, one for deny. I'm not sure what I'm going to do yet, would appreciate thoughts.
Note that I'm looking to remove the 'default profile' being shown underneath the general permissions, but the whole nature of that I'll get to in a minute. I would also be tempted to remove some of the other stuff in the admin pages, like 'setting permissions for one group like another' - basically if you go to the permissions page, you get the list of groups, then some stuff below those groups for things you can apply to the groups; setting 1+ groups like a template, setting a single permission on each of the ticked groups. Seems to me that a single big ol' list would negate the need for that. Permission copying would be reasonably simple too.
There was a concern previously about fitting it all in - while this is not a huge deal for the most part (inherited groups wouldn't be shown either, to save space), I'm also looking at using http://fixedheadertable.com/ - you'd keep the group names and the permissions in view at all times and scroll across to fit.
I don't think there was any real objection, but I think now I'm looking at it again, I'm having second thoughts on the idea - but I also know I don't have anything better to solve the problems I want to solve. I don't want to get into huge scale re-engineering if the idea doesn't feel sound, and right now this doesn't.
Board permissions. Ah, yes, I couldn't forget this, could I? I've been looking at what SMF 1 did versus SMF 2, unique board permissions vs profiles and I think I might have a better solution but this is sort of off the cuff. If I said it came to me while I was sat on the toilet you'll hopefully understand.
So, let's recap, first of all.
SMF 1, for those who never used it, had the notion of global versus local board permissions. You'd set the permissions for each group generally, and if you had a board whose permissions were different, you could indicate as such and get unique permissions for that board.
Conceptually that's fine, until you have two or more boards that need the same-as-each-other but unique-compared-to-everything-else permissions. Incidentally, sm.org has this very setup, there are boards that have different permissions to any other (namely showcase, but some of the internal boards have that going on too)
Meanwhile, SMF 2 has the idea of profiles. You have some template profiles (but one you can actually change despite the system telling you that you can't, which I'm still not sure isn't a bug in disguise), and you create new profiles to apply them to the relevant boards. Great for managing boards with a few tiers of boards where you only have a few sets of 'permissions'.
Then we have SimpleDesk. This did something a little bit different: permissions were expressly not tied to groups. You create roles, which are essentially groups of permissions, then you say 'these groups, have these permissions, in these boards'. For example you'd create a staff role, which had a bunch of permissions, and all the time they were in those boards, they had those permissions. It was a bit ropey in places because I abused the concept in two interesting ways.
Two options present themselves, ultimately.
Firstly, I can take the SD route. The UI can be nicer this time because I don't need to pull stunts around 'non board permissions', I can safely have the UI abstract that stuff away. But I'm not sure how well the 'groups != roles' concept will get across and I'd hate to lumber us with 'how do I set this permission up' crap.
Secondly, and perhaps more confusingly in a way. I can sort of regress back to SMF 1 permissions. I'd envisage it being split between permissions and the board configuration area, or at least... mirrored that way.
See, what I'd envisage doing is giving a list of the board type permissions, and the groups again - like above. Only this time, with an extra dimension to it. For each permission, you'd select the list of groups who have it/don't have it, but there's an extra option: apply to all boards. If you say 'apply to all boards', all the boards the users can see would be able to have/not have that permission. For example, posting replies would typically be yes to any group who can see the board in question. So you'd just have that as 'all boards', and just set it to the groups who reply.
If you decided you didn't want it as all boards, I'm thinking that the list of boards could fold out underneath to indicate that permission for that board/group combination. I think it could be thoroughly ugly, but I think it would be more intuitive than the current permissions setup.
Then you could go into a given board and see how it is in that given board, and configure it that way too. It would be back to local vs global permissions but easier to configure for simple changes. Of course if you have a lot of boards, changing things is going to suck very, very quickly, which is where profiles win.
More importantly, newbie factor. Setting up roles is not the most obvious thing, especially if you want people to be able to dive in and just set up a forum quickly, though I guess if sane roles were defined out of the box, that might not be a bad thing and it would probably clue most of them in on how to do it. But seeing the confluence of boards/groups/permissions should be marginally easier to follow - and still more compact than the current reporting methodology (which could also go bye-bye in the process)
/medoes not normally want much in the way of external validation, but this is a *big* thing to get right and I want to involve everyone as much as possible because it's also one of the most fraught areas of setting up a system.
Note that all the things I have in mind down the road about other content types can slot into what we have here with little change on a purely technical level, so this is almost entirely a UI problem. UI says it must be so, everything else will be kicked into line.
I don't know. I honestly don't know what's best out of all this. I just know that I don't like how SMF does it and by extension how we do it. I've been wary for some time of making big changes because I've been frightened of creating a worse mess than we already have. But I'm also not sure it can be *that* much worse. So, over to you. I'd love some thoughts on this, even if it's only to tell me whether you like or dislike it. Remember: you're the people who are ultimately going to be *using* it.
Of course, I'm open to other ideas. If there's any other system you've seen that you like the look of, tell me and I'll see what I can do to find out about it, including figuring out what's good about it. I'm not averse to drawing on any system out there - if the system works, I want to see it :)
-
How about something in middle? Revert back to the original SMF 1 type board permissions, but allow some boards to follow other board's permissions. Something like "Set same permissions as <insert board name here>", this becomes sort of like profiles without the actual profiles type thing.
-
It's all so complicated.
Still my only suggestion is to add more complexity. Have a new 'by permission' area in addition to by member group or by board. Once the year chooses a permission, allow them to change it at once for all boards or members.
This would help with new plugins that add a new permission. Heck they could even quick link to this.
-
I think the most simple UI for groups would be the deny permissions + the ability to set per users exceptions (listed somewhere under the groups perms, maybe with a limit of X exceptions the admin can add.
-
I think if, it's at all possible, to have per board and per add on permissions.
So when creating a board you can set permissions for that board, and or plug-in and the ability to edit such permissions, by the admin clicking on such board or plug-in. Maybe crazy, just and idea.... this sort of the way TP is set up, along with this you can edit where the boards/plug-in/mods or what ever you want to call them will appear?
Later when it comes down to ou plug-in options, this may or may not work!
Please remember I'm not coder and this maybe way off course!
regards,
Maxx
-
I think if, it's at all possible, to have per board and per add on permissions.
So when creating a board you can set permissions for that board, and or plug-in and the ability to edit such permissions, by the admin clicking on such board or plug-in.
What bothers me about listing it in the board area is simply how big that page is going to be. If you imagine that in the board area you will have the board configuration stuff, plus one - and sometimes two - lists of groups who can see that board, there's really not a vast amount of space to put a huge list of things in it.
But even if we did, what about the presentation of it? You know, that bit I spent a third of the post talking about...I think the most simple UI for groups would be the deny permissions + the ability to set per users exceptions (listed somewhere under the groups perms, maybe with a limit of X exceptions the admin can add.
Still my only suggestion is to add more complexity. Have a new 'by permission' area in addition to by member group or by board. Once the year chooses a permission, allow them to change it at once for all boards or members.
How about something in middle? Revert back to the original SMF 1 type board permissions, but allow some boards to follow other board's permissions. Something like "Set same permissions as <insert board name here>", this becomes sort of like profiles without the actual profiles type thing.
-
Copying or inheriting? The two are subtly but very importantly different.
-
Inheriting can be problematic, it's why I deliberately went with copying for SimpleDesk.
See, I'm trying to keep it simple - and inheriting, or copying for that matter, is not necessarily a simple way to do it.
-
Inheriting can be problematic, it's why I deliberately went with copying for SimpleDesk.
See, I'm trying to keep it simple - and inheriting, or copying for that matter, is not necessarily a simple way to do it.
-
XF does it slightly differently, though to a point it has a certain amount of sanity to it.
Group permissions are again handled with what amounts to Yes/No/Never (though they call it "Not Set (No) / Yes / Never"), with the permissions being selectable per group (you see each group one at a time, fairly comparable to what we have)
Board permissions... well... node permissions, they call it. In Node Permissions, it is board by board permissions and again has the triad, though here it's called Allow/Revoke/Never, but means the same thing. Just for fun, though, they have 'inherit' as a 4th option, which means to inherit from a parent, e.g. parent board, parent category - since everything is inherently a child. Here's the clever part: what 'board' permissions are is also set at the group level, so you can tell it to inherit from that, and only change it per board if you need to.
It's actually quite elegant in a way, but I dislike the fact that permissions in one thing are explicitly set from somewhere else :/
-
I know one thing, it's quite an elaborate mess to code with. You can't query against permissions directly like SMF.
-
*nods* Here's the thing, incidentally. If I were to implement the style they have (global then per board variations), allowedTo() would pretty much work without modification. I'd have to fix boardsAllowedTo(), though.
You can see why I take this stuff so seriously: because I want it to be nice to code against as well as nice for the end user and I'm not entirely satisfied that any of the paradigms out there actually work all that well :/
-
Just thinking out ...
Not certain what you guys already have done, too much for me keep up with. so I'm going to say that could there be Two ways to edit and set permission, at the install when the board or Mod is set up and when viewed by the admin or moderator, they can use the edit icon to edit that mod or board?
The staff can access them faster and easier, make corrects as soon as they are found! As far as style I would suggest that the style be inherited from the present or current template, if this would be possible. to match the situation ( looks) or set all backgrounds transparent?
regards,
Maxx