Assignment: section permission design

saccade · 2005-12-20 06:36:23

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)

saccade · 2005-12-20 23:22:27

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)

squaredeye · 2005-12-27 04:55:24

> 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

alexandra · 2005-12-27 12:38:14

As mary said on the other thread: it´s rather the logic behind it [right permission] (case examples, how should it work, etc) that needs to be figured out first.

I would like to suggest to set up a workgroup figuering out the best approche to a solid, flexible and scalable rights, roles and workflow concept within textpattern.

The issue should be handled with care as it is one of the most essential for a CMS.

edburdo · 2005-12-27 13:47:49

I am one of those folks who have 1 or 2 users. I don’t foresee needing more anytime this (coming) year.

So the default permissions are great for me. I think shipping with those permissions is great. Then give the ability to expand from there.

squaredeye · 2005-12-27 13:48:30

Alexandra,
I second your motion.
How would a workgroup operate?
Would it be a coder based workgroup or open to others?
Should it be open I would like to participate :)

Matthew

alexandra · 2005-12-27 14:34:51

Hi Matthew et al,
i would split it up into two steps:

setting up a workgroup working on a paper (rights, roles and workflow concept) from a more ‘theoretical’ point of view (working out the logic)
once this is done, talk to the programmers and cut it down to TXP capabilities

Last edited by alexandra (2005-12-27 14:35:22)

saccade · 2005-12-28 10:35:36

Hi Alexandra,

I’m (not yet) a coder nor programmer, but in the first step of working out the logic I would like to participate – if you think my suggestions can contribute something to it.
(Maybe some points could be worked out by me more precise in German).
So if you think I should participate – let me know.

alexandra · 2005-12-28 11:13:31

Hi saccade,
i just got an private email from ma_smith who is as well interested in joining such a workgroup. That is a nice start. Right now it probably makes sense to ask the dev´s if they did already work on such a concept just to avoid ‘double work’. If they did not, which i persume, we can open up a new thread on the issue asking for support and further related information.
I will send emails to the dev´s asking and will inform you.

Hang on you´ll hear from me in a while or tomorrow…

Jeremie · 2005-12-28 20:25:45

alexandra wrote:
I would like to suggest to set up a workgroup figuering out the best approche to a solid, flexible and scalable rights, roles and workflow concept within textpattern.

This isn’t what’s done here ?

-P- · 2006-01-02 16:30:37

I agree to that if user doesn´t have permission to some section, just hide it instead of “You don´t have permission”-text.

I also would like to have option to set permission to Presentation indivually OR only to levels Publisher, Managing editor and Designer.
At the moment when user is set to have rights Copy editor, there´s also Presentation tab that for normal advanced user is unnecessary. But if rights are set to Staff Writer, there goes also permission to edit links and comments.

I know this can be fixed with editing source but it would be really nice to have it as default. :)

alexandra · 2006-01-02 22:53:57

@jeremie – i am convinced a workgroup is more efficient than a discussion. We need a kind of paper with structured informations and examples on how a permission system can/should work.

Okay, Sencer and zem did reply and neither of both did work on a rights & permission concept. So best is to get the workgroup working on a paper (rights, roles and workflow concept) from a more ‘theoretical’ point of view (working out the logic) going.

Okay, who likes to join or contributes informations?

Last edited by alexandra (2006-01-02 22:55:58)

Textpattern CMS

Textpattern CMS support forum

#13 2005-12-20 06:36:23

Re: Assignment: section permission design

#14 2005-12-20 23:22:27

Re: Assignment: section permission design

#15 2005-12-27 04:55:24

Re: Assignment: section permission design

#16 2005-12-27 12:38:14

Re: Assignment: section permission design

#17 2005-12-27 13:47:49

Re: Assignment: section permission design

#18 2005-12-27 13:48:30

Re: Assignment: section permission design

#19 2005-12-27 14:34:51

Re: Assignment: section permission design

#20 2005-12-28 10:35:36

Re: Assignment: section permission design

#21 2005-12-28 11:13:31

Re: Assignment: section permission design

#22 2005-12-28 20:25:45

Re: Assignment: section permission design

#23 2006-01-02 16:30:37

Re: Assignment: section permission design

#24 2006-01-02 22:53:57

Re: Assignment: section permission design

Board footer