Rights and Permissions Workgroup

saccade · 2006-01-13 12:51:25

still busy
thinking about which single elementary permissions are indivisibly grouped – and thus can be assigned as a single “pack” to have access to,
and which can make sense to be assigned to different users. (at the moment I’m still in the admin field)

this is splitting-hairs-work

But I’ve come to a few paths of questions to ask when thinking about existing and planned permissions:

for whom could it make sense to give the permission to?
1. to an admin only? (the we perhaps could leave them out of the setup and grant them in a fixed admin-permission group)
2. or to an operator too? (restricted “co-admin” for special functions, e.g. a managing operator could decide how to deal with comments)
3. or to someone else? (e.g. presentational comment settings – “present comments as numbered list” – much better fit to the permissions for a “designer”-role even as it is present in txp now)
where should a permission possibly belong to? (e.g. if it has influence on presentation)
what new type of permissions we do need or wish?
is the permission to be splitted/applied to different areas? (example: is it a reasonable idea to have different comment settings in different sections applied by content groups?)

~~I have unfortunately to leave now quickly, but wanted to ventilate my thoughts so far.~~
I’m working on a table who shows that.

EDIT (some point clarified above)
Back again.
Do these questions sound reasonable to you?

Last edited by saccade (2006-01-13 16:09:56)

alexandra · 2006-01-13 16:55:02

Right now in TXP we have the following permissiongroups:

1 => gTxt(‘publisher’),
2 => gTxt(‘managing_editor’),
3 => gTxt(‘copy_editor’),
4 => gTxt(‘staff_writer’),
5 => gTxt(‘freelancer’),
6 => gTxt(‘designer’),
0 => gTxt(‘none’)

here are the accompanying privileges:

‘admin’ => ’1,2,3,4,5,6’,
‘article.delete.own’ => ’1,2,3,4’,
‘article.delete’ => ’1,2’,
‘article.edit’ => ’1,2,3’,
‘article.edit.published’ => ’1,2,3’,
‘article.edit.own’ => ’1,2,3,4,5,6’,
‘article.publish’ => ’1,2,3,4’,
‘article.php’ => ’1,2’,
‘article’ => ’1,2,3,4,5,6’,
‘category’ => ’1,2,3’,
‘css’ => ’1,2,6’,
‘diag’ => ’1,2’,
‘discuss’ => ’1,2,3’,
‘file’ => ’1,2,3,4,6’,
‘form’ => ’1,2,3,6’,
‘image’ => ’1,2,3,4,6’,
‘import’ => ’1,2’,
‘link’ => ’1,2,3’,
‘log’ => ’1,2,3’,
‘page’ => ’1,2,3,6’,
‘plugin’ => ’1,2’,
‘prefs’ => ’1,2’,
‘section’ => ’1,2,3,6’,
‘tab.admin’ => ’1,2’,
‘tab.content’ => ’1,2,3,4,5,6’,
‘tab.extensions’ => ’1,2’,
‘tab.presentation’ => ’1,2,3,6’,

Saccade did suggest some changes regarding TXP present settings:
<pre>
(Publisher) > admin
Publisher > publisher (is not necessarily fully admin, but may have the same rights when assigning them.)
Managing Editor > managing editor
Copy Editor > copy editor
Staff Writer > staff writer
Freelancer > contributor
Designer > designer</pre>

I would change them to and add as well:

<pre>(Publisher) > admin
Publisher > co-admin > publisher
Managing Editor > managing editor
Copy Editor > copy editor
Staff Writer > staff writer
Freelancer > contributor
Designer > designer > filemanager</pre>

An admin has all privileges including the privil. deleting the co-admin.
A co-admin has all privileges except for deleting the admin

Last edited by alexandra (2006-01-13 16:55:55)

Destry · 2006-01-13 17:06:59

Just wanted to bring this to people’s attention: here.

You’re not obligated to go that way, by any means (and I won’t be mentioning anything more about it here), it’s just being made available to you if you want it. Might be a whole lot easier than a long multi-page thread. Saccade I’m sure would really appreciate it since he’s been given the hardest task — drafting the text. You can use the wiki to upload mockups and so forth as well.

saccade · 2006-01-13 18:24:17

@alexandra

thank you for reminding me of this. I had it in mind before, but just on this piece of work didn’t think of it.
It should help me to get some more order in my thoughts.

Now I have some questions for I’m no coder:

Those keywords “article”, article.edit”, “article.edit.publish” and so on
1) They seem to be of a cascading structure. Do they apply the parents rights to its childrens (one of the important questions Jeremie asked)?
2) Behind the components of the keywords I think there is a definition of what a set of characteristics (e.g. “own”) or what set of “triggers” they do contain (e.g. “plugin”).
Or (maybe the sentence above tells more what I have in mind) do they only define the bare access to a e.g. menu which lets the privileged user do what is defined within this (part of) menu – in this case the definition of rights (more or less subsettings, fileds for creating content or the ability to view something) is technically independent from the keyword itself.

Did I express comprehensible what I mean?

@destry
I only had a short look on your proposal, and have to look closer soon, but from my first glance is seems reasonable for me.

coming back soon, Michael

alexandra · 2006-01-13 19:10:36

> saccade wrote:

> Those keywords “article”, article.edit”, “article.edit.publish” and so on
1) They seem to be of a cascading structure. Do they apply the parents rights to its childrens (one of the important questions Jeremie asked)?

No they are plain permissions: f. e.: article.edti means simply ‘allowed to edit articles’.

2) Behind the components of the keywords I think there is a definition of what a set of characteristics (e.g. “own”) or what set of “triggers” they do contain (e.g. “plugin”).
Or (maybe the sentence above tells more what I have in mind) do they only define the bare access to a e.g. menu which lets the privileged user do what is defined within this (part of) menu – in this case the definition of rights (more or less subsettings, fileds for creating content or the ability to view something) is technically independent from the keyword itself.

Did I express comprehensible what I mean?

:) i did not get you question, sorry

@Destry: i am not familiar with wikis and do not know the ‘wiki language/syntax’ which always kept me off using a wiki. nevertheless the idea is reasonable.

saccade · 2006-01-13 19:39:17

@alexandra

sorry, maybe I’m not yet sorted well, let me have another try from the “under construction”-area of my mind:
And let me clarify before – I’m still in the pure logic of the system

1) There ought to be some inner system or systematics of rights, some more and some less powerful, and some for example existing in couples or triples (submachines), some independently from another and so on.
2) Now this system has to be expressed somewhere, that is represented and filled into modules to handle it.
3) And now it leads to my question: Are the keywords part of the origin of the viewable order (or module-system) of rights. So the keywords or what is behind them generate the menues. OR are the menues, as we see them, the origin of the expressed system of rights txp has at the moment, and the keywords are secondary handles to give or deny access to parts of those menues.

I hope it is more clear now. (Maybe this is also a lack of my understanding of the database structure behind.)
If I’m not clear again, then lets try it in german.

alexandra · 2006-01-13 19:51:21

:) i send you an email…

Jeremie · 2006-01-13 21:15:08

alexandra wrote:
A co-admin has all privileges except for deleting the admin

And edit admin’s personnal datas (like email), and admin’s privileges. Right ?

saccade · 2006-01-13 21:35:51

ok, at last I’ve finished a first stage regarding permissions setup.

EDIT
Let me describe shortly what has been my plan of process:

