Rights and Permissions Workgroup

saccade · 2006-01-07 09:51:50

Alexandra.
Thank you very much for the good visualization. That helps a lot.
Yesterday in the evening I have been online for only two minutes (or at least only two minutes of looking on screen) between coming home and leaving again. I was very pleased and impressed by the visualization but couldn’t look in depth nor say/write anything.

How did you create it? (with which application?)

As I understand your post, it is allowed to work in this grafic.
I would like to visualize the concept of “groups” in it.

saccade · 2006-01-07 10:05:42

some suggestions or questions that come to my mind quickly:

1) For improving the understanding and better showing the connections to present functions of textpattern:
Shouldn’t we include (some of) the roles (=privileges) that are available in the present version of textpattern?
(Maybe with some tag or color marking what is presently possible)

2) I would draw a frame/border (or give them a background color) around “permission” and “content”, for these two together create a role (I think that was, what you wanted to show with the double arrows).
The combination of the two is the “permission machine” that creates a role.

For the concept of groups I have to think still a while.

alexandra · 2006-01-07 10:15:35

@saccade my suggestion: lets split it up into two grafics:

reflecting the concept (abstract)
reflecting the combination of the concept an what is already availabe in present version of TXP

agreed? Or is this confusing?

Last edited by alexandra (2006-01-07 10:15:54)

saccade · 2006-01-07 10:24:37

@alexandra
agreed!

saccade · 2006-01-07 16:10:36

still thinking and working – please be patient

While working on the grafic another question came up, a real brain-twister (I need advil too now):

1) We’re in the “permission” area.
2) Someone should have the right to “edit articles”
3) He should be able to edit “own” articles.

Now the first question:
A) Isn’t “own” really/in fact a part of the “content”-component? Meaning all or only own content?
If so, it should be better to have this choice – restricting to “own” or “all” – in the content-area. (I think so)

But thinking further the second question arises:
1) At the moment in textpattern permissions we have two choices: “all” or “own”. That could be very rough.
2) If the permission in question relates to some characteristic of content, then in our present scheme we could choose “all” and restrict to the relating content-characteristic. That would be an advance.
3) But some role could afford, that a permission is not related to content but something in between “all” or “own”, thus related to users.
For example a role could be needed, where a teaching editor should have rights to edit articles of distinct other users e.g. volunteers or trainees (that is a user group).
This also I would locate as a possibility of selection in the content-component.

(Of course you could do this task by my idea of content group with the selection of all single articles created by volunteers, but then you have to find them manually first and you are always behind the action. So it would be much better if you could select content by its author in the same way as you can select it by its section)

Finally what I suggest is an additional new way of defining content by authorship.

It could look as following:

content autorship

all
own
subset or usergroup

Can you follow me? I hope I managed to outline the task.

Of course I’m thinking whether it is sensible to make all these distinctions and separations, but I think it opens a true modular and scalable architecture for our task. And it seems to me better for carrying out the programming. Or deciding which of the parts we need now and which we can spare for later.

EDIT: ok, reading the following post – thank you P – another point comes to my mind: If authorship is located in the “content”-component, it applies to all permissions. But it could be possible (in fact it is) that in “publisher” you need the permission “publish article” for all users but “edit article” only for own or maybe a usergroup xy.
Conclusion:
Authorship should be an option applied to every element of permission (where applicable),
but my new suggestion is to include usergroup as an option besides “all” and “own”.

Last edited by saccade (2006-01-07 16:57:24)

-P- · 2006-01-07 16:19:46

Based on groups there are now, here´s how I´d see the system.

Scenario for example a webmagazine that has main section and sections by writer.

Publisher (site admin) as is. To Managing editor I´d remove default options to have a access to site design and preferences and change them to be per user group selectable options. -> can edit site preferences yes/no.

I would add new option, Assign to shared. This shared would be additional setting in sections and articles.
So Publisher and Managing editor could assign sections and articles to shared. This would be kinda built in workflow. By default, articles posted to shared are editable by everyone if assigned with needed priviledges.

There would be three basic user groups with predefined options much like now (Publisher, Managing editor and Writer). But I would add an option “Create a new user group based on …” with drop down selection. On the new group one could individually choose option yes or no to following:

Admin rights:
can create, edit or delete any article, link or comment
can change article status
can edit site preferences
can edit sections and categories
can add and remove authors
can grant and restrict privileges
can change article status from Pending to Live
can edit sections and categories
can edit any article, link or comment

Style:
has access to all site design areas
can edit Page HTML, Forms, and CSS

Publishing:
can create and edit own articles
can publish and delete own articles
can create and edit shared articles
can publish and delete shared articles
can move articles to shared
can upload images
can edit links
can edit comments
can edit categories

edit: seems like saccade was posting same time from similar stuff.

