Rights and Permissions Workgroup

squaredeye · 2006-01-05 00:05:09

Rights and Permissions Workgroup

It has become clear that textpattern users are interested in seeing some growth in the area of “rights and permissions” both for end users and for developers. Therefore a number of folks here in the TXP forum are forming a workgroup with the hope of producing a working document (in some form) that outlines a conceptual map of how a permissions scheme might work for textpattern.

raison d’être:
Zem has made it clear in this post and others that it is important for the core development team to have ideas/participation from the community for issues such as permissions for the admin to create such a scheme with PHP.

By no means:
Does this mean that whatever this workgroup comes up with will be implemented. This is an experiment.

THINGS TO POST HERE:
Post suggestions IF they are well thought out, and clearly explained. (within reason :)
Post questions that pertain to your own need for permissions rights management as you build sites. (so that we can understand the spectrum of needs that txp users face)
Post your experiences with other rights/permissions systems that you have found either beneficial or cumbersome.

THINGS TO NOT POST HERE:
Your problems with TXP not having a great rights/permissions system.
Your need for a good hemorrhoids cream

Thanks,

Matthew (for Alexandra , Jeremie , Saccade , P , and Neutrino

Last edited by ma_smith (2006-01-05 00:06:06)

neutrino · 2006-01-05 01:08:57

Hey Matt,

Thanks for including me. I hope I can be some help. Mostly I need to learn permissions issues. BTW, I love your signature line. I can almost hear Rufus Wainwright.

Jeremie · 2006-01-05 06:37:47

First some ground things to bear in mind. There are three “metagroups” that can (stress can) interact with each other on the matter of rights&permissions.

The usergroup where the user belong (some groups already exist in core TXP, aka Publisher, Writer, Designer, and so on).
The user himself
Where the rights&permissions are applied, aka the section.

Several other software (in particular advanced bulletin boards, like vBulletin) use these three “metagroups” (or components) and process the rights&permissions from each of them to finally “know” if a specific user can or can’t do something.

Maybe we need this level of complexity. Maybe we don’t. But in any cases, that’s will surely be one of the importants topics: how to handle exceptions, and/or opposite directives (“the section A say usergroup A can delete articles belonging to itself” but “the usergroup A doesn’t have the delete article privilege”, and so forth).

A second thing, is descendant privileges. If components controling the privileges (like usergroups), and/or if components where the privileges are applied (like sections) can be nested, have child, descendant and so on; do we apply the parents rights to its childrens ?

Practical example: Zem has made some move toward nested sections. If a usergroup has the “delete articles” privilege applied to parent section A, can they also delete articles in subections AA, AB, AC, etc. ?

A third item, is multiple group belonging. Most certainly, we will need this. An user can be a “section A publisher”, and a “section B writer”, and a “section C admin” for example. So not only the tryptic usergroupr-user-where can interact with each others, but usergroups can interact with each others too. Not sure if I’m crystal here though…

Last edited by Jeremie (2006-01-05 06:41:04)

alexandra · 2006-01-05 09:48:59

[Great introduction, Matt]

As Matthew pointed out in another thread:
It seems like it will be important for the workgroup to have a cohesive language set in order to understand what means what.

We are talking about:

Permissions (or privileges) control access to content. Granularity refers to how fine permissions can be divided. Permissions can be per user, or based on their Role. They can be given to a Group of users, then users assigned to the group. It can be per page or even per Content Element. It can depend on the time. For example, a user may edit a page scheduled for a future date, but not change it once it is published.

Content Management Roles: are for groups of users who share the work on a certain organizational task. Generally, a workflow notification email is sent to a Role mailbox, which can be forwarded to all the Users who are sharing that task at the moment. Typical roles are writers, copy editors, editors, illustrators, graphic artists, rights clearance managers, (multilingual) localizers, and publishers. Different workers can have assigned roles. Notification may be sent to the roles rather than the individuals.

The idea of a role notification mailbox is very good (but beyond textpatterns architecture at the moment). Here I think we have to distinguish:

role-notification based on the role as itself (e.g. mailing to all illustrators) and
role-notification based on the piece of content (e.g. mailing to those illustrators who have access to the article in question).

Workflow: A system for routing documents (or pages) between users responsible for working on them. This is often used to implement a review and sign-off process for new or updated content. Workflow is the management of who exactly is working on a Content Element or Content Template, what exactly they are doing, and when. The workflow reporting system sends messages to others working on a page, with details of actions taken.

In a system of components Michael aka saccade sees the following (thank you Jeremie for leading me to content):

permission = privilege = right
is a single element of access to content as “create”, “delete”, “assign to section xyz”, “assign to category xyz”.
These permissions can be combined to a
permission group = content management role equal to user group
is a set of permissions combined and given a name (e.g. editor, writer, …) and assigned to 0/1/x/all user(s)
user
is a single person which identifies itself to the system and has assigned 1 or more role(s).
user group
a) are all the users assigned individually to a permission group or content management role
b) is a list of usernames (there can be multiple lists) that makes it easier to assign permission groups to multiple users or assign users to concrete content (see below).
content
is where the permissions/roles are applied.
Here we have to distinguish between two topics:

