Rights and Permissions Workgroup

alexandra · 2006-01-15 11:48:01

@Jeremie
forget about the co-admin. i thought the false direction…sorry :)

@wet

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.

Exactly. I wholeheartedly agree. We definately need a table summerazing all permissions and then structuring them (along objects). Actually that should be our main task right now!!

Wet´s object concept is similar to the object model in programming languages. The owner of the content object f. e. has all permissions regarding the setting within this ‘object groupt’. The benefit of the concept is that we do not need to specify a co-admin or usergroup-admin or whatever.
If i am wrong, please correct me wet.

Last edited by alexandra (2006-01-15 11:48:36)

-P- · 2006-01-15 12:18:49

If I understand you guys correctly, I think you are getting very close to most effinient way to solve rights and permissions.

Defining content objects would be probably best way to achieve very customisable user administration meeting different needs no matter if the needs are for web magazine with tens of writers or for single site owner with no interest/need whatever to even have visible those sections she/he does not need/ is paying somebody else to take care of.

saccade · 2006-01-15 12:41:17

As far as I see, the concept of an “object ~~owner~~” (as well as an owner) is implied (or at least could be done) in the concept of “content group” (which in our present scheme defines where a “permissions group” is applied to to create a “role”).

Most of wet’s sample objects I also had in mind being possible contents of a content group:

article (as well image or file)
section (I didn’t yet think about section definition, but it is not far)
category
user and user groups (I didn’t think about – aren’t they dynamic? – user groups defined following to their role)
I also had im mind the “hairsplitting” way to give access solely to the exzerpt-part of an article (e.g. to the trainee-group) but I located this in the permission-area.

“template” i didn’t see as an object (= content) but as a permission.
But maybe it is an advance to look at it as an object like content. I have to think about.

Am I right, that thinking about an “object owner” also leads to another way of access?
Like this:
You have a (complete) list of objects (maybe the same as “content groups”) as your origin point, and assign a definition of users to it, who have permissions for that object (this definition could be our “permission group” or the combination of “permission group” and “usergroup” = “role”.

So as far as I see the concept of “objects ~~owner~~” could be fully implemented within our scheme, it only needs a different assignment of the five columns ([user/usergroup – role – permissiongroup] – [contentgroup]).
Content group as well could be called “object group”.

EDIT
And (after reading alexandras post) this concept would apply our scheme to the structure of permissions itself: “date format” regarded as a content_(=object), the right to change/define it as _permission and a user (=owner) who is granted that right.
That sounds reasonable to get a logic way to deal with permissions.

EDIT2 Above at first I wrote about “object owner”, but I think I meant the whole thought of dealing with “objects”. corrected some words to reflect my thought better.

Last edited by saccade (2006-01-15 22:05:27)

saccade · 2006-01-15 13:25:16

just let me throw in a very basic thought about rights:

For some settings or content elements it could be good to be allowed to see them,
even if you are not granted any right to create/edit/change them.

So I think we should add a basic permission

“visible”
besides create/edit/change and so on.

-P- · 2006-01-15 13:34:53

Here is an suggestion based what I posted above about what should/could be administative objects assigned to site owner who is not into/does not need to care about all “the technical stuff”.

Off course, when there are several authors, for clarity these are admin (besides the user email and pw) options that would be only assigned to site admin or to site admin and co-admin.

example screenshot

saccade · 2006-01-15 13:47:58

@-P- (post #88) (EDIT: crossposted with last post)
Regarding “Change your password” and “Change your e-mail address”:
I agree, I also think that it would be very helpful, if users could set up their password themselves (of course with higher rights of admin or “user manager”).

I only wanted to clarify that I don’t want to give any access to admin-rights to a non-admin “user manager” by accident.

Regarding situations with only two users:
With our scheme it should easily be possible to delete all superfluous groups, roles and permissions and only leave the two roles or groups needed for a two-person-workflow.
It is only a question of filling the frame we provide.

Maybe we should later (!) think about something like providing different “preset configurations” for “small workflow” and “multi workflow” in the installation of txp.

Last edited by saccade (2006-01-15 13:50:32)

saccade · 2006-01-15 14:04:09

@-P-
I think I didn’t exactly match your thought in post #88 as I see now.

What you showed regards the user interface. (at least as I see it: The owner has some definite admin-rights so he needs to be admin too, but he shouldn’t be bothered with all the other technical stuff.)

I think that is a point we have to discuss later.

But a few thoughts now though:
I suggest to introduce customizable templates into the r&p-system.
The best place would be the “role”-area.
Here you could define which template should be used for a user when he is working in his workflow-role.
So you also would be able to create a “training mode”-template with templates that include explanations for every input-field.
When training is not necessary any longer, simply change to a normal template.

(This exactly is, what I need for a txp-site in work!)

Last edited by saccade (2006-01-15 14:12:52)

-P- · 2006-01-15 14:18:05

@ saccade

Okay, may be because english is not my mother language why I don´t understand correctly what you mean but isn´t the goal same?

While making the most suitable, fluent and customizable user management->user groups it ends up with the different user interface with different users. :)

saccade · 2006-01-15 14:33:06

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

Last edited by saccade (2006-01-15 14:34:27)

-P- · 2006-01-15 14:42:49

saccade, I get back to this within an hour, have to go now to vote for the next president in Finland. :D

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

well done!

too many people do not use their rights and permissions to vote.
(it really hurts me if democracy suffers lack of commitment).

wet · 2006-01-15 15:19:19

> saccade wrote:

So I think we should add a basic permission

“visible”

besides create/edit/change and so on.

A part of my day job I am responsible for the system administration of an enterprise scale content management system. This system has seven distinct levels of permissions:

none: you cannot even see whether this object (i. e. article, image, file, link, page template, stylesheet, form, …) exists.
browse: you can see the existence of an object but you cannot read its content.
read: you can see an object and its content.
relate: you can use an object as part of another object (include an image into an article, include a form into a template, …)
version: you can modify an object but you cannot overwrite it in place (no textpattern equivalent)
write: you can modify an obejct and overwrite its content.
delete: you can delete an existing object.

Maybe this will fuel your thoughts. I am not suggesting to use that schema in any way, but I think it might serve as an example taken from a product which is capable of handling really complex permission requirements.

Last edited by wet (2006-01-15 17:53:09)

Textpattern CMS

Textpattern CMS support forum

#97 2006-01-15 11:48:01

Re: Rights and Permissions Workgroup

#98 2006-01-15 12:18:49

Re: Rights and Permissions Workgroup

#99 2006-01-15 12:41:17

Re: Rights and Permissions Workgroup

#100 2006-01-15 13:25:16

Re: Rights and Permissions Workgroup

#101 2006-01-15 13:34:53

Re: Rights and Permissions Workgroup

#102 2006-01-15 13:47:58

Re: Rights and Permissions Workgroup

#103 2006-01-15 14:04:09

Re: Rights and Permissions Workgroup

#104 2006-01-15 14:18:05

Re: Rights and Permissions Workgroup

#105 2006-01-15 14:33:06

Re: Rights and Permissions Workgroup

#106 2006-01-15 14:42:49

Re: Rights and Permissions Workgroup

#107 2006-01-15 14:49:21

Re: Rights and Permissions Workgroup

#108 2006-01-15 15:19:19

Re: Rights and Permissions Workgroup

Board footer