Rights and Permissions Workgroup

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.

alexandra · 2006-02-21 10:08:24

I have been too busy Me too :)
but i like to pick up our working group again.
My suggestion is to combine our very abstract approach with some practical examples so other readers can follow easier.

Here is f. e. the MODx testinstall. Login with username: admin and passw: demo and invesstigate their rights system.

saccade · 2006-02-21 11:13:44

Thank you for the link. A quick look was interesting but unfortunately I’m not yet in dual processor mode :-)
I have to look closer after work.

I already thought about sorting and combining our thoughts so far into a well-ordered paper and for example first collect all “scenarios” (and a few more) to get an impression what is needed. And by numbering them we could faster cite how our suggestions affect those practical demands.
What do you think about that?

alexandra · 2006-02-21 11:30:29

I already thought about sorting and combining our thoughts so far into a well-ordered paper

i agree, seems necessary to order our thoughts a bit before we go on. it is probably easier for us to talk in our language. we could email a bit and post our paper than in english. How about that?

saccade · 2006-02-21 11:45:10

Ausgezeichnet!

squaredeye · 2006-02-21 13:26:57

Gesundheit!
(sorry I couldn’t help myself)
That word above looked a lot like the sound of a sneeze to me :)

I look forward to seeing what you all come up with. Michael, glad to hear you are slightly above water again. Alexandra, hope you are staying afloat as well.

I would still like to suggest we take a good look at what expression engine has done. And if it would help I can set up a demo site for us to play with for practical examples?

However, TXP is very much its own beast, and I like it that way, so its just fodder.

See you both soon,

M

alexandra · 2006-02-21 14:31:57

hi Matthew :) excellent (= Ausgezeichnet) seeing you again/back here. I wish you health (Gesundheit) too ;). I would be interested in an EE demosite. It is very helpful to see how other CMS manage.

Textpattern CMS

Textpattern CMS support forum

#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

#145 2006-02-21 10:08:24

Re: Rights and Permissions Workgroup

#146 2006-02-21 11:13:44

Re: Rights and Permissions Workgroup

#147 2006-02-21 11:30:29

Re: Rights and Permissions Workgroup

#148 2006-02-21 11:45:10

Re: Rights and Permissions Workgroup

#149 2006-02-21 13:26:57

Re: Rights and Permissions Workgroup

#150 2006-02-21 14:31:57

Re: Rights and Permissions Workgroup

Board footer