Rights and Permissions Workgroup

alexandra · 2006-01-12 22:13:57

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.

Yes.. that´s why i asked for a ‘permission list’ as Matthew did put together above. We need such a matrix just in english – so Matthew will understand as well :)

no beer tonight saccade?

saccade · 2006-01-12 22:56:15

no, unfortunately I’m short of beer again – waiting for a better time ;-)

saccade · 2006-01-12 23:14:36

Matthew and Alexandra,

Thinking of all special kinds/sorts of permission belonging to *admin*-tasks:
If listing all the permissions
which order would you suggest? (e.g. from most important to optional, or ordered by position in workflow).
What makes the most sense to a not so skilled user?
Which of the permissions in Matthews list would you collect under “admin” – which under another title?

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)

Textpattern CMS

Textpattern CMS support forum

#73 2006-01-12 22:13:57

Re: Rights and Permissions Workgroup

#74 2006-01-12 22:56:15

Re: Rights and Permissions Workgroup

#75 2006-01-12 23:14:36

Re: Rights and Permissions Workgroup

#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

Board footer