Rights and Permissions Workgroup

saccade · 2006-01-18 12:00:48

Here I want to give a preview on my work and a suggestion so far.
It is still playing with the logic, not directly suggesting anything to do, just to see in depth and in a playful manner (is this ghastly english?) what could be done.

Here below two pictures and the full picture with an explanation in the pdf.
The pdf has english and german text in levels (Acrobat 6/7) (examples coming in levels too, you can show or hide levels in the levels tab in Acrobat – in the browser-plugin too)
Still missing :( some examples inside the playing field, how present rights are structured (by whom and where), – along the present rights-configuration-model [see alexandras post #77 and how some of our suggestions will be. (pdf updated: basic try to show relations for “txp402 managing editor” but not yet verified)
As I have to work now, I wanted to give a small look what to come and perhaps getting some hints or corrections or feedback in the process, until I can continue here.
(Perhaps it is not fully comprehensible without the visual examples, then please wait until tonight, but maybe someone can imagine yet though.

and as tags for who and where defines relations between those parts:

Last edited by saccade (2008-04-16 16:58:27)

saccade · 2006-01-18 13:29:17

In addition to the suggestion in my last post, I want to point out that it results from thinking over the current permission-configuration-model in txp (post #77).

This model (a sort of matrix) is extensible to our groups in the (first) scheme.
But there is a mix of areas in the keywords.
For example: “article.edit.own” lists an object, a permission and a qualifier.
I think if it is possible to separate the different things along to the (second) scheme in my last post,
and have for example keywords staying within an area like this:
article.text.qualifier1 = …
and relate them to something in the other area.

Just thoughts/ideas …

saccade · 2006-01-20 12:15:24

I’ve done some review of scheme 1 and scheme 2 and here you can read about differences and working/application models (permissions_differences.pdf).

Now I have a question regarding terms in english:
is there a difference between “setup” and “config”, e.g. “setup rights” is different from “config rights”?

And two remarks:
1) In the scheme 2 I use “object” primarily as “thing to do something with it”, maybe there are a lot of implications if it comes to code or programming – that I do not know.
2) In scheme 2 “role” is missing, because it only shows “things”. “role” is organization (a thing of second order) and should be drawn into the playing field as a suggestion.

And two points of discussion:
1) does it make sense to have a permission “assign” (e.g. for section/category-selection in articles) – or is it only a special technique of “edit”?
2) Regarding Tabs I implied, that tabs are shown, as long as you have any right (permission+content) that belongs to the tab in question. If you don’t have any, the tab should be hidden (or left out).
Maybe that is technically too difficult (it needs another round of determination in the code).
So: Should “tab” be added to the object-list? Tabs could be switched off by the (negative) permission “no access” [or shown by “read only access” (the tab itself is ‘read only’, the options have other permissions)].

Last edited by saccade (2008-04-16 17:23:40)

alexandra · 2006-01-20 12:33:52

Hi saccade, great pdf…
i am a bit short of time this week but i will read the pdf tonight an hopefully have some decent questions :) .. just to let you know

saccade · 2006-01-20 12:52:36

Hi alexandra,
seems to be a loads of work week for everyone – (besides other work I had a fierce battle with css/divs/and that internetexplorerbeast yesterday that too costed me hours of time)
:)

squaredeye · 2006-01-20 13:00:42

Michael,
#Setup often refers to some getting “configured” from the beginning. Where as config would be a detailed or specific way of speaking about “editing” and can apply to both start/beginning and current/present changes.
#As I understand it, it does make sense to have a permission “assign” as that can relate to whether or not a person can assign articles to their own section only or others. Do you see it as a permission that has options? ex: assign section (yes/no) assign cat (yes/no) etc.
#I agree with your assessment of tabs (hidden/shown), if that were too technically difficult to achieve, I wonder if stomething like a ~~strikeout~~ method could be used to illustrate what is there, but cannot be accessed by a given user?

Also, just to bring Everyone’s attention to this on the Dev Weblog. :)

M

alexandra · 2006-01-20 13:33:23

….what a sweet post over at the dev weblog :) haven´t noticed it yet…
Thanks for the link Matthew.

saccade · 2006-01-20 13:36:40

Matthew,

Do you see it as a permission that has options? ex: assign section (yes/no) assign cat (yes/no) etc.

Yes. The ‘options’ are done by assigning an object*(-group, f.e. “section” or “category” in the article-object) and its *qualifier (if instance-subset required) to the permission “assign”. (Sorry for the doubled meaning of assign, I didn’t find another word for the italic one)

EDIT Examples: (“no” by not assigning any object to “assign”, “fixed” by assigning one instance through a qualifier, “subset” by assigning more instances through a qualifier, “all” by assigning f.e. “section” or “category” without a qualifier)

EDIT 2 Here another question comes into account:

There is a top-level object “section” (I had this in mind for create/edit/delete the section-settings.
There is the “section”-part of the top-level-object “article”. In my view the permission “assign” refers to this occurrence of “section”.

Is it logical to have these two different objects “section”?

one as the section-setup/config
the other as the section-classification

Maybe we should give them two different names to reflect that difference.

Or maybe this difference is not needed and the permission determines which application of “section” is meant? (e.g. “create/edit” automatically refer to the section-setup, assign to the “section”-classification in the active object?) My own answer: No, because in this way you could define only one section-assignment-subset per role. But it could be necessary, that you are allowed to give an article all sections, but an image only one or two of these sections. So you need to have a section-classification-object in every suitable piece of other objects (article, image, file).

Conclusion: We should name the “section”-object within f.e. an “article”-object section-classification. Or do you have a better term?

Michael

Last edited by saccade (2006-01-20 16:14:18)

saccade · 2006-01-20 20:09:38

for playing around a playing field template (basic_thoughts_template.pdf).

Modification: renamed “section”/“categ” in article, added “tab”.

For I didn’t do much with files/images/links yet, it would help me, if you could complete the objects within these elements (like in article). Then I could complete the template. Thank you!

More and more I think, this will fit basically in what is r&p-config-structure in present txp (the “article.edit.own=1,2,5”…) . I will demonstrate this later.

Last edited by saccade (2008-04-16 17:24:52)

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

As I stated in my last posts, there are tangential points between current txp-r&p-setup and our considerations (tangential_point.pdf with explanation).

In the pdf I try to show, what I think of.

If the structure of scheme 2 is considerable as a pattern for assigning rights,
it has the benefit of fitting well in existing structures of txp.
Its implementation could mount on existing paths (as I think with my rudimentary understanding of course it requires modifications in handling the objects and determining their privileges within the code, but these in my opinion could be implemented step by step or object by object).
And we are still free to decide which objects (or permission-object-couples) may be taken into a configuration-menu for users and which will be defined within the code by some setup-lines as in present txp.

Last edited by saccade (2008-04-16 17:26:29)

saccade · 2006-01-21 16:11:05

Example according to post #142:

The object “setting” includes as instances all settings in post #114 and #115 (as far as they don’t belong to other objects).
They can be qualified individually by their “name”, e.g. “site name” or “date format”.
Access to a single setting (e.g. “site name”) could be granted by
‘edit.setting.[name=“site name”]’ => … </ol>

You have an admin (role 1) and an owner (role 2):
1 => gTxt(‘admin’),
2 => gTxt(‘owner’)

Right for an admin (I know he has all rights, but only for demonstrating how the syntax works) to access all settings, would be
‘edit.setting.all’ => ‘1’

If you have an owner who likes to play with his site name, let him do so
‘edit.setting.[name=“site name”]’ => ’1,2’
(it could be discussed, if the admin-role 1 has to be set here or if it is implied)

Or an example with separate qualifier-definition:
See – P-‘s example in post #101

Lets have this owners right be defined in the “qualifier01”.

The owner (role 2) gets the rights group with:
‘edit.setting.qualifier01’ => ’1,2’

The definition of qualifier01 could look like:
qualifier01 => ‘[name = “site name”, “site tagline”, “accept comments”, “moderate comments”, “on by default”, “disabled after”, “commentsrequsername”, “commentsreqemail”, “changepassword”, “changeemail”]’

(listing the selection of instances, the owner should have access to)
With an eye on implementation: the code must determine (according to the qualifier01-list) which setting-elements within the tab are visible and make them editable.

Last edited by saccade (2006-01-21 16:26:45)

saccade · 2006-02-21 10:01:17

I have been too busy doing my profession, paying lots of bills, and setting up a textpattern installation learning more and more about peoples’/customers wishes regarding privileges.
Now in a few days I want to get back – hopefully – to improving rights and permissions suggestions.

Textpattern CMS

Textpattern CMS support forum

#133 2006-01-18 12:00:48

Re: Rights and Permissions Workgroup

#134 2006-01-18 13:29:17

Re: Rights and Permissions Workgroup

#135 2006-01-20 12:15:24

Re: Rights and Permissions Workgroup

#136 2006-01-20 12:33:52

Re: Rights and Permissions Workgroup

#137 2006-01-20 12:52:36

Re: Rights and Permissions Workgroup

#138 2006-01-20 13:00:42

Re: Rights and Permissions Workgroup

#139 2006-01-20 13:33:23

Re: Rights and Permissions Workgroup

#140 2006-01-20 13:36:40

Re: Rights and Permissions Workgroup

#141 2006-01-20 20:09:38

Re: Rights and Permissions Workgroup

#142 2006-01-21 15:37:26

Re: Rights and Permissions Workgroup

#143 2006-01-21 16:11:05

Re: Rights and Permissions Workgroup

#144 2006-02-21 10:01:17

Re: Rights and Permissions Workgroup

Board footer