Rights and Permissions Workgroup

Jeremie · 2006-01-06 10:45:27

Saccade, well I’m not sure. I need some advil I think :)

I’m still unsure on what you call role. For me, a role is just an internal semantic. A role would be “painting publisher” for example. Defined by the site’s admin as a new usergroup under the name “Painting Publisher”, with several permissions (like being able to change articles status) only to the “paintings” section.

saccade · 2006-01-06 11:50:13

Jeremie,

ok, I understand – and have to refine the system once more. (But what means “advil”?)

With role I mean a distinct set of rights and duties a user can have,
partly that what now is called “privileges” in textpattern: e.g. “publisher”, “managing editor”, “staff writer” – and we want more to be created.
At the moment these privileges cannot be defined by restriction to parts or families of content but only apply to all elements (sections/categories) of content.
The feature we want to have is the ability to define privileges down to parts of content (defined by sections/categories and other criteria down to single articles).

And in this view a role
is the combination of rights or privileges
defined by permissions (organized in permission groups)
and content (organized in clusters or types of content, e.g. section, or in content groups which I suggest for managing rights for specific contents).

So in a system of components that consist of

permissions / permissions groups
content families / content groups
user / user groups

the role would be the combination of the first two of metagroups to be able to fulfill a task:
permissions applied to content .
[By the way, it’s in the name: “Painting Publisher”: “Painting” is a part of content – and “Publisher” is a form of permission.]
This role would be assigned to users

for example
Painting Publisher for the “paintings” section,
but there could also be
Painting Publisher Ancient and Painting Publisher Modern if you have different user(s) working on different categories within your “paintings”-section and need to separate them.

So role shouldn’t be only an internal semantic but could be a definable “set” of permissions applied to content.
This *role*-set you can choose to be applied to the user (or user group).

I hope now I described more clearly what I mean.

EDIT
So a “permission group” alone for me is no role, because it is important to which content it is applied.

It could be a general role if it is applied to all the content (so it would be something like “general managing editor”) But normally there will be something like

“managing editor paintings” and
“managing editor furniture” and
“managing editor tableware” …

combining permissions and parts of content.

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

squaredeye · 2006-01-06 12:32:58

Saccade,
Well done, this is starting to make more sense to me.
The little bit of a matrix that you set up was helpful in getting me on board mentally (speaking of: advil is a painkiller for a headache :)

I think Alexandra’s suggestion of a setup of working examples might be a good idea.

Let me know how I can help.

Saccade I am really impressed with your ability to think through the logic of this, hopefully I can help from a user perspective :)

Matthew

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)

Textpattern CMS

Textpattern CMS support forum

#13 2006-01-06 10:45:27

Re: Rights and Permissions Workgroup

#14 2006-01-06 11:50:13

Re: Rights and Permissions Workgroup

#15 2006-01-06 12:32:58

Re: Rights and Permissions Workgroup

#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

Board footer