Rights and Permissions Workgroup

saccade · 2006-01-06 12:36:25

thinking about the discussion so far, I feel the need to add some thoughts:

In what I suggested until now
I try to hold every element or component strictly separate:

a user group is strictly only a group or list of users – it needs to have an own name, for example “the germans” or “our trainees” or “volunteers”
but it has nothing to do with rights so far (of course you could give it a name that reflects rights as well, but that could be confusing).

a permission group is strictly only a group or set of permissions – also with an own name that here of course reflects the function, for example “publisher”, “managing editor”, “staff writer”
but it has nothing to do with content so far.

the “content family” or content group – also with an own name
lists all elements of content, that should be assigned to the same rights, for example the section “diary” or the category “reviews” or the one specific article “annual 2006”,
but it has nothing to do so far with the type of rights.

Only in the combination of this separate elements the thing we want results:

permissions applied to content create a role
this role can then be applied to any user or a user group,

for example:
“staff writers” for the category “reviews” create the role “review staff writer”
and this role is assigned to the user-group “volunteers”

and you can set up
“publisher” for “reviews” and assign to the user “websiteowner”

this way you can easily change the groups later for example from “volunteers” to “trainees” if you give the work to another user-group.

Last edited by saccade (2006-01-06 12:47:42)

saccade · 2006-01-06 12:42:38

@alexandra and matthew
i was writing my last post while you posted yours, so I did read them after my posting.
Thank you. I’m happy if I can help something.

Jeremie · 2006-01-06 12:48:22

Ok doki (by the way, in my first post when i was talking about “privileges”, I meant them as in rights&permissions. Aka “Being able to publish article” was one privilege. But ok with your new taxonomy).

It’s starting to take some serious shape here.

One thing though. tWe have to be careful with the “content-family category X”. Some TXP users use category cross-sections/website (a “Car” category would apply to all the websites and sections). This is what the gang of four meant in the first place. But some others (and I would bet, larger) TXP users define Categories within sections (a “Car” category would only be used within the “Review” section, not the “blog” section for example).

So, without knowing where TXP will go in the future (nested section and categories as tags, section-sensitive categories, sections and categories and tags added, or whatever) I can foresee some user’s request about “giving user X permissions over the Car category of the Review section, but not the Car category of the News section” or something along those lines.

We need to be absolutely clear about what a content-family is and can be, and how they might or might not interact with each other.

I’m not saying would should allow that kind of granularity; because it may be granularity no more but over-complicated. I’m saying we should keep this (and others possible future developement of TXP… I don’t know, things like real use of nested categories&sections, tags, keywords, etc.) in mind and decide if it should be handled, and how.

Last edited by Jeremie (2006-01-06 12:50:36)

saccade · 2006-01-06 13:25:45

@Jeremie
“keep this in mind” – very true.

As far as I understand at the moment sections and categories are completely different things (sections bound to design and categories bound to content) and thus not nested at all.
Those users who define categories to be used only within sections do that by their own restriction – not by any restriction the system provides. Am I right?

The “giving user X permissions over the Car category of the Review section, but not the Car category of the News section” could in my opinion be solved in the content family/group by giving control over section “Review” but forbidding control over “News” section. So user X cannot create/edit any content in “News”. And if he is forbidden to assign the section “News” he cannot create content for “News”.
So a basic control in this direction could be possible with this rights system.
(Of course if the News-Section is not section-sensitive and all Car-category content will be shown in “News”, then “Car-Review” will also be. But that is out of our topic for it has nothing to do with rights but how textpattern organizes content.)

But anyway: The component system is a very global structure and it can be filled with whatever structure textpattern provides. If textpattern will introduce nested sections and so on, these should be introduced in the “content family/group”-component as well.
At the moment I think we could work with what textpattern provides regarding sections/categories/keywords.
If it later develops, the content-component has to develop too of course.

Last edited by saccade (2006-01-06 13:27:00)

saccade · 2006-01-06 14:38:18

@jeremie

maybe I didn’t quite meet your point making clear what is meant with “content family”, let me have a try:

with “content family” I mean a type of content characterized by something, for example a section or a category or maybe a keyword or custom field.
In every case I have in mind all previous, existing and future pieces of content that belong to this cluster. It is a cluster without a fixed number of content elements.
Maybe it should better be called content type.