content group or content family or content cluster
a set of (all) elements of content with a connecting characteristic, e.g. section or category or author. In Textpattern at the moment we have only this topic .
specific content
is one specific article or a set of single (=named) articles, e.g. one week in a diary or one person in a set of biographies.

Last edited by alexandra (2006-01-06 11:30:16)

NXArmada · 2006-01-05 14:27:11

Here is a good idea of what I think the Rights and Permissions can be like.

Everything in blue is what I have added.

Staff Writer

can create, edit, publish and delete own articles, images, files
can upload images
can upload files
can only see own articles, files, images in list

Freelancer

can create and edit own articles
can change article status from Draft to Pending
can only see own articles in list

These are just small changes that I suggest

Also restricting user to certain section, image categories, and file categories.

Also an option on the Section page were a dialog box well open when a certain link is clicked and allowing you to enter a username and password to lock the section and whent the section is view in publish mode it asks for a password, rather than putting a password code into the section html page.

saccade · 2006-01-05 16:09:48

Based on the above system of components

there are two architectures of assigning rights:

If you want to assign rights for a cluster of content (that is all elements of content with the same characteristic),
then you can set up a suitable permission group (or use a predefined) and assign it to those users who should be legitimated.
This process of assigning could be done

per individual user (those users who have the same permission group are a user group)
by first structuring the users (set them in groups), and then assigning the permission group to the user group.
The second way would have the benefit, that you can change the permission group for a user group with one change and you don’t have to change the permission for every user separately.</ul>

If you want to assign single users or user groups to a (set of) specific content
then there must be a way to assign permission groups to an article (or another form of content). This could be done only during or after creating content.

Here the other way round seems to me be too complicated:
If you would want to assign specific content to one user or a user group, then you would have to use a list of all content elements – which can grow very long! – and then have to mark all suitable contents.

Last edited by saccade (2006-01-05 18:02:19)

squaredeye · 2006-01-05 17:23:35

Alexandra, Saccade, and Jeremie,
Great start. This makes me feel like I am smart :) It took a few reads through, but I think I am following.
#I agree with Alexandra that combining the posts into one in this particular type of thread is appropriate when considering readability, even though shorter posts are nice, fewer more concise posts are clearer. (imho)
#Saccade, would you be willing to ammend the bit above that says “one by one user” to “per individual user” ? (slightly more clear), but I must say that I am ashamed with the strength of everyone’s english, when I can only just barely recognize the basics of your german. (memories from a 7th grade class).

Matthew

saccade · 2006-01-05 17:46:27

@matthew
I ammended the bit above.
Fortunately for my english I do profit from wonderful forums like textpattern support forum :-)

saccade · 2006-01-05 19:31:23

reconsidering the system of components I see the following structure:

A.
we have

