Rights and Permissions Workgroup

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

saccade · 2006-01-09 14:06:22

I introduced the SuperAdmin alexandra posted in the graphic (see above).

On the Admin/Publisher rights:
For better understanding perhaps I should mention, that in my view the permission groups in the graphic do not necessarily match exactly the privileges of textpattern at the moment. They can of course – but: With separating permissions and content and with additional permission types (shared and permissions by authorship) there can be more refined groups of permission. And thus different types of admin – some more powerful and some less.

With the Admin-group
it was my intention that there could be admin-rights that only apply to a part of the whole site – so you could give away a portion of admin rights to someone else and get rid of the work.
For example: The Instructor Laura could be allowed to grant and restrict privileges to “her” user group “trainees”, so she could give them more rights as they learn more to do – a task of an admin, this task for me is not very well described with “publisher”.

That of course is very dependent on what we have in the admin-permission-group. If it is all and everything then it makes no sense. But I of course have in mind, that the area where the rights are operative could be defined in the content component – also for the admin-rights.
So in the version of yesterday my thought was:
permission-group “Admin” + content-group “All” = “SuperAdmin”
(unfortunately I called the Role “Website Admin” and so this couldn’t be noticed at once.)
Am I wrong in this idea? Isn’t it possible?

I think we should also separate rights that are now together in “publisher” into “publisher” and “admin”.
If you need an admin-publisher like now, you can easily do this by giving both roles to the user.

@Matthew:
beer = pending, I will continue working in ascetic mode ;-)
Kerstin, my wife, was out with the car, and for walking to the next petrol station (no, not because beer were like petrol for me, but because shops have closed!) it was too cold and too late. But I could get a glass of Glühwein (mulled wine / glogg in American?). Better than nothing but not as relaxant as bavarian Weißbier.

Last edited by saccade (2006-01-09 17:13:20)

saccade · 2006-01-09 16:34:59

to proceed from the global theory to practical execution and prerequisites:

in a list of permissions for the permission group setup we need these new permissions:

create permission group
edit/customize permission group

and as well

create content group
edit/customize content group

and of course

create role
edit/customize role

The following can be discussed, for a general permission to create/edit users could cover as well user groups. Why should there be a difference? (Except if we have to treat single users and user groups different)

create user group
edit/customize user group

saccade · 2006-01-09 17:05:37

another modification is implemented in the graphic: user/usergroup.

Does that reflect what you think of?

Textpattern CMS

Textpattern CMS support forum

#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

#46 2006-01-09 14:06:22

Re: Rights and Permissions Workgroup

#47 2006-01-09 16:34:59

Re: Rights and Permissions Workgroup

#48 2006-01-09 17:05:37

Re: Rights and Permissions Workgroup

Board footer