Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2005-10-17 04:10:11

zem
Developer emeritus
From: Melbourne, Australia
Registered: 2004-04-08
Posts: 2,579
Website

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
tstate

Offline

#2 2005-10-17 05:06:43

Zarabadoo
Member
From: Denver, CO
Registered: 2004-03-14
Posts: 28
Website

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
Website

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
tstate

Offline

#4 2005-10-17 05:38:04

Zarabadoo
Member
From: Denver, CO
Registered: 2004-03-14
Posts: 28
Website

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

#5 2005-10-17 12:10:05

ubernostrum
Member
From: Lawrence, KS
Registered: 2004-05-05
Posts: 238
Website

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

#6 2005-10-17 12:50:13

Sencer
Developer emeritus
From: cgn, de
Registered: 2004-03-23
Posts: 1,803
Website

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

#7 2005-10-17 13:32:07

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,284
Website

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)


Wordworkin’ for you.

Offline

#8 2005-10-17 13:32:39

ubernostrum
Member
From: Lawrence, KS
Registered: 2004-05-05
Posts: 238
Website

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 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).

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

Board footer

Powered by FluxBB