The task was and is to clarify in which way permissions can be set up in a “permission group setup” to build ‘permission groups’ and in consequence lead to ‘roles’ that grant privileges or rights to ‘user groups’.
If we want to create a versatile r&p-system, that can be tweaked to every job workflow (see the second definition of workflow in my post #54) we have to carefully examine all elements of permission and have to become clear for every element
1. if it has a single application to a unique and specified role or usergroup. This means that the permission applies solely and only to that one group. Then of course there is no need of setup, because the rights belong to a permission group by nature. This of course is the case for a set of permissions that should be granted only to an admin.
2. if it could be applied to any role or to multiple roles. In this case it has to be set up in a ‘permission group’ as the first step leading to a ‘role’, where (to which users) it should belong in the specified workflow.
3. to which area of content it can be applied and if there are parallel elements which have to be applied to a different area of content. This decides whether there is required a qualifying setting within the ‘permissions group setup’ or if it is enough to assign externally a defined ‘content group’ to create a ‘role’ and specify its area.
4. if there are packs of permissions who are always to be assigned together (e.g. there are 4 single settings in the “import” tab, making 4 single permissions: it only makes sense to have access to all of them. so a single permission to access one of them is of no use, it is a permission pack to be assigned together. [[Of course one may ask, if the “default comments invite”-setting really is an integral part – or if it also may be left out here and leaved to someone who has the rights to define (and fix!) the wording. But that I admit is hairsplitting. It is a good example of the systematical problem though. It is a decision how far we want to straighten the logic structure of the system. ]]
It is also to be taken into account how permission elements are grouped functionally and under the aspect of usability. This also reflects workflow aspects. It will ease the decision what is best granted to which ‘permission group’ > ‘role’ and how different tasks cooperate.
When introducing a system of rights and permissions there are additional tasks required by the system itself, which have to be added.
Also modularity and scalability have to be beared in mind. So if there are additional permissions to come they could be integrated without having to rebuild the whole system.
END OF EDIT</ol>

See here a pdf-file with what I figured out so far. EDIT v1.1 slightly updated

In the first step I revised all permissions granted to admins so far.

My approach is to see whether there are (administrative) permissions which <ol>

relate to admin-rights only (they could be left to admin, without any need to integrate them into a system of permission groups) and
could possibly be wished to grant to some other user with special (administrative, not in the sense of a full “admin”) rights (I call it for example ‘operator’). They should be configurable within a permissions group system and possibly be granted to a user who does some related task.

An example:
You want someone to do (only) the user-management (= create users, assign them privileges/roles, but maybe not delete users [that depends on his special setup] and of course he has NO access to the admin and the admin-privilege/role, so he can’t make himself full admin).
But this manager shouldn’t have access to the technical base of your site (PHP, RSS, create sections, edit articles …).

Another:
You have a designer, who should set up the whole site for you. Because he is taking his job seriously, he also wants to test the visual effect of different “date format” settings. Your admin will get crazy, doing that again and again for the designer (or the designer – who loves to work at night). So he should have access to the date-settings.
And he wants to include in his design the way comments are presented. So he ought to have access on all settings that regard the presentation of comments.

EDIT:
And of course my comments in the pdf are a proposal, I cannot imagine all situations and I surely will fail to see some problems that occur. And I haven’t finished yet.
For example, I thought a while about the possibility of giving the right to name custom fields to a designer, for sometimes a designer does the concetional wording too (but that’s my experience of a designer/texter). That may be unconventional and possibly dangerous (if assigned without care) –
but at least I would continue to assume that in some workflow of txp-users it may be required to include an “operator” maybe called “conceptioner” (=role) as a non-admin who needs to get the right to name customfields – and in conclusion I would put the customfield-setting to the permission groups setup.
Now your opinion is needed.

Last edited by saccade (2006-01-14 10:19:25)

alexandra · 2006-01-14 19:47:00

I referr to saccades previous PDF: at present TXP has listed adminrights under TAB Admin. There are some rights which should not be solely admin rights but althought rights f. e. a designer could get. The permisions in question i did sorround with a red border.

admin-permissions

Please let´s discuss which permissions should be applied to the admin and which should be taken out of the admin Tab.

Last edited by alexandra (2006-01-14 19:53:47)

alexandra · 2006-01-14 20:03:57

Some questions concerning a Co-Admin:

Does a co-admin make sense to you?
Is a co-admin really needed?

I noticed i quite like to work with a co-admin. A co-admin should have

all privileges except for deleting the admin
edit admin’s personnal datas (like email)
send admin new password
does not necessarily have f. e. acces to the logs
should have the permission to setup user/groups

But i am not sure the co-admin concept really makes sense.
Your ideas?

saccade · 2006-01-14 20:38:32

Thank you alexandra, great work!
And thank you for helping me get the admin-thing right!

May I add some more permissions in question to post #85?

Date format (*)
Archive date format (*)
Comments date format (*)
Default invite (Comments) (here too often wording belongs to my design, or I have to test in which size which words look best)

(*) As a designer I often include decisions about date formats in my designs, for sometimes you can show a more human way of referring to date than a computerized way – or the other way round: you want to have a very technical impression of your site and best need hex-dateformat ;-)

User setup
And of course I want to take the user setup (“Authors” and “Add new author”) out of a pure admin-restriction (co-admin is not enough, because that still is too much additional right).
It should also be accessible to other users if you grant them that right.
Then of course the right to assign the privilege “admin” must be taken out of the privileges a user can assign to other users! This of course is an admin-only-right.
Of course the “Change your password” and “Change your e-mail address” also still is restricted to admin only.

Custom fields
To set up and name custom fields is by logic the same thing as to set up sections and categories and thus in my view also should be open to a “role” someone defines for this task. (And not be solely for admins)
Because it has the aspect of “naming” the fields (and this appears in design) it may also be useful for a designer, if he does wording as well. But if access is customizable we could leave it to the users, to whom they grant it.

Because I think we need to think about a few “roles” that reflect areas of responsibility I would think about creating a role “content structure manager” or “content organisation manager” who has the rights to create sections, categories and those custom fields.
To the other possibility to give it to a designer I admit: The idea to give it to a designer is very special. But it should be possible.

Last edited by saccade (2006-01-14 20:40:54)

-P- · 2006-01-14 21:47:38

<blockquote>Of course the “Change your password” and “Change your e-mail address” also still is restricted to admin only.</blockquote>

I disagree with this one. Or am I the only one hosting websites, blogs and forums with users that tend to forget their passwords constantly no matter what you tell them? :) I also feel that at least advanced users should have an option to change their own email-address.

