Rights and Permissions Workgroup

squaredeye · 2006-01-11 00:25:55

Here is the first list I came up with to sum everything up as textpattern is currently.
It seems like you all may be ready to make adjustments for these new ideas?

admin access (textpattern interface)
ADMIN • view diagnostics • preferences ⁃ general prefs (edit) ⁃ languages (edit) • site admin ⁃ (edit / delete) admin info ⁃ (edit / delete) author/user info and RIGHTS (including reset pw) ⁃ create new author • logs ⁃ view • plugins (upload / edit / delete) • import (upload content)

PRESENTATION • sections (create / edit / delete) • pages (create / edit / delete) • forms (create / edit / delete) • style (create / edit / delete)

CONTENT • organize • categories (create / edit / delete) ⁃ article ⁃ link ⁃ image ⁃ file

• write (create / edit / delete)(assign/re-assign)(draft / pending / publish) • articles (delete / change section / change status) • images (create / edit / delete) • files (create / edit / delete) • links (create / edit / delete) • comments (create / edit / delete)

Also to weigh in on symantics, I have often worked in office environments where the structure is Admin/owner then Manager.
Manager tends to be someone who covers a shift of work or a section of work. ie: the Kitchen manager, or the Morning manager. You may have moved on from instructor (though I’m not sure about that), but in either way, instructor, has a fairly ambiguous meaning in American English, relative to Teacher, which doesn’t hold up well in the psyche of the American mind, where teachers are often low on the totem pole.

Sorry the list took a bit. Work and a cold got to me :)

Matthew

PS I am really getting on board with this. Saccade your graphic is looking HOT! Well done. I hope the beer was fantastic. I’m a big fan of belgian Triples myself, so get a hold of a good one and drink for both of us, as Pennsylvania makes it hard for poor folk to buy good beer.

Last edited by ma_smith (2006-01-11 02:12:14)

Jeremie · 2006-01-11 01:58:26

I wouldn’t put editing user’s infos, reseting password and editing user’s permissions in the same right. For me, that’s three different rights.

squaredeye · 2006-01-11 02:17:03

Jeremie, I agree, I only presented things as they currently are in sections for the Publisher.

