Rights and Permissions Workgroup

alexandra · 2006-01-09 18:36:36

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

Thanks :)

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.

Yes i agree and therefor i quite like to summarize and stucture privileges we may have to deal with. An advantage will be that it will be easier to understand for all of us what we exactly are talking about.

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”.

Okay but i have some problems with this approach. In fact Lauras privilege is to change privileges for ‘her’ group e. g. for certain members of her group. Right? As far as i am concerned, i would regard her privilege only in -> change Userrole. Correct? If so, this is not necessarily an Admin-privilege. An Admin-privilege is havin access to all kind of areas (Admin Panel etc.) and deleting article, members etc.

Now we come to the expressions: SuperAdmin and Admin.

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.

Right. Then again the expression Admin is an IT term meaning having all rights. So what is a Superadmin then? What i like to say is: Laura´s privileges f. e. are restricted to her role as Instructor – changing privileges of members of her Trainee-Group. She is not necessarily an Admin right away.
I get what you are thinkin saccade but i would stay away from the term Admin. We get mixed if we mix terms and their meaning.

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?

No you are right. We need a Superadmin but i would not call others Admin not even admin-publishers. Publishers have certain defined rights. Why call them admin-publishers? This is confusing.

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.

Again i agree but i do not agree on splitting it up in ‘publisher’ and ‘admin’.

[was ich meine ist eigentlich recht simpel. Wir sollten in den Definitionen genau unterscheiden. Per se ist in der IT Welt ein Admin eine Person mit allen Rechten. Was ist dann ein Superadmin? Um nicht durcheinander zu kommen, würde ich die Rollen, die das Recht haben anderer Leute Rollen zu ändern nicht Admin nennen. Ein Admin hat i. Al..g. das Recht Zugang zur kompletten Website/content zu haben und alles zu löschen was er will. Laura hätte das in unserem Beispiel nicht. Sie ist nur Instruktor und hat nur eingeschränkte Rechte bezüglich Zugang zu anderem Content und Bereichen der Website bzw. der Adminoberfläche]

Last edited by alexandra (2006-01-09 18:37:57)

alexandra · 2006-01-09 18:56:57

> saccade wrote:

> another modification is implemented in the graphic: user/usergroup. Does that reflect what you think of?

Yes, though i would list all Users in the column for Users. It is not necessary to change the grafic but we should keep in mind, that we have a list of really all users and a list of all Usergroups.

saccade · 2006-01-09 21:02:58

Alexandra,

i would regard her privilege only in -> change Userrole. Correct? If so, this is not necessarily an Admin-privilege.

correct and agreed,

stay away from the term Admin.

agreed again. You much better know the terminology and how it will be understand. I only wanted to describe some functions that could be described by other terms as well or better.

Why call them admin-publishers?

this was only an internal word to express that I mean a privilege with admin-permissions and publish-admissions.

i do not agree on splitting it up in ‘publisher’ and ‘admin’

I for myself can imagine, that someone is a “publisher” (means: has the privilege to publish content) without some of the other admin-rights. Or am I wrong again in understanding the term?

I think I have not enough knowledge to have a sense for all the implications of terms as “admin”, “publisher”. So I try to figure out what I mean and you must help me to get it right in terms.

Do I understand it right: Admin = SuperAdmin? So I would conclude that we need SuperAdmin only as a concept and call it “admin”? (I ask because this has effects on the graphic. If its so, I would change Superadmin to admin and we should find another word for Lauras Instructor Role permission.)

alexandra · 2006-01-09 21:47:53

In general an Admin has all privileges: access to all parts of the site, can publish, delete articles, comments … can execute processes, add new members…. and so on.

A Publisher can publish and edit articles but does not have necessarily access to fileuploads.

Laura can be an Instructor with the privilege to publish articles, change userroles but not delete comments. She is an Instructor – not an admin.

If we understand Admin as i pointed out, we do not need a Superadmin as the Admin has all privileges per se. Or in other words: Admin=SuperAdmin.

If the r&p concept gets implemented into TXP i personally would keep it simple and vote for having just an Admin or if you like better a SuperAdmin but not a SuperAdmin and someother Admins. That will mostlikely be confusing.

