Rights and Permissions Workgroup

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.

squaredeye · 2006-01-07 23:59:38

Whoa there big thunder! (western expression – western as in “cowboy”)
You all are fast!

I’m tracking, but I’m also lagging.

Perhaps I can throw the expression engine demo in order to understand a few differences, between what you are going after saccade, and what they have rolling here. Of course, its a demo, so its limited, but I think you’ll get the picture.

Once you login: navigate to here
Or just locate Admin/members and groups/ and see what you think.

*They use a series of radio buttons to manage yes and no’s about member groups. (which the admin controls)
*There is a large list of capabilities to edit for each member group.
*Each member then can edit many of their own preferences once allowed access to the “control panel”.
*Because the demo is limited, you will note that its hard to tell if as a “member” rather than “admin” you would be able to manipulate the options for those under you, but it may be worth contacting expression engine about?

With “sharing” are we talking about a WIKI style of article that could be edited by any member if you allow “all” access, and any member within your group if you allow “user group xyz” (xyz being your own user group), or just you if you specify “me only”?
I think I understand it that way.

I agree that “Admin” is the most appropriate and understable nomenclature for the top dog.

Saccade: Could you elaborate on the post above? : “To only have groups…” I think I lost you on that one.

squaredeye · 2006-01-08 00:05:30

I echo Jakob’s post above, but I also think we need to be careful about how much we bite off?
Mary at one point suggested that those things ought to be kept separate.

If you look at expression engine, as I posted above, I think you’ll find that they do handle much of this in “chunks” (if you will).

The issue of seen and unseen for usability is a HUGE one me thinks, and thus it should be dealt with, but is this the right time?

Ideas,

matthew

saccade · 2006-01-08 11:53:08

Matthew,

at the moment I have spare time for these things and wanted to get as much as possible done now. Next week my normal job starts again and I fear that then I will be lagging.

I tried to elaborate the post above and edited it. I hope now it is more clear.

I still think about the top-down/bottom-up structure and shared content.

I think the content authorship has to have to places:

within permissions setup (for differentiating permissions) and
within content group defining (for giving access to content defined by its user/group) too.

The “shared”-Attribute is still something in between, because in its function it is the same type of status as live/pending/published/draft.
So we should think about putting it there, but it must be an additional status (means: you could have draft and shared or live and shared.
So you or the admin can set one of your articles “shared” and the other not – completely independent from all other characteristics. And who is legitimated to edit is defined by the editor access definitions we discussed above.

Seems to be the solution – but that is only a feeling, I didn’t put it to fire yet.

Last edited by saccade (2006-01-08 11:54:24)

saccade · 2006-01-08 19:42:25

Oops, hard work thinking and visualizing – and maybe harder work looking and understanding what I have produced.
I owe you pallets of advil I presume ;-)

Here’s the graphic:

Link to previous version
Link to previous version

Updated Version:

The center point are the Roles, they have a single color tag (it makes sense to set the color origin here because they link between three other components, can be used for many users …).
The Roles reflect tasks in the workflow.

A role consists of

(normally) one permission group
(but if the permission groups don’t intersect/clash, as for example “Edit Excerpts” and “Change priceinfo” they could be combined withou problem) and
one or more content groups (see “AmericanLit Keyword Writer”)

Notice I have tried to show how versatile the system could be:

Assign a user group together with a single user: For example the usergroup “trainees” can write excerpts for all forms of content. Single user “Laura” also is assigned to this Role. This is because she is an “Instructor” (for the trainees) and thus has the permissions as a Managing Editor for all contents created by the usergroup “trainees”. In this role she should have the Role/Permission of writing excerpts for all other users too.
For she is a Linguist, she is included in the AmericanLinguists group and gets their permissions as a result of belonging to the group.

Regarding the Admin rights:
There is one Super Admin Barbara whose Admin rights relate to all content.
But I can imagine that in some workflows you want to leave admin rights (and admin work) for a special section to another person. So I engaged Juliette to do the admin job for the whole European Fiction Section.

Fritz is new in the job, he’s an experienced Linguist, and he can write articles, but on the whole tasks of internet/textpattern publishing he is a trainee, so Laura as an instructor has managing rights on his articles.

I hope everything is correct and comprehensible now.

Remarks about a menu structure

The complex of user(group) and role in its first way of assignment (=*assign privileges/role to a user*) can simply be managed with what we have in textpattern. The existing roles fit into the “privileges”-list, users could stay as now, and only a function to set up user groups has to be added. If someone doesn’t need anything more than now is present he needn’t be bothered with what we introduce further and what is possible behind the szene.
I think if you have workflow (of your content, not of administration) in mind which is more interested in the management of tasks than in the persons behind, then it could make sense to have another admin menu that shows all Roles (as now users) and have the users assigned by selection to the roles.
For creating or setting up a Role a menu (I think only one new admin-tab) is needed in which you simply pick elements from a permission-group-list on the left side and a content-group-list on the right side. It could look like the grafic, with two links to the “Setup”-Menues for both groups. (And there need no color tags to be, as you don’t need the overview of possibilities like now. Only on/off checkboxes are needed. Their combination is stored in the role-profile.
In the Setup-Menues for “Permission Groups” and for “Content Groups” I would prefer a solution like it is shown in the article alexandra posted: A Matrix set of permission elements (with descriptions) or content type/elements in the y-dimension and the existing and new groups in the x-dimension. In this manner you have a good overview for example how permissions decrease, or how content types specify more and more (here you could later visualize also every form of nesting). (To give a form of comparision of groups rights of course would include a form of sorting the order of groups manually, maybe that’s too difficult for programming.)

Matthew, I looked over the expression engine, but not in depth. My first impression was that you get no sense for the whole picture of permissions and content from it, because everything is separated and shown on a single page. But of course it includes a big lot of more functions. But maybe I’m totally wrong and only didn’t understand its structure. (My brain was fully busy with finishing the theoretical system.) Can you help me which structure/scheme/visualization I should look nearer?

So now after this long post I would wish a good beer (I live in bavaria) to get my brain relaxed and rebootet for new work – but I have none and it’s Sunday :-(

Last edited by saccade (2008-04-16 16:47:07)

alexandra · 2006-01-08 19:53:18

Hey wow great grafic! I have to read through and look at it for a while… We owe you ~~Advil~~ gallons of bier :))