It seems like:
-editing user info, should be admin>user (where the greater than symbol = anyone above user can change user info.
-resetting user password should be admin>user
-resetting admin pw should obv. be admin.

Is that what you mean Jeremie?

Do you all want a list as it works for “out of the box” for each type of author/user? or Just as I have it above for Publisher?

Jeremie · 2006-01-11 02:24:54

ma_smith wrote:
It seems like:
-editing user info, should be admin>user (where the greater than symbol = anyone above user can change user info.
-resetting user password should be admin>user
-resetting admin pw should obv. be admin.

You mean, as set-up in a default install, right ?

squaredeye · 2006-01-11 02:34:52

I mean that currently it is not separated into those different permissions, but it should be (yes in default install).

Am I making sense? Hope so.

saccade · 2006-01-12 11:15:45

For until now we talked mostly about the structure of components I proceed to thinking about these components regarding their content (in the view of their definition by content).

First I look at the user groups:

In our system it is very open (I regard that as a benefit) what defines a user group regarding content.

Matthews example of the “Expression engine” helps thinking:

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

These are user-groups roughly taken by their status.
Our examples show, that we reflected user-groups taken by a task – it could be also “organizational branch”, “responsibility”, “language” (multi-language sites!), “income” ;) or “skills”.

Until now I thought to leave it completely to the users of textpattern, how they want to organize their user groups.
I also thought, that these user-groups range on an equal level.
That would mean that users of textpattern could decide if they want to organize users by their status as above or by their tasks or anything like that or even mix both views.

But re-reading Jeremies requests the problem of interaction came to my mind. How is it solved, if a user

belongs to a user-group A which grants him rights to edit something
and also belongs to a user-group B which forbids editing?

I think the best solution lies in the concept of roles and is to take it like i suggested before:
A user has to choose in which of his roles (tasks) he is working at the moment.
So it is the responsibility of the admin to make secure a user only has roles he ought to.

¹ To help the admin maybe there should be a place where he gets an overview, which roles are assigned to a user directly or by result of a user-group. (The first column in our bookreview-example is something like that. Make the boxes and crosses full names of the Role and you have it).
Or the other way round: Provide a list of the roles and show all users, who are assigned to this role at the moment.
(I think or hope this should be possible without too much programming effort, because the different components are linked by the settings anyway.)

But regarding content interaction confronts us with another problem:
To choose his role solves the problem how to distinguish between different tasks/rights of a user(group). So far so good.
But if it comes to his status normally he shouldn’t be able to choose (imagine he is offered to choose between “banned” and “publisher”!).
So we need another stage of handling user rights before giving access to one or more roles.
The status is prevalent to tasks(=roles). See example below. Both of course are user-groups.

How to solve this situation?

First I want to sort what is really a status (= prevalent to other groups/tasks/role) and what can better be defined by a task or role: It is a little bit difficult to sort that, because you have to figure out, what function is intended. I’ll try to explain:

A status should be prevalent to role(s) in that way that it affects the validity of assigned roles without changing them.
Example: You have a complicated organization and thus a sophisticated system of roles. Now you need to ban five of your users for a week due to some reorganisation. But after a week they should get their roles back and be in the same groups before. Of course you could remove them from all groups, change their roles, note their groups and roles on a piece of paper. And do all this reverse in a week. Or you simply could set their status to “banned” or “pending”.
If the main purpose is to assign (or possibly change/adjust) roles then the function is that of a “Role” and the current concept of user-groups is sufficient and there is not need to have a status for it.

Second: It should be thought about, if status is related to user groups or if it is better located at another place.

Status could easily be added as a feature in the profile of the single user (and for the admin a list of users with this profile).
If so it should supersede/exceed all (later applied) Roles of the user in a fixed way.
This (as I imagine) would work and be quitely enough for “banned” and “pending” if that means that no role = no rights is in effect at the moment.
But “guest” and “member” in my opinion could benefit a lot from being a user group for then you can assign a (mostly basic or minor) role to the whole bunch of members or guests and you can change to another role if required. (If I think further it could be a thought for “pending” too. Only “banned” normally includes to have no access and thus no necessity to configure/change your role.)

Third: The picture gets clearer if we look at the five groups from above and reflect if they truly represent a status or more a task/role:

“superadmin” (or admin) definitely is not a status but a Role and already has its place in our system.
“banned” is clearly a status in my view. (See example above)
“member” I think is a normal user, so it needn’t necessarily to be an extra group nor an extra status. What could be a function of specifying a user as “member”? (see below)

More complicated to grasp are “guest” and “pending”:

If “Guest” relates to the users role(s), then it is no status but can be treated like a single normal user group with applicable roles.
If “Guest” is a function of time (For example someone has access to the site with granted rights = one or more roles (and maybe in different user groups), but his access as a guest is restricted to one day or 30 days, and then he automatically will be restricted from access. His settings will be preserved.) it is a status.
“pending” could mean the same as banned (=no access at the moment) but with another reason (and another error message?), then it is a status,
or “pending” could mean activating account in a future time (also status), or rights in effect but to be revised in one month, or something like that.
or “pending” could mean some minor rights status for beginning users, then it is a normal user-group/role-combination.

Fourth: Now,

when an element is clearly related to role(s), it should be treated as a normal user group with roles applied and doesn’t need to be prevalent. That is truly the case with “(super)admin”. And I think also for “member” (but see below).
when an element is clearly a status (= above roles – that depends on our definition of its function), there are two ways to implement:
1. make it a feature in the settings of a single user. You apply the status by editing the user profile, you don’t need an extra prevalent group but maybe only a report somewhere which users share the status.
2. implement it by dropping a user into or removing him from a prevalent user group “banned”, “guest” … (regarding our graphic this could be an extra area at the top of “user groups” or between “users” and “user groups”). Here you have overview by default. (ah and here a group “members” now makes sense to me, for it is the correspondent status to you rights in full effect, so we could have “banned”, “pending”, “members” and “guests”)

Examples:
You have a literature-site, where users can publish their works.
Here you have different sections, reflecting different languages.
Your users are organized in groups by their language and some other tasks.
Your organisation is a society or association.
So you have maybe 50 paying members who are permanent granted rights due to their user-group and role. (status “members” or no status).
You have the offer of a a monthly subscription for writing/publishing guests who have different roles in their language section. Those people don’t subscribe permanently, but at times. You don’t want to do the whole setup every two or six months. (they are set up as users within the system once, and get the status “guests” [if possible with an automatic 30day timeout] every time, when they pay the subscription fee)
One of your poets, a genius if sober, sometimes is drunk over a week and if this occurs, you better ban him for some time till he’s normal again ;-)