Admin: “Ich bin Root, ich darf das.” ( I am root, i can do everything”.

squaredeye · 2006-01-10 00:40:27

Shall I hold off on the list until we have a bit of this worked out symantically?

saccade · 2006-01-10 07:43:09

My inner distinction maniac (beer calms him down, but you know …) would like to make another suggestion.
I let him ventilate and hope you can cope somehow with this:

I suggest a semantic separation in the naming of “roles” and “permission groups”.

[Notabene: As we want to give the users of textpattern the possibility of creating and naming roles and permissions groups this semantic “rule” most possible will not continuously or constantly be followed. But for our intern purpose it may help. Due to some pros and cons let’s see, if it works.]

Workflow In the first place I have to point out, that I think there are two different meanings or definitions of workflow – or maybe it helps to say aspects of workflow:

The “system for routing documents between users” and its “management” as Alexandra stated in the beginning. In this description the technical aspect is predominant, e.g. who is admin, who is allowed to edit, to publish, how are all these right granted. All these things are related to textpattern, databases, menues and so on.
Workflow can (is and will) also be understand as the way tasks are organized in the office that uses textpattern. In this description organisational, hierarchical, personal, content-regarding aspects are predominant, e.g. who is the boss, who may allow or forbid someone something, who shall share jobs and who never should get access to seomething, who can work together and who must have very separate areas, how different kinds of content (european Literature, Poems, Fiction) are organized, are there trainees, is there an instructor? and so on. These elements of workflow have (by theirselves) nothing to do with textpattern, databases, menues and so on, but they should be depicted or reflected by them.

Roles
to me are tasks in the workflow in the second aspect: “European Literature Managing Editor”, “Instructor” …

Permission groups
to me are better be understand as elements of workflow in the first aspect: They grant privileges – independent from their exact determination to content and user(group) and in a combination of more or less single permissions or restrictions. The highest privilege is admin, one privilege has access as a managing editor, a privilege can change user(group)-roles, a minor privilege is only allowed to create text and set it pending (now in textpattern called “freelancer”). One and the same permission group if applied to different content and usergroups can result in different tasks/roles.

Semantic separation
Now I think it would help, to have separate semantics of naming.
Let me show that on “Instructor” and “Freelancer”.

Instructor: Laura is an “Instructor” in her Literature Office and should have rights to change roles for her bunch of Trainees. So her own role is well described by her job title “Instructor” – provided there is no other instructor, for example “Instructor for management trainees”.
Her permission group in this case consists of the permissions suitable to change roles for a user group.
This permission-group doesn’t necessary have anything to do with the job of an “Instructor”,
there could be a “Manager of Volunteers” or “Volunteers Instructor” who needs the same right, applied to volunteers,
or there could be a “Personnel Manager” (a role) who will have the same right to change roles for all users.
Both could share the same permission group, applied to different kind of content.
So it is better, if the permission-group in question has a more technical orientated name and the role reflects a name of workflow in the second sense above. Mention the Abbreviations common in offices (CEO, CSM and whatever) !
Of course you can name and setup the permission group “Instructor”, but that would result in confusion or unnecessary doubling permission groups (if you need “Personnel Manager” as well and don’t see the correspondence of rights in the name “Instructor” if it is given to a permission group). Also this would result in redundant paralleling roles and permissiongroups.
Freelancer. In textpattern at the moment it is a name for a very small portion of rights. But in the business a Freelancer could mean a lot of different things, is could also mean a very important, skilled person, who should be granted a good portion of rights. For example you could leave the rights for managing and editing a complete section to the Freelancer who does the “business history” for you. So Freelancer is much more a role within a workflow than a qualified portion of rights.

So my suggestion is to make a difference in the names and try to give more technical expressions to permission groups and more job referring expressions to roles.

NB: “Admin” in this sense is both: A role and a (technical) permissiongroup. And I see it as one of the fixed groups. As a role it could be given another name to reflect how the admin is called in the organisation (he may be root on the site, but normally he is not root in the business, for example he is called “CWA” Chief of Web-Activity or whatever, sometimes even a trainee or freelancer is given that task.).

Of course I see the difficulty in it. There will be intersections.
And of course it’s more difficult to find neutral expressions. But I think it is worth the effort, because it could result in a more sophisticated system of permission groups and a very versatile and comprehensible (nonconfusing) rights-system.

OK.
Please excuse the maniac if it throws you back to advil addiction,
now he has spoken and that helps,
if it is not reasonable, simply forget it,
I will give him some beer tonight. ;-)

