Rights and Permissions Workgroup

-P- · 2006-01-15 15:54:07

<blockquote>saccade wrote:
too many people do not use their rights and permissions to vote.
(it really hurts me if democracy suffers lack of commitment).
</blockquote>

Yeah, I voted for guy I think should have most root admin access rights for Finland. :D

<blockquote> discussing admin permissions:

-P-s suggestion (see post #101) directly affects the question “what are really solely admin rights?”

Here we have an owner, who doesn’t want to have all admin rights. He leaves the technical stuff to the admin.
On the other side he has rights that we regard so far as typical admin-rights.

He wants to have the rights

to define the site name
define the site tagline
define primary comments-settings

If I think correctly, these could indeed be given to a user (of course he should be a mighty one in the job/business workflow) without touching essential admin rights (for example url, php-settings, link-mode, folders and paths, utf/iso-settings, plugins).
Is that correct?

Background: There are groups, who like to change their name constantly. Experimental approach. To me at least it sounds reasonable, that an owner wants to have direct access to the sitename (without having to speak with anyone).
(For as well, as a designer/conceptioner it makes me nervous, edgy, fidgety if an owner wants that. Too often a good concept dies collateral).</blockquote>

Yes, I did think about that “can change site name” right at first but desided to leave it there in my sample screenshot of “Site owner admin”.

I am speaking here only from my point of view of user administration with small sites which I´ve done quite a lot with different publishing systems. I think you have everything already well covered with sites that have multiple authors so nothin to add up there.

To those small sites the whole thing is not so much about for example trust and security(1). More like how to be able provide simple enough admin interface for users that don´t have technical skills/ are having somebody else to take care of it.

And based on customized admin interfaces I´ve made, users do prefer having an clean interface. They are all grown up and adult people I deal with when making sites so I could as well sign up them to be super admins but it is easier and nicer to them handle and learn the system when things they do not need are out of sight.

So I´m talking here about achieving also basic user friendly admin interface with enough options to admin and configure your own site with out having a need everytime to ask somebody else to do it for you or fear that you end up doing something that will crash your site.

That is a bit different thing but I believe could be achieved with same carefull Rights and Permissions -planning.

I believe it is much easier to plan user administration for publishing tools that are meant only and mainly for sites with need for large user and content management but since TXP is suitable for both personal use and commercial use with one or two or multiple users we should be thinking all the time the most effient way to please all these needs.

(1) security used here in a term that you want for example prevent user A. deleting posts from user B. Here´s no need for that since there is only one user posting articless anyway.

Last edited by -P- (2006-01-15 16:07:43)

saccade · 2006-01-15 15:54:54

@wet
Thank you! That is a good bottle of fuel for thoughts!

saccade · 2006-01-15 18:41:13

@-P-

Yeah, I voted for guy I think should have most root admin access rights for Finland

You think of “Change site name”?

Last edited by saccade (2006-01-15 18:41:57)

-P- · 2006-01-15 19:00:24

@saccade

Happy with the site name. Some improvement could be done with the tagline ;P

alexandra · 2006-01-15 19:39:35

@ p

we should be thinking all the time the most efficient way to please all these needs

agreed .. as wet said: KISS :) keep it smart and simple

I quite like to pick up the question for the ‘true’ admin privileges:
textpattern.com/viewtopic.php?pid=94803#p94803

Once we have sorted that out, we got rid off that and only have to deal with and structure the other privileges.

Last edited by alexandra (2006-01-15 21:00:32)

saccade · 2006-01-15 19:58:09

Here a list (without comments) what in a short review is left for solely admin permissions. Some are in question, but I think those are best in the hands of an admin.
[e.g. time zone won’t change too often, owner won’t really have to change a time zone]

The other permissions (not showed here) in most cases will also be admin tasks but possibly could be left to owner, usermanager or whatever mighty user.

„Diagnostics“ Tab
Site URL
Time Zone [in question]
Daylight savings
Permanent link mode
Logging
Production status [maybe in question]
Mail comment to author
Disallow user images
How many articles on RSS
Send last-modified header
Image directory
Temp folder
Max Upload File Size
File upload path
Ise ISO-8859-1 for e-Mails
plugin_cache_dir
Comments require user name? [in question]
Comments require user email? [in question]
Access „link“-settings
Textile links description by default? [?]
Update Ping-o-matic
Allow PHP on pages?
Allow PHP on articles?
Show comment count in feeds?
Syndicate excerpt?
Include email in atom feeds?
New comment means site updated?
Never display email?
Allow form override
Attach titles to permalinks?
Permalink title format
Expire logs after
Use plugins?
Ping textpattern.com
Use DNS?
Use admin side plugins?
Use nofollow on comments?
Use mail on feeds id?
Max URL length
Spam blacklists