This is distinct from my view of content group which

can hold combinations and multiple elements of “content type” (e.g. content group A holds cat x of sect y and cat z of section b and the whole section c)
and can as well be restricted to single articles, picked from the article list. (e.g. content group B holds the articles “Einstein” and “Relativitätstheorie” and “e=mc2”)

At the moment I think this is independent from the exact structure content has in textpattern and so it can be adapted to every concept of nesting.

Jeremie · 2006-01-06 15:30:58

Indeed, “content-type” may be more understandable. Still, we are going to need to be more specific in those areas if we want our work to be of any use to Alex. I’m not pressing to move forward, not being wrong about the grounds is essential.

alexandra · 2006-01-06 20:28:01

Here is the grafic; my fist attempt visualizing the coherences
Link fow those who have a small monitor.

permission concept

squaredeye · 2006-01-07 03:26:32

Alexandra.
Wow. That’s schnazzy! I am such a visual person, and this helps tremendously.
I have a bunch of questions about how selecting these pieces in different menus would affect the next menu down the line, etc, but I think that is a question for later, for now:

A couple of edits I think. Their are two sections “american poems” in the content section is one of them suppost to be “american fiction”?

I am also confused by what you mean by “stuff”. Are you saying that they could be a staff writer or a designer or any of the above? (in other words, is “stuff” all inclusive?)

Lastly, you may consider removing the arrows, as they suggest direction instead of connection? Which I think is more what we want? Yes, no?

Is Ian allowed to get to ALL files? Is that what is meant by “section” files?

Just for clarification.

alexandra · 2006-01-07 09:42:41

Hi Matthew, thanks for your feedback :)
I worked on the grafic last night and was a bit tired already. You are right, there are some faults in it, like ‘americanPoems’ should of course be ‘americanFiction’. As well: Ian is responsible for ‘files’ and not ‘Section files’. Sorry.

I noticed saccade has been online when i published the grafic. I wonder, if he comes up with an improved version :). If not, we can go on working on this grafic. I already wanted to ask you helping me with the english expressions. F. e. ‘Stuff’ ment to me a ‘writers group’. May be you know better expressions?

Well, let´s see, what saccade´s and others response is. If needed and appreciated, i will correct the grafic along the suggestions.

Last edited by alexandra (2006-01-07 09:44:46)

saccade · 2006-01-07 09:51:50

Alexandra.
Thank you very much for the good visualization. That helps a lot.
Yesterday in the evening I have been online for only two minutes (or at least only two minutes of looking on screen) between coming home and leaving again. I was very pleased and impressed by the visualization but couldn’t look in depth nor say/write anything.

How did you create it? (with which application?)

As I understand your post, it is allowed to work in this grafic.
I would like to visualize the concept of “groups” in it.

saccade · 2006-01-07 10:05:42

some suggestions or questions that come to my mind quickly:

1) For improving the understanding and better showing the connections to present functions of textpattern:
Shouldn’t we include (some of) the roles (=privileges) that are available in the present version of textpattern?
(Maybe with some tag or color marking what is presently possible)

2) I would draw a frame/border (or give them a background color) around “permission” and “content”, for these two together create a role (I think that was, what you wanted to show with the double arrows).
The combination of the two is the “permission machine” that creates a role.

For the concept of groups I have to think still a while.

alexandra · 2006-01-07 10:15:35

@saccade my suggestion: lets split it up into two grafics:

reflecting the concept (abstract)
reflecting the combination of the concept an what is already availabe in present version of TXP

agreed? Or is this confusing?

Last edited by alexandra (2006-01-07 10:15:54)

saccade · 2006-01-07 10:24:37

@alexandra
agreed!

saccade · 2006-01-07 16:10:36

still thinking and working – please be patient

While working on the grafic another question came up, a real brain-twister (I need advil too now):

1) We’re in the “permission” area.
2) Someone should have the right to “edit articles”
3) He should be able to edit “own” articles.

Now the first question:
A) Isn’t “own” really/in fact a part of the “content”-component? Meaning all or only own content?
If so, it should be better to have this choice – restricting to “own” or “all” – in the content-area. (I think so)