I would split Single Users and UserGroups up into two seperate columns. Easier to understand for programmers as we need 2 databasetables for that anyway.

Some questions arise concerning adminrights. I will elaborate on that tomorrow.

I am happy for getting that far and by now already having an approach on the ‘Share content’ issue. I guess there is enough content here to bite through the following week :)

Last edited by alexandra (2006-01-08 21:02:14)

squaredeye · 2006-01-08 21:50:21

Looks great all!
I am also impressed we are churning along.
Saccade: while I like the idea of a single graphic to illustrate how all this could work, I am confused about our current status:

Would this be a graphic, which would change or show changing info based on decisons the user makes in the txp admin
or is this a representational graphic for us (the workgroup)?

I agree with Alexandra about the two columns issue for readability (and it sounds like coding issues).

Per the expression engine rights/permissions/groups setup, I am not sure that I understand the whole structure of that beast myself, but thought it might be a good platform for discussion, per what we were coming up with here? What I liked about how they had it layed out, was that it was not overwhelming. I am led through to a structured admin menu that branches out into logical parts from there.

In the section member/groups you’ll find the group names listed:
-banned
-guest
-member
-pending
-superadmin

While this is all on one screen, I am limited to five pieces of information about each type of member. In terms of usability, I personally find this more helpful than inhibiting.

When choosing to edit one of these members I am presented with this list for each member:
• Member Group Name
• Security Lock
• Site Access
• Member Profile Privileges
• Comment Posting Privileges
• Search Privileges
• Private Messaging Privileges
• Control Panel Access
• Control Panel Area Access
• Control Panel Administration
• Control Panel Email Privileges
• Weblog Posting Privileges
• Weblog Assignment
• Comment Administration
• Template Editing Privileges
• Module Access Privileges

Within that list I am presented with between approx. 3-12 choices of yes or no privelages to assign to that “type” of member.

Again, rather than speaking to the infrastructure I am concerned with the graphical implementation, in which case if the answer to my first question is that Saccade’s graphic is preliminary and only for example then I am jumping WAY ahead :)

(one thing to note is that it appears that expression engine is using Ajax to load the more internal menus ahead of time so that much of the time it is a very fast switch between menus) – this may not be available for us at the moment?

Perhaps I’m rambling, I think I’ll go have a bit of alcohol as well and call it a TXP night :)

Matthew

Last edited by ma_smith (2006-01-08 21:51:51)

saccade · 2006-01-09 11:51:44

Matthew,

the graphic is primarily for a representational graphic us (the workgroup),
but I always had in mind that a real suitable system has to be understandable (and in result: usable) for users too.

It contains on the one hand theoretical meta-information (the structure, the distinctions etc.), on the other hand practical examples (the sections, the lower permission groups, the users and their possible – or intended – relations).

And so secondarily the four (or five if separating users/groups) lists of elements could also basically reflect, what an adminuser with a Bookreviews-Textpattern-site could see in his different tabs.

But the color tags (crosses and boxes) are purely representational for us. They shall visualize the whole picture.
An admin/user for example would see the “permission machine” as a “role name”-field on top, below the two lists and only empty checkboxes (or characteristically filled, if he modifies an existing role) with black or whatever checks. What he chooses will be saved in the role-profile.

How the user-role assignment could look like, I stated in my former posting (widely like now in textpattern except for adding usergroups).

Did I describe it understandable?

alexandra · 2006-01-09 12:03:02

Well said, saccade.

As i am just about it, we need indeed a list of privileges as the EE one above in Matthews post. Perhaps Matt likes putting together a list? It should be simple. All we need are txp terms. F. e. in the EE list it says: Control Panel Area Access. What is that in TXP?

EDIT
As well we have to talk about Admin and Publisher rights. And we need a SuperAdmin which should be introduced in saccades grafic above.

Last edited by alexandra (2006-01-09 12:04:52)

squaredeye · 2006-01-09 12:48:23

Saccade and Alexandra,
I will have a go at the list this evening.
Feel free to go after it sooner, but for now I’m off to work.

Saccade, your explanation was outstanding and really brought me up to speed : Thank you. I don’t think I understood that each column would/could be under its own tab, so that helps clarify. You’re doing an outstanding job. How was that beer?

You’ll hear from me later about the list.

Matthew (prefer the full name :)

Textpattern CMS

Textpattern CMS support forum

#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

#37 2006-01-07 23:59:38

Re: Rights and Permissions Workgroup

#38 2006-01-08 00:05:30

Re: Rights and Permissions Workgroup

#39 2006-01-08 11:53:08

Re: Rights and Permissions Workgroup

#40 2006-01-08 19:42:25

Re: Rights and Permissions Workgroup

#41 2006-01-08 19:53:18

Re: Rights and Permissions Workgroup

#42 2006-01-08 21:50:21

Re: Rights and Permissions Workgroup

#43 2006-01-09 11:51:44

Re: Rights and Permissions Workgroup

#44 2006-01-09 12:03:02

Re: Rights and Permissions Workgroup

#45 2006-01-09 12:48:23

Re: Rights and Permissions Workgroup

Board footer