Different to alexandras list are “PHP on pages” (this I regard as an admin right, for he does the technical thing) and my additional suggestions in a post before.
And my question: Why assign the permalink-setting to a non-admin?

And of course I think the following tabs are “admin only”:

„logs“ Tab
„plugins“ Tab
„import“ Tab

Last edited by saccade (2006-01-15 20:07:40)

saccade · 2006-01-15 20:17:33

For better understanding:
These I would take out from solely admin rights:

Site name
Site tagline
Date format
Archive date format
Use Textile
Accept Comments
Moderate comments
On by default?
Present c. as numbered list
Default invite
Comments date format
Comments mode
Autom. append comments to articles?
Show article count on categories
Edit raw CSS by default? [in question – a technical setting]
custom field 1
custom field2
custom field3
custom field4
custom field5
custom field6
custom field7
custom field8
custom field9
custom field10
Articles use excerpts?

Access „Authors“
Edit real name
Edit email
Assign privilege
Delete author
Create new author
Reset authors password

Still in question – I have no scenario in mind for this:

Access „Manage Languages“
currently active language
view Install/Update menu
access to install/update

Last edited by saccade (2006-01-15 20:19:53)

-P- · 2006-01-15 21:21:59

Few things:

I´d suggest thinking “if it does not hurt them/you, why not let it to be a user right”.

Log files, an easy and interesting way even to a basic user to see, where do the visitors to their site come from. So why should it be solely admin right?

Require name and or email in comments. Does not hurt you, what ever the setting is. Does not hurt the user untill and if there starts to be problem with anonymous commenters he/she/they can start requiring email and name for comments.
I´d also let users to deside, if they want to have an email notification of comments submitted to articles or not.

Autom. append comments to articles is something I could easily think basic user may find confusing, that one still to only admin rights.

Presenting comments as a numbered list can have an affect to site design and same goes with usage of textile. I would leave them as it is now, solely admin rights.

Same goes with commets mode. It is dependent of site design, should be admin only decision, of cause based on user needs. But that should have been covered when making the site.

I´d keep language option also as an admin option. It can be also a matter of design…. user desides to change language without consulting you. Next time you visit the site and notice the site public interface beeing a weird mixture of german and finnish for example. I´d say it hurts you :D

(Not really relevant with user groups but thing that I´d lose totally from everybody, both admin and user groups and leave it to be site admin preferences option only is comments invitation in event=article screen. I don´t know why it even is there? Surely is not good accessibility and can be very confusing to site visitors if first article says “Comments 5” and second article says “Opinions 5”. So I feel that invite is vain and just adds extra form there and should be cleaned out.)

Everything else as saccade posted :)

Last edited by -P- (2006-01-15 21:32:55)

saccade · 2006-01-15 21:49:26

@-P-

Presenting comments as a numbered list can have an affect to site design

Exactly. That is the reason why I think it should be kept closely to the right to “edit page html, forms and css” (in fact it is a part of that task because it effects the html-code and the effects of css as well).
And that’s why it definitely shouldn’t be an admin-only.

I think “name and email in comments” could possibly hurt me a lot as an admin: If I require it (for example to make it a bit more difficult for robot commenters), the user doesn’t (because he isn’t really interested in names and emails and likes anonymous posts as well), and then after he disabled the option thousands of robot posts are to be cleaned out by (of course!) me (“You’re the admin”). But maybe I’m wrong or this is outdated with the new security tools.

“Comments invite” truly should have a better place.

Last edited by saccade (2006-01-15 21:51:58)

-P- · 2006-01-15 22:28:48

<blockquote> saccade wrote:
Exactly. That is the reason why I think it should be kept closely to the right to “edit page html, forms and css” (in fact it is a part of that task because it effects the html-code and the effects of css as well).
And that’s why it definitely shouldn’t be an admin-only.</blockquote>

okay.. you are thinking here same time both admin and designer rights. Presenting comments as numbered list definitely goes to site style section. And thinkin it from that point of view, shouldn´t be only admin-option. But it doesn´t belong to basic user either nor the ability to switch between normal and popup commets.