Last edited by saccade (2006-01-10 07:54:37)

saccade · 2006-01-10 08:02:14

@matthew,

no don’t hold the list. I think both aspects must be reflected together. The list could help to get the things sorted.
Saying this I think of a list of the single elements of permissions, their relations to each other and a suggestion of how they are best combined to a basic set of permission groups could help finding the most suitable subdivisions as “admin”, “groupmanager” or whatever.

saccade · 2006-01-10 09:38:48

If we would separate terminology as I described above,
there would be one problem:

Are we (or feel we) bound to terminology of textpattern, as it is now?
or
Should we suggest some change?

At the moment there are the following “privileges” that are in fact Roles that most likely should be permission groups in the new r&p-system (and maybe in the textpattern installation package there should be preconfigured Roles with the same name and content-group “all” assigned to them):

Publisher (=admin due to its rights)
Managing Editor
Copy Editor
Staff Writer
Freelancer
Designer

What we discussed so far would lead at least to adding “admin” and therefore split the “Publisher” of present textpattern into two groups. (they of course could have both full admin rights, but it is important, that a publisher can be restricted from some of the admin rights.)

When making distinctions between technical and organizational terms,
then at least “Freelancer” needs to be changed, so we have basically as my suggestion:

(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

I hope this helps to understand what I mean.

Last edited by saccade (2006-01-10 09:48:43)

alexandra · 2006-01-10 12:38:13

@matthew,

no don’t hold the list. I think both aspects must be reflected together. The list could help to get the things sorted.

I agree. Find some nice technical terms as saccade suggested :) i think we need them to proceed.

I as well agree with saccade on the term ‘freelancer’. Freelancer is too vague, can just be anything or nothing …

saccade · 2006-01-10 19:33:37

Here for further thinking, ventilation, rethinking, elaborating and discarding (and feed for the maniac or advertising for advil/beer) a more basic graphic of our system (and the last modified before for comparison):

basic graphic of our system:

Last edited by saccade (2008-04-16 16:51:05)

saccade · 2006-01-10 19:55:06

beer = live
ascetic mode: off

:-)
to your health!

Last edited by saccade (2006-01-10 20:02:32)

alexandra · 2006-01-10 20:03:15

*lol .. these bavarians and their holy beer
enjoy ! :)

EDIT
for those of you speaking german, here is a flashanimation of a Userrightsmanagement system (OMECO (CMS))
Modul Benutzerverwaltung jetzt in Aktion

Last edited by alexandra (2006-01-10 20:11:20)

Textpattern CMS

Textpattern CMS support forum

#49 2006-01-09 18:36:36

Re: Rights and Permissions Workgroup

#50 2006-01-09 18:56:57

Re: Rights and Permissions Workgroup

#51 2006-01-09 21:02:58

Re: Rights and Permissions Workgroup

#52 2006-01-09 21:47:53

Re: Rights and Permissions Workgroup

#53 2006-01-10 00:40:27

Re: Rights and Permissions Workgroup

#54 2006-01-10 07:43:09

Re: Rights and Permissions Workgroup

#55 2006-01-10 08:02:14

Re: Rights and Permissions Workgroup

#56 2006-01-10 09:38:48

Re: Rights and Permissions Workgroup

#57 2006-01-10 12:38:13

Re: Rights and Permissions Workgroup

#58 2006-01-10 19:33:37

Re: Rights and Permissions Workgroup

#59 2006-01-10 19:55:06

Re: Rights and Permissions Workgroup

#60 2006-01-10 20:03:15

Re: Rights and Permissions Workgroup

Board footer