1. permissions = general rights to to manage specific functions
and
2. packages/groups of permissions = (arbitrary, I mean by decision) combinations of permissions for a special purpose

then we have

1. users = individual identifiable contributors
and
2. packages of users = (arbitrary, I mean by decision) lists of users who share the same rights for a purpose

B.
we can use the same structure to distinguish content:

we have
1. content clusters = generally all elements of content that belong to a section, category, keyword or something like that. Rights assigned to clusters are completely independent from the actual number of elements of content
and
2. specific content = (arbitrary, I mean by decision assigned) individual content. That could be a group of one or several (for example:) articles.

Here I have to clarify/correct some wording from before:
In this view this 2. “specific content” could be best understand, interpreted as a “content group” like “permission group” and “user group”. This means group = an arranged set that is put together arbitrary by decision to serve to some purpose.

So for better understanding the 1. “content cluster” shouldn’t be called “content group” but “cluster” or “family”.

In the final system if you want to assign specific content you could set up (1) a content group, assign it to (2) a user group with (3) a permission group. Each part could be easily modified later.

EDIT: This concept of content group solves the problem of assigning content I remarked in 2. of this post .

Last edited by saccade (2006-01-06 08:53:29)

saccade · 2006-01-06 08:49:28

another refinement:

when we have “content family” and “content group” as the location where to assign content-based rights,
then in “permissions” it should not be “assign to section xyz” or “assign to category xyz” but the bare “assign to section” or “assign to category”.
The “xyz”-Set of sections, categories (and so on) a user is allowed to manage should be defined in the _content_-components (either by family or by group).

For more clearness:
In my first suggestions I had the impression, that restrictions to special sections/categories have their place in the permissions area as a form of specific permission (for example as a subset).
But if there is content as a customizable component, then it is more logical to chose assignable sections/categories etc. within content settings.
To the permissions-area the bare right to assign sections/categories could be left. In this way you could grant rights to edit content to a writer, but leave the right to assign it to a section or category to an editor.

Last edited by saccade (2006-01-06 09:08:15)

saccade · 2006-01-06 09:15:10

@alexandra

if my last two revisions/reworkings of the system of components are agreeable, they could be integrated in this post . And then the two posts could be deleted.

Some explanations on how the system can be used in the workflow I would combine in a new post.

saccade · 2006-01-06 09:33:36

@Jeremie

On the issue of “multiple group belonging”:

This should definitely be possible.

But from the view of a user it is very important to know which role (= rights or duties) you have at the moment – to avoid to get mixed up with what you (are allowed or committed to) do now.

If you have multiple roles there are two basically ways of access to your role:

1. You first choose which of your roles you want to take – and then you get the matching content.

or

2. You first choose which content you want to work on – then you must be told, which role(s) you have or can choose for this particular content.
(For it can happen, that on a specific piece of content you are both writer and editor).
(And the current role should constantly be shown very obviously on the page.)

Both have their pros and cons.

Did I understand right, what you meant with “interaction”?

Textpattern CMS

Textpattern CMS support forum

#1 2006-01-05 00:05:09

Rights and Permissions Workgroup

#2 2006-01-05 01:08:57

Re: Rights and Permissions Workgroup

#3 2006-01-05 06:37:47

Re: Rights and Permissions Workgroup

#4 2006-01-05 09:48:59

Re: Rights and Permissions Workgroup

#5 2006-01-05 14:27:11

Re: Rights and Permissions Workgroup

#6 2006-01-05 16:09:48

Re: Rights and Permissions Workgroup

#7 2006-01-05 17:23:35

Re: Rights and Permissions Workgroup

#8 2006-01-05 17:46:27

Re: Rights and Permissions Workgroup

#9 2006-01-05 19:31:23

Re: Rights and Permissions Workgroup

#10 2006-01-06 08:49:28

Re: Rights and Permissions Workgroup

#11 2006-01-06 09:15:10

Re: Rights and Permissions Workgroup

#12 2006-01-06 09:33:36

Re: Rights and Permissions Workgroup

Board footer