Last edited by -P- (2006-01-07 16:27:12)

saccade · 2006-01-07 17:23:39

Thank you P, I edited my last post, based on your suggestions, that led me to rethink the problem of all/own/authorship.

Your concept of “shared” is very interesting.

Our thoughts base on the same problem of workflow: How to give specific permissions across authorship.

My concept bases on taking the authorship of content as a point of origin (by giving permissions related to author groups), refine it to the intended content type and connecting it exactly to a permission role and so an editorship role.
This concept has the lack that in this way all content of the assigned authorship-usergroup-content is given to the permissioned editor. The user themselves have no possibility to decide. It’s always clusters of content.

Your concept of “shared” articles base on content or content type. That has the benefit, that authors (or higher rights) can decide themselves, what is shared and what not. It can be refined to single specific articles.
But to me it seems that beyond giving articles to the shared pool, you cannot specify exactly, who is allowed to share. I think all permission groups share all “shared” articles if they have access to the same cluster of content.

Do I see this correctly? Or am I wrong?

I think these two systems reflect bottom-up-decision about sharing or top-down-decision. In the first case principally the user decides, in the second principally the admin.

Maybe there is some way to combine both possibilities, but this seems to take lots of advil ;-)

Now this is very theoretical, but this exactly are the problems that come up in any workflow, even if you have only five users. I think we should keep these problems in mind.

saccade · 2006-01-07 19:01:53

Here my first try.
Unfortunately I have to leave my home now for about two hours, but I wanted to show the first structure. Later I will refine the grafic.
I couldn’t manage to get arrows in time, so you have to follow the color boxes. Sorry.
Also I wanted to take alexandras user/roles-relations over but now I haven’t enough time left. Sorry again.

“own/all/usergroup” will be defined in the permission group setup and is so parte of the permission group.

EDIT:
There is a new grafic in a post below. I decided to leave this here as a link for comparing.

see old grafic here

Last edited by saccade (2008-04-16 16:44:58)

alexandra · 2006-01-07 19:27:38

I need some advil too by now :) Nevertheless, very interesting. In general i tend to the top-down-decision-making. Then again the sharing concept sounds very appealing to me. Maybe a simple solution could be:

set article to ‘share all’ -> everybody can edit article
set article to ‘share exclusively’ -> noone except for Admin, Mangaging Editor and Author can edit article.
set article to ‘share usergroup’ -> noone except for Admin, Mangaging Editor and Usergroup can edit article.

My suggestion above is the same as saccades: Content authorship

all
own
subset or usergroup

correct saccade?

Edit
Great grafic just seen it.. will respond on it tomorrow.. mh btw. laura should not be blue. She is green. But then again i would suggest to take all single users out of the grafic, except for the Admin/publisher, and only apply Usergroups.

[Klasse Grafik Michael..wow.. ich würde nur die Einzelpersonen rausnehmen, bis auf den Admin, und nur Usergruppen anführen. Jeder User kann doch der einfachheit halber gleich eine Usergroup sein? Oder sollte man das getrennt halten? Das könnte Verwirren sein.
Laura ist übrigens Blau, sollte aber wenn dann Grün sein oder Blau und Grün. Ich würde gerne noch einen Admin einführen. Wir mischen übrigens derzeit Publisher und Admin in unseren postings. Sprachlich sollten wir uns für einen der beiden Ausdrücke entscheiden, sonst kommt es zu Verwirrung. Admin ist eigentlich klarer aber in TXP ist das glaube ich der Publisher, oder?]

Last edited by alexandra (2006-01-07 19:46:10)

-P- · 2006-01-07 21:41:01

Very nice to hear that others find the concept of shared group to be good idea! That is something that I´ve come accross (well the lack of it) several times already when assigning rights.

saccade · 2006-01-07 22:22:22

Regarding the color boxes in the grafic:
I only placed boxes along what has been manually set when setting up rights.
So these boxes are like needles picked to the table to create rights.

But indeed those boxes can as well be taken as indicators (of resulting connection) and in that view indeed
Laura should also be green – because she is part of the group Linguists. And indeed she is blue because I wanted to show, that you can combine usergroups and single users.
Fritz should also be red and blue
Jeremie green
Juliette red
Ian blue and orange

I’ll think over a system to show the difference between actively set connections and connections as a result of others – maybe x-crosses for settings and bullets for indicators?

