Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2005-10-17 04:10:11
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Assignment: section permission design
A section-specific permission or restriction feature is a common request. But I haven’t heard anyone suggest how it might work, beyond “uhh, restrict authors to certain sections”. But even the simplest idea is actually a lot more complicated than that.
So, we need suggestions on how this might work. How are users assigned to sections? By name, permission level, group, or something else? Can users have permissions for multiple sections? How does this relate to the (currently) 9 different article permission levels set in admin_config.php? Can users see restricted sections? Can they access its article list and/or article edit pages in read-only mode? How are deletion privs handled? What about the page template and style for restricted sections? Do categories come into it at all? What would the user interface look like? Can it scale to include extra permission and user types if they’re added later? etc.
Alex
Offline
Re: Assignment: section permission design
zem wrote:
So, we need suggestions on how this might work. How are users assigned to sections? By name, permission level, group, or something else? Can users have permissions for multiple sections? How does this relate to the (currently) 9 different article permission levels set in admin_config.php? Can users see restricted sections? Can they access its article list and/or article edit pages in read-only mode? How are deletion privs handled? What about the page template and style for restricted sections? Do categories come into it at all? What would the user interface look like? Can it scale to include extra permission and user types if they’re added later? etc.
Technically, the whole permission system needs a little bit of an overhaul. I would think the ability to modify permissions of the groups (or individuals) is something that shoudl be handled through the admin panel. Something more than selecting a group that has to have it’s permissions modified through a config file on the server.
The group/individual should be able to have things like article approval, design access, and section control handled by easily checking things off in the permissions. At this point I wouldn’t worry too much about an individual, but jsut make the groups themselves more flexible. Make it so we can add groups, delete groups and change permissions without having to open a text editor. Once this is done, it will be much easier to move on to section specific options.
One other thing to do is to make it that if permission is denied to a group, those tabs should not even be visible to a person in the admin panel. (I have noticed the dropdown menu also doesn’t exclude areas of admin.) The changing of passwords and user info really needs redone too. It is the one area that gets hidden from users that shouldn’t be. They should be able to go in and edit their information without having to use a plugin to do it.
All should be pretty simple to be laid out as long as we give group and user control it’s own tab. You can bring up a group like you would any article, but it would have all the possible permissions available laid out in a list. All an admin has to do is go in and start marking off how they prefer the permissions to be. I would have to assume that scalability would not be a problem with this option. The database would just contain what would come down to on or off switches, and if there are mor epermissions added later on, you just tack them onto the end of the list in the database. I am also not a coder though, so I could be very wrong.
One problem I am having trouble figuring out how to assign permissions with is design. It may require a bit of a rewrite in the core code to get it to function optimally. There is a lot of shared templating code between sections. In recent revisions of textpattern, it is getting even easier to do with all the conditional statements that are available (which I am loving to death personally). This can cause a problem when different people are working on different sections: you don’t want to break one page while fixing another. It may require certain templates, forms and CSS to be assigned to a specific section. The designers would be able to use any for they wish, but if they want to alter it, they would either have to get with the maintainer of the other section’s code or create a copy for their section to edit. The bloat of several variations of a templates forms may be a bit of a turn off to some, and I can see why there would be resistance.
I hope this rant makes some sense. It is mainly just and instantaneous stream of consciousness. Mainly some preliminary thoughts on the matter and will definitely need some fine tuning. In any case, I hope it generates some thought.
—Al “Zarabadoo” Steffen
http://www.zarabadoo.com
Offline
#3 2005-10-17 05:15:17
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: Assignment: section permission design
I would think the ability to modify permissions of the groups
When you say “group”, do you mean the current user types (Publisher, Editor, Staff Writer etc), or some other kind of grouping?
I can imagine fairly common scenarios where it’d be desirable for a user to be an Editor in one section, and a Staff Writer in another, which might require an additional grouping type.
Something more than selecting a group that has to have it’s permissions modified through a config file on the server.
Sure. But we need to know how that might work, before we can build it.
Alex
Offline
Re: Assignment: section permission design
> zem wrote:
When you say “group”, do you mean the current user types (Publisher, Editor, Staff Writer etc), or some other kind of grouping?
I can imagine fairly common scenarios where it’d be desirable for a user to be an Editor in one section, and a Staff Writer in another, which might require an additional grouping type.
The user types. You can have the default setup of groups as you currently have them, but the option should be left open to rename, delete, create and alter the permissions for each.
The semantics for setting up the permissions per section is mind numbing. In fact, it is making my brain hurt a bit. Do we set up several different roles/groups system wide and assign them per individual and per section? Or do we have completely seperate groups per section, and then assign people to the groups? I am not sure wich way would be the most flexible with a growing feature base. One thing is for sure, the permissions settings would have to be stored in the database and not a flat file.
I hope this answered the question instead of creating more.
Last edited by Zarabadoo (2005-10-17 05:40:54)
—Al “Zarabadoo” Steffen
http://www.zarabadoo.com
Offline
Re: Assignment: section permission design
I know I keep mentioning it in comparison to TXP, but I think a great user permission model is the one Scoop uses. Here’s how it works:
Out of the box, Scoop comes with a sensible set of default user groups: “Anonymous”, “Users”, “Editors”, “Superusers” and “Admin”. The permission structure for each group is editable, but in general they do about what you’d expect. The group-management interface lists existing user groups and allows them to be edited, or new ones to be created. When creating or editing a group, a list of all permissions in Scoop is presented, and members of the group can have permissions added or deleted as desired.
Then on the section-management page, Scoop lists existing groups next to the section, and provides a drop-down box for each group, allowing an admin to choose whether users in a particular group can read that section, post to it, add comments to articles there, etc. This might be seen as duplicating the groups interface, but actually doesn’t; there are a lot of “behind the scenes” permissions that have nothing to do with article or comment posting, and the groups page is the logical place to list and control those (for example, Scoop’s built-in aggregator only allows user groups with the correct permissions to add new feeds that it will poll, and all of the administrative options can be enabled or disabled for particular groups — this lets you have, say, a “designer” group which has access to change the site’s templates and CSS, but not anything else).
Finally, site admins can designate which group will be used by default for new users, and can edit any user to assign him or her to any particular group.
For reference, here is the chapter of the Scoop Admin Guide which lists all the permissions and explains how the group-management system works, and here is the chapter on section management.
It’d be a heck of a job to replicate in TXP, and I’m not sure that it wouldn’t be overkill, but it’s awfully nice ;)
You cooin’ with my bird?
Offline
Re: Assignment: section permission design
> It’d be a heck of a job to replicate in TXP, and I’m not sure that it wouldn’t be overkill, but
> it’s awfully nice
It sounds like that would mean awfully lots of drop-down boxes or matrixes of checkboxes. If it means alienating a lot of the current happy users, I am not sure if it really would be as nice.
Don’t get me wrong, power and configurability is very nice, but you can’t unconditionally surrender to them as complexity may well make usability horrible. For example I love the power that the permission system of phpBB2.2 adds over the alreadScoop) – However understanding how to use them and taking advatange of that power got so difficult, that many users were struggling (and that is users that are already bold enough to use CVS and heavy in-development software).
Sidenote: Textpattern already uses groups to assign permissions (in fact we don’t have individual permissions) and moving the permissions from file to the DB and creating an interface for editing them, has been on the list of to-dos for months now (as is explained in the file itself, too).
Offline
Re: Assignment: section permission design
Zarabadoo wrote: One other thing to do is to make it that if permission is denied to a group, those tabs should not even be visible to a person in the admin panel. (I have noticed the dropdown menu also doesn’t exclude areas of admin.)
Not really help to zem, but I agree this would be a good thing. I think most people expect that if they can see a link, function, control, or whatever then they can use it, and it confuses them if they can’t…they might think something is not working properly, even if it is. I certainly would not like this as a user of an interface, but to me it would be a screen-clutter issue more than anything else. In short, if something is off limits to a particular user (as defined by user roles), make links, functions, controls, whatever disappear from their view for simplicity. I can tell you also this makes writing documentation about user roles a whole lot easier too. (You should never have to explain what a person can’t do in a user interface; the option shouldn’t even exist.)
Last edited by Destry (2005-10-17 13:33:52)
Offline
Re: Assignment: section permission design
Sencer wrote:
> It sounds like that would mean awfully lots of drop-down boxes or matrixes of checkboxes.
It does, at least as currently implemented.
> If it means alienating a lot of the current happy users, I am not sure if it really would be as nice.
I’ve been badgering for a while to do some redesigning of Scoop’s admin interface, actually. At the moment it’s certainly not elegant, but I think it could get there.
You cooin’ with my bird?
Offline
#9 2005-10-21 15:29:24
- Henrik Pejer
- Member
- From: Sweden
- Registered: 2005-10-13
- Posts: 23
Re: Assignment: section permission design
For those of you that want to be able to hide tabs that a user has no access to, here is a hack:
http://forum.textpattern.com/viewtopic.php?id=12133
Happy TXP:ing!
.:8):.
Offline
#10 2005-10-21 20:15:12
- KurtRaschke
- Plugin Author
- Registered: 2004-05-16
- Posts: 275
Re: Assignment: section permission design
> Sencer wrote:
> > It’d be a heck of a job to replicate in TXP, and I’m not sure that it wouldn’t be overkill, but
> it’s awfully niceIt sounds like that would mean awfully lots of drop-down boxes or matrixes of checkboxes. If it means alienating a lot of the current happy users, I am not sure if it really would be as nice.
Don’t get me wrong, power and configurability is very nice, but you can’t unconditionally surrender to them as complexity may well make usability horrible. For example I love the power that the permission system of phpBB2.2 adds over the alreadScoop) – However understanding how to use them and taking advatange of that power got so difficult, that many users were struggling (and that is users that are already bold enough to use CVS and heavy in-development software).
I think there’s got to be some way to strike a balance between the two. Obviously more flexibility is needed for some sites, yet I’m sure that at the same time there are plenty of TXP sites with one or two users who have no need for more advanced or fine-grained permissions. So perhaps what is needed is a “wizard” or whatever to set permissions for simple cases, with an “advanced” permissions editor also available for more complicated setups. Sort of like what we have with CSS now—it’s the same code, just two different ways of looking at it.
-Kurt
kurt@kurtraschke.com
Offline
Re: Assignment: section permission design
the Simple Machines Forum has a pretty nice permissions setup. You basically have a general set of permissions for each group, and then each section can either accept the global permissions set up previously for each group or person, or they can be modified specifically for that forum.
This would require quite the setup in the backend, but it would allow for a great amount of flexibility. Textpattern wouldn’t need nearly as many permissions as a forum, but in terms of semantics, it may work. I am going to look at Scoops system to see what I think, but the thought of dropdowns for permissions doesn’t sit well with me thinking about it.
As it stands, Textpattern is good for a small group of trustworthy people, but it’s funtionality and ease of use makes it great for larger groups and organizations. To me, the permissions setup is the only thing that holds me back from recommending it to groups other than friends who want a blog system.
No matter what path is taken, it is going to be one hell of a project and is going to take some time to get completely set up and coded with as few security holes as possible.
—Al “Zarabadoo” Steffen
http://www.zarabadoo.com
Offline
#12 2005-10-22 00:14:05
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Assignment: section permission design
My thoughts:
- Customizable admin group permissions should be separate from this.
- Current article edit/publish permissions should be separate from this.
- The section drop-down list of the article page should only give you the option of sections you are allowed to edit/publish to.
- Permissions to manage said section(s) should be unchanged, remaining underneath the admin prefs.
- Sections a user can publish to defined under the user permissions, with checkboxes, but in its own step page (“Article Section Permissions” or whatever) within the admin event.
- A preference to determine what the default user section permissions should be, what checkboxes should be checked (“all” by default) for each user by default.
How you’d go about accomplishing this I’d leave up to those more knowledgable, just what I would look for as a user.
Offline