Rights and Permissions Workgroup

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)

wet · 2006-01-15 10:13:03

Maybe I am overwhelmed by the sheer amount of text in this thread, but I haven’t managed to locate the general concept of an “object owner” in it, which imho would reduce the need for super-, minor- and co-admins by turning every owner of an object which is controlled by permissions into an admin for that given object (content, persons and other stake holders like groups or roles, site presentation, feed presentation).

Add the capability “change object ownership” and you can designate administrative tasks to just about every stake holder on object granularity level. Keep in mind that an object’s creator doesn’t have to be an object’s owner, and that object ownership may change either manually or automagically at state transitions (for instance whenever an article goes from draft state into live state).

Saccade wrote:

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.

This is already implemented now. Textpattern determines the existence of permissions in one core function (has_privs). On the downside, every additional permission has to be verified prior to the execution of an action requiring a certain privilege. This has to be done inside the code performing that action and will thus probably introduce code modifications deliberately sprinkled all over the backend code with every newly introduced permission object.

Jeremie · 2006-01-15 10:41:39

ma_smith wrote:
Jeremie, is this what you mean, in your post above?

What I meant was: the pre-requisite on which we based our discussion is that every action within Textpattern is linked to one right (do/can’t do), and every user is also linked to every right (there are things on top of that, like “rights-packs” – roles – and others, but that’s secondary for this particular question).

So every admin can create whatever co-admin, secretary, assistant, shoe-shiner or desk-cleaner he wants and needs, with exactly the access, rights, privileges, permissions he wants them to have. It’s beyond “customization”, and more within a “creation” paradigm.

The question was “in a default install, along with AdminUserGroup, WriterUserGroup, PublisherUserGroup, etc. do we think a CoAdminUserGroup would be needed, helpful, to most people and/more TXP beginners ?”

And basically my asnwer was: “IMO, no, even if I would probably create it for my personnal use”.

On this topic, I’m wandering if it’s good practice to merge the logic of the permissions systems, with the backend management UI, with the default install configuration, and other topic on that matter.

Maybe a thread split on these mains topics, to keep each sane, easy to read, and at this begining stage independant from one another ? Just a thought…

Last edited by Jeremie (2006-01-15 10:43:21)

alexandra · 2006-01-15 10:49:08

The general concept of an “object owner” is appealing to me.
Before we misunderstand: an object owner as you (wet) understands it, is someone who has for instance the right to decide on the presentation of the Date format. Date format is the object, correct?

wet · 2006-01-15 11:08:32

Sample objects:

an article, a image, a file (content objects)
a page template, a form, a date representation setting, a section definition (presentational objects)
a category (structural objects)
a user, group, role (stake holder objects)
a plugin (hard to categorize given the nature of plugins)
…let your mind drift…

From my point of view, one main task of this work group is to identify all objects in a textpattern system which will receive individual permissions. This might be coarse along the lines of the current impelementation (an article being an atomic object, all preferences sharing one permission level), or granulated down to a hair split level (separate permissions for excerpts, bodies, form overrides; separate rights for date presentation format, public vs. admin side plugins, “excerpts on feeds?” and so on).

This is a hard task as it seduces one into generating an overly complex system which will be hard to implement and maintain, just out of the urge to create the uberflexible, most future proof design which will stand the test of time and try to compete with ERP permission systems (think SAP / Oracle Financials). My base line: KISS.

alexandra · 2006-01-15 11:10:49

@Jeremie

On this topic, I’m wandering if it’s good practice to merge the logic of the permissions systems, with the backend management UI, with the default install configuration, and other topic on that matter.

Well, right now we work solely on the logic of the permission system but have to mix in some practical issues and examples so we all know what we are talking about. We do not talk about changing TXP´s interface or permission systems right now. This will follow in a next step once the logic of the r&p system is worked out. That is my opinion.

Jeremie · 2006-01-15 11:16:49

Alexandra, ok it’s fine by me. But then, I don’t understand the “co-admin” question/issue.

Wet, I don’t understand what would be the use of the object concept. An admin would still have to define precise rights for/on/over it. I don’t get the pro of that conceptualization (is that english ?).

Textpattern CMS

Textpattern CMS support forum

#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

#91 2006-01-15 10:13:03

Re: Rights and Permissions Workgroup

#92 2006-01-15 10:41:39

Re: Rights and Permissions Workgroup

#93 2006-01-15 10:49:08

Re: Rights and Permissions Workgroup

#94 2006-01-15 11:08:32

Re: Rights and Permissions Workgroup

#95 2006-01-15 11:10:49

Re: Rights and Permissions Workgroup

#96 2006-01-15 11:16:49

Re: Rights and Permissions Workgroup

Board footer