But thinking further the second question arises:
1) At the moment in textpattern permissions we have two choices: “all” or “own”. That could be very rough.
2) If the permission in question relates to some characteristic of content, then in our present scheme we could choose “all” and restrict to the relating content-characteristic. That would be an advance.
3) But some role could afford, that a permission is not related to content but something in between “all” or “own”, thus related to users.
For example a role could be needed, where a teaching editor should have rights to edit articles of distinct other users e.g. volunteers or trainees (that is a user group).
This also I would locate as a possibility of selection in the content-component.

(Of course you could do this task by my idea of content group with the selection of all single articles created by volunteers, but then you have to find them manually first and you are always behind the action. So it would be much better if you could select content by its author in the same way as you can select it by its section)

Finally what I suggest is an additional new way of defining content by authorship.

It could look as following:

content autorship

all
own
subset or usergroup

Can you follow me? I hope I managed to outline the task.

Of course I’m thinking whether it is sensible to make all these distinctions and separations, but I think it opens a true modular and scalable architecture for our task. And it seems to me better for carrying out the programming. Or deciding which of the parts we need now and which we can spare for later.

EDIT: ok, reading the following post – thank you P – another point comes to my mind: If authorship is located in the “content”-component, it applies to all permissions. But it could be possible (in fact it is) that in “publisher” you need the permission “publish article” for all users but “edit article” only for own or maybe a usergroup xy.
Conclusion:
Authorship should be an option applied to every element of permission (where applicable),
but my new suggestion is to include usergroup as an option besides “all” and “own”.

Last edited by saccade (2006-01-07 16:57:24)

-P- · 2006-01-07 16:19:46

Based on groups there are now, here´s how I´d see the system.

Scenario for example a webmagazine that has main section and sections by writer.

Publisher (site admin) as is. To Managing editor I´d remove default options to have a access to site design and preferences and change them to be per user group selectable options. -> can edit site preferences yes/no.

I would add new option, Assign to shared. This shared would be additional setting in sections and articles.
So Publisher and Managing editor could assign sections and articles to shared. This would be kinda built in workflow. By default, articles posted to shared are editable by everyone if assigned with needed priviledges.

There would be three basic user groups with predefined options much like now (Publisher, Managing editor and Writer). But I would add an option “Create a new user group based on …” with drop down selection. On the new group one could individually choose option yes or no to following:

Admin rights:
can create, edit or delete any article, link or comment
can change article status
can edit site preferences
can edit sections and categories
can add and remove authors
can grant and restrict privileges
can change article status from Pending to Live
can edit sections and categories
can edit any article, link or comment

Style:
has access to all site design areas
can edit Page HTML, Forms, and CSS

Publishing:
can create and edit own articles
can publish and delete own articles
can create and edit shared articles
can publish and delete shared articles
can move articles to shared
can upload images
can edit links
can edit comments
can edit categories

edit: seems like saccade was posting same time from similar stuff.

Last edited by -P- (2006-01-07 16:27:12)

Textpattern CMS

Textpattern CMS support forum

#16 2006-01-06 12:36:25

Re: Rights and Permissions Workgroup

#17 2006-01-06 12:42:38

Re: Rights and Permissions Workgroup

#18 2006-01-06 12:48:22

Re: Rights and Permissions Workgroup

#19 2006-01-06 13:25:45

Re: Rights and Permissions Workgroup

#20 2006-01-06 14:38:18

Re: Rights and Permissions Workgroup

#21 2006-01-06 15:30:58

Re: Rights and Permissions Workgroup

#22 2006-01-06 20:28:01

Re: Rights and Permissions Workgroup

#23 2006-01-07 03:26:32

Re: Rights and Permissions Workgroup

#24 2006-01-07 09:42:41

Re: Rights and Permissions Workgroup

#25 2006-01-07 09:51:50

Re: Rights and Permissions Workgroup

#26 2006-01-07 10:05:42

Re: Rights and Permissions Workgroup

#27 2006-01-07 10:15:35

Re: Rights and Permissions Workgroup

#28 2006-01-07 10:24:37

Re: Rights and Permissions Workgroup

#29 2006-01-07 16:10:36

Re: Rights and Permissions Workgroup

#30 2006-01-07 16:19:46

Re: Rights and Permissions Workgroup

Board footer