On single users vs. usergroups:
I have usability in mind:
Normally the first step is to create a (single) user.
As long as you have only one user or two or three, it would be a very superfluous step to create a user group and assign a single user.
Only if you have to manage a growing number of users and need to organise them along groups, usergroups come into question.
So you will connect a set of your single users into a usergroup.
But even in this case, there will still be single users, that shouldn’t be packed into an extra step of administration.
So if you treat/show single users and usergroups in the same manner (only with different content) you can use the same menu for assigning role(s) to them. You only need an extra function in the menu like “create/manage user group”.
One exception comes to my mind: Until now this system would show every user as a single user – even if he belongs to a user group.
So usergroup creation/managing should include an option for every user in the group “hide user in single user list” (it must be a separate option for every user because for example you may have 199 users that can be hidden, but one of the shouldn’t because he has another function/role as well. It should have the default “hide”.).

EDITED 8.1.2006: Should there only be “groups” in the settings menu? alexandra suggested to use only groups in the users-component and set up a group for with one member for single users. As I wrote above I do not think this is good. But in the content component it is worth a thought:

First point: In the content component we have (1) the option “all” (it reflects, what is possible at the moment and will fit for many situations – careful users provided). And then (2) we have specified parts of content.
“All” as well as everything not being “all” can obviously be taken as a “group”.
Even a content type “section xy” is in fact a group of content elements which has to be defined in any manner (either by manual selection or by automatic creation, a section is created).
Second: We have no legacy (as in the users area) in this field because we want to introduce it into textpattern.
Third: I distinguish between “content type” (of any number) and “specific content” (which has a specific number, e.g. the three articles “A”, “B” and “C”).
In the grafic at the moment there are “Sections” as a definition by (single) type.
And all what is defined by more than one type or by specific titles or a combination of both should be covered in “groups”.
This distinction between group and type is perhaps (no, surely) misleading and not necessary.
It was a reference to those users who primary want(ed) to have easy access to restriction by section and nothing more.
But their task could be easily achieved by building a group that consists of “Section A” for example.
And maybe single-section-groups could be created by textpattern automatically along to creating a section. (That is meant as an administration help for those who only need to assign content by its section)
All further groups have to be created by the admin/user and a “create/manage content group”-function is needed (of course).

~~To only have groups is something I have in mind for the content-component.~~
~~Here a “type” like “section xyz” can be understand with no loss as a “group” as well.~~
~~So why not have two preset options: “All” and “Create group” (and here the possibility to create a group “section xyz”)~~
~~But here also I have in mind the usability of small textpattern installations:~~
~~Sections could perhaps be automatically defining entries in the content-group-component.~~
~~And groups should be set up or customized, when a user needs them.~~

~~But in this logic I think the work and possibility of programming comes to question.~~

Publisher vs. Admin
When defining new rights as we want it, someone can be “publisher” of a section or even a category (the one who publishes) but should possibly have no rights to set rights and permissions, because he is not the boss of the whole textpattern installation.
So I think we have to include a (new or overriding) role “admin” who has the right to set rights and permissions.

top-down or bottom-up / authorship in permissions and/or authorship in content needs some additional reflection. Because I have to work in my job now, this will take until tomorrow evening to come to a suggestion.

Last edited by saccade (2006-01-08 11:40:39)

jakob · 2006-01-07 23:45:34

I would like to echo NXArmada’s suggested additions to the rights area:

It would be good to have the right “can only see own articles, files, images in list”
but “own” could also read “author” / “work group” etc. in the context of the above discussion.

There are numerous crossover situations where some degree of user contribution or ‘membership’ of a site would be advantageous, without the need for full blown own user accounts etc. TXP would work well for this and Manfre has already implemented some initial tools.
Such contributing authors/member’s can handle the backend of TXP much more easily when presented only with their own (relevant) articles, rather than all articles on the site. It also avoids ‘members’ copying from one another.

A personal wish would be to have some aspects of the write form such as a custom field or category “invisible” for guest contributors but visible for admins. This would enable ‘members’ to update their own information whilst the admin can control where and how it appears.

Textpattern CMS

Textpattern CMS support forum

#25 2006-01-07 09:51:50

Re: Rights and Permissions Workgroup

#26 2006-01-07 10:05:42

Re: Rights and Permissions Workgroup

#27 2006-01-07 10:15:35

Re: Rights and Permissions Workgroup

#28 2006-01-07 10:24:37

Re: Rights and Permissions Workgroup

#29 2006-01-07 16:10:36

Re: Rights and Permissions Workgroup

#30 2006-01-07 16:19:46

Re: Rights and Permissions Workgroup

#31 2006-01-07 17:23:39

Re: Rights and Permissions Workgroup

#32 2006-01-07 19:01:53

Re: Rights and Permissions Workgroup

#33 2006-01-07 19:27:38

Re: Rights and Permissions Workgroup

#34 2006-01-07 21:41:01

Re: Rights and Permissions Workgroup

#35 2006-01-07 22:22:22

Re: Rights and Permissions Workgroup

#36 2006-01-07 23:45:34

Re: Rights and Permissions Workgroup

Board footer