Another example:
You have to do a complex setup of groups and roles for a new employee in a complicated workflow.
Because the whole thing has to be confirmed by the boss (when he comes from his vacation)
and then (of course!) immediately been brought into force within five minutes,
you can do everything in advance, set the user to the status “pending”
and impress your boss by setting it into force within one minute by changing the status :-)

Please forgive me if I again cause headaches
:)

EDIT/PS: In thinking about prevalent groups yet I hadn’t in mind that between banned/pending and guest/member there are different AND/OR/XOR-relations. So maybe it is only possible as a setting within the single-user-profile.

EDIT 2: And in consequence of EDIT 1 maybe we should have a semantic correction too: “guest” and “member” ist better left to usergroups or roles (they anyway have to be build for applying a role, “guest” could be in practice “tester” or “one month subscription”), so for example call the status “restricted” and “full” (equals to former “member”).
For at the moment I only can imagine a “guest”-like retsricted status defined by time it could be an option in the user profile, where you add a date in an option “timestamp”. (Then “full” may be not really necessary if it equals to leave the field timestamp empty).
But of course then there is a lack of scalability if someone has another idea of (or plugin for!) status-restriction, for example numbered access: “You are allowed to publish five pages”.
Conclusion: A restricting status filed could in its principle consist of a counter, which is processed by something (for example time or a published articles counter) and by default presents a timestamp.

Now I have a headache myself. But a concept of status seems reasonable to me anyway.

Last edited by saccade (2006-01-12 12:55:49)

squaredeye · 2006-01-12 13:02:30

Michael, (Saccade)
Interesting concept. Your brain works so much differently than mine :)
I have a hard time putting those concepts into a working framework in my minds “eye”.
BUT, the examples you gave make a lot of sense.

One thing to possibly consider as we move forward, or a question at least to ask this group? Is: Would it be worthwhile to schem an entire permissions system, but then retreat a few steps, toward the most basic steps of implementation?

In other words: is it possible to offer the devs a FULL SCHEME for Rights and Permissions, but to encourage implementation, suggest that each step toward more complexity in the system is grandfathered in over the next several revisions?

(As we continue to debate/create/manipulate this possible scheme) I just thought to throw this question in the mix,
hope it doesn’t dissuade anybody’s train of thought :)

saccade · 2006-01-12 13:46:53

Matthew,

to me it looks like this:

of course we will have to retreat a few steps when it comes to implementation,
for it will probably not be possible to implement all suggestions at once within a reasonable amount of time.

But the more aspects of a full scheme are beared in mind and dealt with,
and the more the scheme is structured modular with planned gaps/cuts/interfaces for future implementations to fit in
the easier implementation will be in the first steps and in the view of the whole process.
And of course the scheme will be of more worth and power and also will be more convincing. (I hope it is so far!)

And: if you know there are things to come and the ground is prepared for them, also restrictions of a first implementation without all features will not hurt so much.

(And I hate it to create something and afterwards get aware that I have to change everything or that I did set myself into narrow borders because I didn’t take into account an important aspect.)

That will fully measure the work of thinking ahead a lot of steps and a lot of possibilities and a lot of requirements other users may have.

Of course I hope I am not annoying anyone with my insisting will to follow nearly every branch that opens at least to the point where we can see what a decision will imply.
To the workgroup:
If so, simply say “shut up”. I will possibly utter some protest, if it seems important to me (can’t help it), but I surely will reconsider if it is necessary what I am thinking/talking about, and I will follow a decision of the workgroup.

:-)