<blockquote>I think “name and email in comments” could possibly hurt me a lot as an admin: If I require it (for example to make it a bit more difficult for robot commenters), the user doesn’t (because he isn’t really interested in names and emails and likes anonymous posts as well), and then after he disabled the option thousands of robot posts are to be cleaned out by (of course!) me (“You’re the admin”). But maybe I’m wrong or this is outdated with the new security tools.</blockquote>

You do have a point there. But it is not always the worst situation. Many of the sites I run, used to have huge problem with spam. After moving sites to run with Textpattern, that just haven´t been an issue anymore thanks to forced preview.

And I see that part also more of a matter of good user consultment … telling user right in the beginning when teaching how to use the system that it is not wise to change your site name once in a week, if you get spam, you should require commenters email etc.

saccade · 2006-01-15 22:41:33

wet wrote

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

Now I have been thinking for days about good and simple ways to structure permissions. There I went from the lines of current structure. I didn’t yet find a fully satisfying system.
The thought of identifying all objects is very appealing to me.
I really don’t know if it could be programmed and what load of work it would be – I hope it is within reasonable possibilities, but let me tell what it could be its advance in terms of logic:

It could lead to a more simple system: You have

object types (like “setting”, “article”, “section”, “category”, “excerpt”, “template”, “form”)
you can use object qualifiers to specify the objects (qualifying characteristics like “date format” for ‘setting’, an “authors name” or a “status” or “title” for ‘article’, section name(s) for ‘section’ …)
and a small but elementary set of permissions, e.g. “view”, “create”, “edit”, “change”, “delete”

Example: You can define an object group containing “articles” qualified by the ‘categories’=‘logic/suggestions’ with the ‘status’=‘pending/draft’ and the ‘author’=‘Michael’.
The permission defines what you’re allowed to do, maybe “view” what I’m thinking.

With this set of permissions and a way to specify just every set/subset of object you could define just anything – from admin-rights to do all
to the “right” to edit only the excerpt of the article “Albert Einstein”

This are first thoughts, maybe they don’t proof. But I’m interested in what you think.

saccade · 2006-01-15 23:00:24

@-P-

And I see that part also more of a matter of good user consultment … telling user right in the beginning when teaching how to use the system that it is not wise to change your site name once in a week, if you get spam, you should require commenters email etc.

Of course that would make a lot of things obsolete – if it would work.
But after a lot of years of teaching users what to do I learned that in most times they don’t listen or don’t want to have too much things in mind. Or they forget. And sometimes “too much” equals “more than two”.
In my full profession I have a lot to do with education and paedagogic, I do my best and I do not give up and I try to find the right way in every case :-) And I partly can understand why users don’t want to be teached to much.
Just a few weeks ago I told someone whom I offered to have txp on his website, that it will be simple to tell his users how to deal with txps “write” tab. There are only a few things to bear in mind. They fit on half a letter sheet.
But it was exactly this what lets him hesitate.

So you are right: It all is a matter of good user consultment. But that is not always enough, sometimes you have to make it waterproof because the users doesn’t want to have to deal with it in any way.

Though: let us take out everything from admin-only, that could be done/required by another user.

EDIT: You can see from my words that I’m passionate about good user consultment (unfortunately there is so much bad out there!), but I’m also very skeptical about the success of good user consultment. So I would say: do both, tell them it’s not wise to … and then hide the menues from them. They will be thankful – and if they later ask to have the option, you can unhide it.

Last edited by saccade (2006-01-15 23:13:34)

Textpattern CMS

Textpattern CMS support forum

#109 2006-01-15 15:54:07

Re: Rights and Permissions Workgroup

#110 2006-01-15 15:54:54

Re: Rights and Permissions Workgroup

#111 2006-01-15 18:41:13

Re: Rights and Permissions Workgroup

#112 2006-01-15 19:00:24

Re: Rights and Permissions Workgroup

#113 2006-01-15 19:39:35

Re: Rights and Permissions Workgroup

#114 2006-01-15 19:58:09

Re: Rights and Permissions Workgroup

#115 2006-01-15 20:17:33

Re: Rights and Permissions Workgroup

#116 2006-01-15 21:21:59

Re: Rights and Permissions Workgroup

#117 2006-01-15 21:49:26

Re: Rights and Permissions Workgroup

#118 2006-01-15 22:28:48

Re: Rights and Permissions Workgroup

#119 2006-01-15 22:41:33

Re: Rights and Permissions Workgroup

#120 2006-01-15 23:00:24

Re: Rights and Permissions Workgroup

Board footer