Of course only admin as root user can change/edit root admin pw and email but I think that for users, they should have rights to change their own details.
Can be a bit complicated to have a built in admin approval system like many discussion boards have? I vote for simple notification via email like Wordpress has, “User A. has changed her/his password.”

I have been following this discussion and it is great things you´re planning here! Really appreciate the thinking you´ve done.

But I do hope that while planning best user management for groups, it´s also remembered that many times there really are only two user groups.

1) Site admin, who builds the site, takes care of the layout, settings, plugins&stuff and 2) The actual user who owns the site (has paid for your work to have everything set) and uses it.

To them it can´t be so much of rights and privileges and restrictions, it should be just thinking about most usable way how to take away from their sight all the stuff they don´t need and care and still maintain enough options for them to handle their own site fluently.

Last edited by -P- (2006-01-14 21:57:28)

Jeremie · 2006-01-14 21:58:41

alexandra wrote:
Does a co-admin make sense to you?
Is a co-admin really needed?

Yes and no. I would probably use it on most of my multi-authors websites, but it may be overkill as a default install. Since everything is should be easily customizable, I’m not sure we need it in a default install.

squaredeye · 2006-01-15 03:16:03

Hey, I’m back.
I’ve been sick, and Brighton’s baptism is tomorrow, sorry for the absence. You’ve been hard at work (all of you).

There’s a lot to catch up on:
To answer Michael: the pdf is great. Makes a lot of sense. As before, I am picking up on your flow. I am personally onboard your idea of an operator (which I believe we are speaking of as a co-admin as well) correct me if I am wrong. I think all that you are coming up with is becoming more and more coherant :)

So to answer Alexandra:
I do like the idea of a co-admin.
I like the idea that the Admin can create a user (or edit an existing user) for whom he/she can apply permissions or apply the user to a permission group or series of groups that enables that user to share admin rights (except those that must remain solely admin). I see this as an option that might be available, but not necessarily setup from the default install. Jeremie, is this what you mean, in your post above?
Also, your graphic is really helpful. I agree with all that you circled in addition to Michael’s suggestions that these pieces need some flexibility in who they are assigned to. I think the direction of allowing the Admin role to be “reset” is a good one, because it helps us apportion the role of website creator/designer/developer in a role seperate to that of the website owner/(possibly client of afforementioned creator).

To answer P:
I agree with you wholeheartedly. The hope is that this setup would create a customizeable scenario in which the simplest use of Rights and Permissions and a wholey more complex use of Rights and Permissions could exist in the same install through a series of adjustments to your preferences (Rights, Permissions, Roles, Users, Groups, etc.)

I think it will be important to achieve a logic (as Michael aptly continues to refer to it) in order to truly get a well oiled machine running here. THEN, we could propose a series of (events/visual changes) that might occur when a user is of a certain Role/Status/Group. This is a big project.
*******************************************//////************************************************

Again, Thanks to everyone, this is really fun for me, and enjoyable. I am learning tons and glad to stand on yalls shoulders and look to see what’s next.

Matthew

Last edited by ma_smith (2006-01-15 03:17:04)

Textpattern CMS

Textpattern CMS support forum

#76 2006-01-13 12:51:25

Re: Rights and Permissions Workgroup

#77 2006-01-13 16:55:02

Re: Rights and Permissions Workgroup

#78 2006-01-13 17:06:59

Re: Rights and Permissions Workgroup

#79 2006-01-13 18:24:17

Re: Rights and Permissions Workgroup

#80 2006-01-13 19:10:36

Re: Rights and Permissions Workgroup

#81 2006-01-13 19:39:17

Re: Rights and Permissions Workgroup

#82 2006-01-13 19:51:21

Re: Rights and Permissions Workgroup

#83 2006-01-13 21:15:08

Re: Rights and Permissions Workgroup

#84 2006-01-13 21:35:51

Re: Rights and Permissions Workgroup

#85 2006-01-14 19:47:00

Re: Rights and Permissions Workgroup

#86 2006-01-14 20:03:57

Re: Rights and Permissions Workgroup

#87 2006-01-14 20:38:32

Re: Rights and Permissions Workgroup

#88 2006-01-14 21:47:38

Re: Rights and Permissions Workgroup

#89 2006-01-14 21:58:41

Re: Rights and Permissions Workgroup

#90 2006-01-15 03:16:03

Re: Rights and Permissions Workgroup

Board footer