alexandra · 2006-01-12 13:48:36

> ma_smith wrote:

> Would it be worthwhile to schem an entire permissions system, but then retreat a few steps, toward the most basic steps of implementation?

Good catch, Matthew.

My idea is: work on the concept e. g. get the logic worked out first and then talk to the devs about which parts could be implemented. Maybe even a modul which can be attached to TXP makes more sense than implementing a comprehensive p&r system?

In other words:
it is worthwhile to schem an entire permissions system and then retreat a few steps, toward the most basic steps of implementation. :)

Other than that: bear with me, i need some time to read saccades post above….

Edit
saccade, we crossposted once again. I fully agree with your approach: post #68,
I second saccads emotion:
(And I hate it to create something and afterwards get aware that I have to change everything or that I did set myself into narrow borders because I didn’t take into account an important aspect.)

Last edited by alexandra (2006-01-12 13:56:19)

saccade · 2006-01-12 13:59:29

addition to my last post:

Take for example the concept of status:
We don’t necessarily need to follow it further, but we can say now,
that it has its place either in the users profile or as a prevalent group in the “user groups component”. Programmers then have to decide what fits more into the concept of programming, and when details have to be settled.
If we didn’t take into account a “status” then someone in the future may ask where to do it, try to set it up as a normal user group and then gets problems.
Those new ideas of timestamp can wait, but they have their gap/interface now.

EDIT (ordering my mind)

@alexandra
doublecrossposting!

As it takes a real huge dimension of system it is good to take a rest and look at where we want to go. Thank you Matthew for questioning!

As far as I see, we agree so far?

Last edited by saccade (2006-01-12 14:29:03)

squaredeye · 2006-01-12 14:27:23

Sounds great to me.
I thought that might be the case, but I felt like I needed clarification.
Saccade, please DO NOT shut up. I for one am enjoying the process, as lost as I can often be :)

saccade · 2006-01-12 21:56:47

alexandra wrote (Post #29 of Feature Requests: Assignment: section permission design)

So we all know what we are talking about, please read the following, more theoretical, article:
CMS-implementation II: description of the workflow through rights and roles. The article is availabe in german too.

In one of my posts I mentioned that the table of assigning rights in the article alexandra posted is a very convincing solution for me. It’s a matrix of “permission elements” and “roles”.
For our purpose a similar matrix could make a very usable “permission group setup” and as well an overview about the cascades of permission groups with different power.

Now I noticed that obviously it is not included in the english version.
I’m working on a graphic showing what it could do in our system.
If you are interested in a preview (and I’m interested in your opinion about it!), see in the german version the “Tabelle: Rollen- und Rechte-Matrix”.

Vertically there are the single elements of permission, they are bundled functionally (grey lines) into “permissions of commission”, “editing permissions”, “publishing permissions” and “admin permissions”.
Horizontally here there are “roles”, in our system there will be “permission groups” instead.

If we manage to sort our possible and requested permissions to systematical/functional bundles to choose from, it will result in a very intuitive and usable matrix.

Last edited by saccade (2006-01-12 22:08:12)

Textpattern CMS

Textpattern CMS support forum

#61 2006-01-11 00:25:55

Re: Rights and Permissions Workgroup

#62 2006-01-11 01:58:26

Re: Rights and Permissions Workgroup

#63 2006-01-11 02:17:03

Re: Rights and Permissions Workgroup

#64 2006-01-11 02:24:54

Re: Rights and Permissions Workgroup

#65 2006-01-11 02:34:52

Re: Rights and Permissions Workgroup

#66 2006-01-12 11:15:45

Re: Rights and Permissions Workgroup

#67 2006-01-12 13:02:30

Re: Rights and Permissions Workgroup

#68 2006-01-12 13:46:53

Re: Rights and Permissions Workgroup

#69 2006-01-12 13:48:36

Re: Rights and Permissions Workgroup

#70 2006-01-12 13:59:29

Re: Rights and Permissions Workgroup

#71 2006-01-12 14:27:23

Re: Rights and Permissions Workgroup

#72 2006-01-12 21:56:47

Re: Rights and Permissions Workgroup

Board footer