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
#13 2005-12-20 06:36:23
- saccade
- Plugin Author
- From: Neubeuern, Germany
- Registered: 2004-11-05
- Posts: 521
Re: Assignment: section permission design
My suggestion (please help if my english isn’t precise/correct or if I don’t use the right terminology):
- It should be possible to create any number of group permissions.
Tabs could stay as they are (with the base set of group permissions as now), only an additional option “create group permission” should be added. See below the structure of the “create-group-permission”-menu.
- I think (personally) there is no need for an individual user permission.
Group permissions are applicable to 0, 1 or more users,
in most cases permissions will be not that individual to be usable for only one user,
and if you need individual permissions one by one, then you could create a “group permission” for every user. You then only have to give them precise names that reflect type and user.
- Regarding different permissions for one user in different sections:
As I see it, that are different roles one user plays within the site.
So it should be possible to assign more than one group permission to one user.
(Assigning a group permission could stay as now, with an additional “more”-link/button next to it ( see here ) if someone wants to assign more group permissions. in a pop-up-list (or something like that, see here ) you then could mark every group permission to assign).
When the user logs in or choses the write/edit tab first (or on top) he should be asked or chose which role/group-permission to use at this moment ( see here and here ) .
- Of course restrictions should be possible for every element (section, category …). Only this makes sense. E.g. if you have structured your site by design in sections and by content in categories it is essential that you can restrict users to contribute to special contents by category/categories.
- For every element (section, category …) there could be two options of permission:
“all” allows to use/chose from all existing options (functionality as now)
“subset” opens a pop-up-list and allows to restrict to one or more of the existing options.
For the user nothing needs to change.
With “all” he has the same list of sections/categories to chose as now,
with more than one option allowed in “subset”, he can chose between those assigned to him,
with only one option allowed in “subset” (and the admin can set which one) he cannot chose and has a fixed section or category.
So with “all” and “subset” all possible restrictions could be achieved.
- There should be an additional option in permissions, where the admin can chose how to show the article tab/list: “all” or “editable”.
So it could be achieved that the user has only those articles in the list he can edit.
Especially if there are lots of articles this would be an improvement for a user who has few own articles spread in the list. (or if he shouldn’t be able to browse through all other articles)
- It would be very good if you could set the default view of the “advanced options”-link.
If you work with custom_fields now a user has to chose “advanced options”-link, before he could see the custom_fields. If custom_fields are needed it would be better, if they are shown from the beginning.
Or better: a default-setting for custom_fields that defines if they are hidden behind a link or if they are shown from the beginning in the write tab.
( see here and here )
- It would be very good if there would be an extra option to set “labels” for every input field assigned in the group permission/profile.
So you could set different forms of description/hint/help for user groups. If you have users that are not very customed, you could set a “new user” permission/profile with more detailed instructions next to the fields. Or have some in different languages.
- About the structure of a “create-group-permission”-menu I have to think now.
But I think it could use a list of all different elements and mainly two options next to them:
“all” – which gives the full range of existing options
and something like
“subset” – which will open a pop-up-list from which you can mark/check the options that are permitted.
(the options “all” and “editable” from the article list is just the same principle)
It even partly could use the design (position of elements) of the editing tabs, so it is more intuitive.
(Of course other options like assigning more than one group permission to one user have to be added).
So I think there is no need for matrices of checkboxes.
EDIT: added some pictures.
Last edited by saccade (2008-04-16 17:38:07)
Offline
#14 2005-12-20 23:22:27
- saccade
- Plugin Author
- From: Neubeuern, Germany
- Registered: 2004-11-05
- Posts: 521
Re: Assignment: section permission design
Meanwhile I imagined how a “create/edit group permissions” tab could look like.
And here is an example
(by the way: I edited my first post an placed some mock images of what I can imagine)
The image shows only few of settings, but you can see the principle:
Yes/no where needed, if applicable an “own” restriction.
Where possible options should be defined there is an alternative between “all” existing and a “subset”, which can be defined. The definition of the subset can allow none, one or more options later to be selected (or of course fixed).
The yellow tabs (select section/category) are meant to be the same as what is shown when you select “define subset”.
So in combination of group permissions and assigning them to users, every possible combination of restrictions is manageable without too much trouble.
E.g. someone can be publisher for one fixed section (he cannot chose another, if the subset is restricted to one of the sections) an the same person can be staff writer with restricted permissions to publish to one single or more categories.
The user only has to chose the right role, when he begins to write or at least when he saves/publishes.
The role-choose-option should only be visible if the logged in user has more than one role.
If you don’t want to change the default settings that are now given, you even don’t get worried by to many additional options.
Last edited by saccade (2005-12-20 23:23:51)
Offline
Re: Assignment: section permission design
> mary wrote:
- 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….
etc
I would add as well, that one of the things I like about Textpattern that I think applies here, is the need for simplicity – limited options with maximum potential.
I currently have a hacked site where any time a new user is created from a “subscribe” page, the user is given the permission to write to their own section (defined by their name) and a group section.
One can imagine that the complexity could grow, and some would want more and more options for this, but unwieldy options lead to bloated pages, as has been expressed above and elsewhere. Mary’s suggestions are a succinct and simple solution that creates a new level, where developers and plugin writers can fork from if necessary.
For what its worth,
Matthew
- I am Squared Eye and I
am launchinghave launched Pattern Tap
Offline