Rights and Permissions Workgroup

-P- · 2006-01-15 23:13:08

Yes, it only works in the perfect world and were not there :)

But there should be still more options that you can grant/deny from a user. There are also very different kinds of non-technical users, some do actually listen and learn. Then there are the ones that just don´t. To them, options off.
We are after the same thing, thinking of ways to make more customizable admin/user interface.
When you have to make everything waterproof, you disable those options from user. When you have a user that is interested in managing more his/her site and you know she/he can, you would be able give them the “basic configuration rights” without them having to deal and care about all the tabs and stuff that are for you (admin)only (presentation, main config etc.)

Last edited by -P- (2006-01-15 23:18:45)

saccade · 2006-01-15 23:14:53

right!

Jeremie · 2006-01-16 02:03:43

saccade wrote:
-P-s suggestion (see post #101) directly affects the question “what are really solely admin rights?”

I would answer, “whatever the admin wants”.

Here we have an owner, who doesn’t want to have all admin rights. He leaves the technical stuff to the admin.
On the other side he has rights that we regard so far as typical admin-rights.
He wants to have the rights
to define the site name
define the site tagline
define primary comments-settings

I can easily imagine scenarios where that won’t be true. A site tagline might change quite often to “follow the mood of the day”, or the news cycle, or whatever. It can be done other ways (creating a static persistant article with only one line, and a minimalist form to display it) but the same is true for any site tagline.

For me, the very basic rights of an admin are:

Edit the admin datas (login, name, email, password, rights, etc.), and he would be the only one to do that
Edit any rights for any users/usergroups/roles/whatever

The rest is based upon the admin wishes. And besides “edit the admin datas”, any right could be given to anyone.

Last edited by Jeremie (2006-01-16 02:06:01)

saccade · 2006-01-16 09:22:45

Jeremie,

thank you, that seems to be the most convincing and coherent definition of basic admin rights.

What we were on, was to figure out a basic set that (1) an admin (by his tasks) should never give to anyone else, and (2) he will normally be the only one to have hands on in every imaginable job workflow.
The benefit of such a set would be as alexandra stated:
We get rid of putting that set into a configuration system for rights.

But maybe that is a weak access(approach?). (I assume so looking at the discussion so far, there could always be some workflow, where you want to have someone with single rights of admin-taste but do not want him to have adminpower).

The real rights are what you listed.

This of course unfortunately means that we don’t get rid of that bunch of permissions in the configuration :(

BUT, hold on, something comes to my mind (maybe complicated, but I think to be thought of once): If I as an admin want to give “permission configuration” rights to another one (mention for example “Laura”),

it is no problem as long as they only have access to roles or predefined permission groups (for I defined them) (so Laura in the example)
but if it includes to set up permission groups (the upper left block in the scheme graphic – a little bit more than “Laura” – in practice mention to have an “Organization Cybernetician” who customizes the job workflow configuration for the site), they have access down to the technical base. That could be dangerous. So I would need to have an additional “control of access” on
“control of access (=setup)” – or what we implied in our question for a set of solely-admin-rights (those would be fixed in the red “admin”-group/role in the graphic.
But I don’t want to structure to the infinite.
So my conclusion: Let all permissions (except those you listed in the first point = access to the admin data) go into the right to set up permission groups. Then normally let this setup-permissions-right be restricted to the admin, and only very very carefully given to skilled persons whom you would grant admin-role as well without worry (or whom you can watch at work).</ul>

“Admin wishes” of course are determined by tasks and customers wishes (job workflow).

Last edited by saccade (2006-01-16 13:52:02)

Jeremie · 2006-01-16 10:45:34

Well, this is a good place to start talking granularity. Do we want/need every item to have a right, or not ?

Example. The actual Admin/prefs tab, is it one right to access it, or is it a “collection” of right (one right for the site name, one right for the site slogan, one right for the number of articles in an XML feed, and so on).

So, a high resolution granularity, or a more global (and simpler) system, along the lines of “one right to rule them all” ? Of course, in the rule’em all resolution, we could suggest some change to the gang of four (for example moving the “site slogan” out of the admin-only-admin/prefs tab to a “customize” tab, linked to a specific right given to the right people —just an example).

There are pros and cons to both system. More granularity means covering every base, every need. With a really good UI, it stay simple to use for admins, coadmin, whatever. But it may be overkill for TXP, and we may have to ship Zem with full trucks of advil and coffee.

Last edited by Jeremie (2006-01-16 10:47:19)

saccade · 2006-01-16 12:00:42

I myself am for high granularity in conceptioning the system.
I think the system itself (the frame) has to be prepared for high granularity, then it is a real good one.
In implementation then it still can start with first steps in global width. (And have finer triggers later).
But also maybe it is less work to implement a thorough-thought fine granularity once and get rid of modifications later (as I stated somwhere above).
But here the programmers should give us a hint, when we present the final suggestion.

I never would suggest an overkill. You are right to remind me of that.
But first I think we should get the logic best (sorry, it is very very hard for me not to orientate towards the best – and txp deserves it!), and then think about, what is achievable with how much effort. Then maybe we will downgrade to make the second best suggestion.

If the system is good I would ship Zem what I can :-)

Last edited by saccade (2006-01-16 12:02:11)

alexandra · 2006-01-16 12:07:02

> Jeremie wrote:

> Do we want/need every item to have a right, or not ?

I really like to avoid that!! No overkill to TXP.

On the long run we have to restrict ourselves in the discussion. And we have to figure out which restrictions should be applied to the p&r system. The finer granularity gets, the harder it is to handle.

In a real world working TXP r&p system there are two scenarios i can imaging:

the admin applies each single right to a user/usergroup [not applicable, granularity is too fine]
admin applies single sets of permissions

Sets of permissions can be:

admin permissions set
article permissions set
design permissions set
file permissions set
user group permissions set
category permission set
link permissions set
etc……

F. e. the admin permissions set includes permissions as:

Disallow user images
How many articles on RSS
Send last-modified header
Image directory
etc……

Now we can place a checkbox next to each set: ALL/NONE/PARTLY.

NO: the usergroup has no access to these permissions at all and would as well not see the tab belonging to these permissions.
PARTLY: some of the permissions can be assigned to a user/usergroup.

sigh..sigh..sigh the issue is really very complex… but we have to start with something real

saccade · 2006-01-16 13:47:50

Alexandra,

1. the admin applies each single right to a user/usergroup [not applicable, granularity is too fine]
2. admin applies single sets of permissions

what you describe here is an aspect of applicaton (or use).

You are right 1. “single rights” > “user” is not applicable, that indeed would be too complicated.

For the application we already achieved a good solution:

We have a system of steps and normally you follow them in this order:

1. The first task of an admin (or comissioned to another user) is to assign a user to a (preset!) role.
(The role itself is a preset (!) permission related to content as well. We could provide basic roles.)
This is easy, it is the same as we have now in txp.

2. One step deeper is to define which combination of a preset (!) permission set named “permission group” and which kind of content defines the role.
Here an admin could create customized roles (for example to restrict to a single section).
This also is not too difficult, provided a good set of permission groups (and to provide a good set of basic “permission groups” I think is our task).

3. The deepest step is setting up “permission groups”. Only here it is about single rights/permissions.
Only if he wants to have a very special “permission group”>“role”, an admin has to deal with this.
And if the system is thought very well, it could be easy following our tracks in the provided groups.
If someone is content with existing roles or permission groups he needn’t use this step.
But we have to think about it anyway. We even do already, for at the moment we are thinking about for example the preset ‘permission group’ “admin only”.
It doesn’t make a difference if we do so and fix it in the programming, or if we provide a setup that lets admins do the same.

Your examples of permissions sets already are designed in the view of “content” as well as to an imagined “user”
and there I think there are better solutions who will make the system easier.

If we separate “permission” and “object” consequently (for combining them again later) I think it will be less complex. For we can concentrate on “what” will someone do (view, create, edit …”,
and then “where” will he do it (in a basic setting, in a template, in the text of an article).

Now I have to go out for two hours, and wanted to post this before. I’m hope it is not too cryptic. :-)

Last edited by saccade (2006-01-16 13:48:08)

Jeremie · 2006-01-16 14:41:15

When you say “complicated”, I read “to hard to easily fit into an UI”. When I said it, I meant “too hard, long and complex to implement for the developers”.

So if we decide on high granularity (ultra precise) in the database/code, but then to hide that to the users/admins on their UI, that would still be a complicated job for the dev.

I don’t say we should, or shouldn’t do it. I just say this is also a matter to keep in mind when we make a decision on what we recommend to the dev team.

alexandra · 2006-01-16 15:19:08

saccade wrote: The first task of an admin is to assign a user to a (preset!) role.

By ‘preset’ you mean the role is kind of hardcoded into TXP?

Last edited by alexandra (2006-01-16 15:20:35)

saccade · 2006-01-16 17:49:44

@alexandra

No, definitely not hardcoded, but preset by the different steps within the scheme.
Preset in the way that an admin will not be bothered with the more complicated steps if he is content with what is provided – as we are now.
And he can decide how deep he wants (or needs) to go into configuration.
Most of the work to give him good ways is done by us in this workgroup.
EDIT: So we should provide some real good basic roles and permission groups along to what we discuss (that has been selfevident for me so far). ENDOFEDIT

@Jeremie
You are completely right.
We have to keep in mind and discuss what is a reasonable job for the devs.
But in my view it may be a hard and complicated way of thinking and discussion and finding structures, and it is a complex material we cope with, but at the end the result could be a simple formula/scheme or an approach that is simple in itself, but capable of the complex. Maybe it even helps to make it easier for the devs.
Often staying with accustomed or usual/given structures is in the end more work, even if you have to change a small bit.
So to ask what is a resonable job I think is a step after finding a convincing logical system.

And I know this would include that we try something and have to discard it again over and over – but in my view that the job of a workgroup :)
In short words: I’m afraid of too fast solutions.

Last edited by saccade (2006-01-16 17:57:50)

saccade · 2006-01-16 18:06:18

@alexandra
oh sorry, maybe we have different view of “hardcoded”:
I mean “presets” should be included in an install-package, ready prepared roles/groups that can of course be customized too or taken as a base for new ones.

I don’t think an admin should have to work from a plain ground within the scheme.
I think he should find a system that works fine as the present system in txp (maybe a little bit refined and surely more versatile if it comes to customize it).

EDIT: And maybe “preset” in a way, that for example an “Organization Cybernetician” who for example knows in detail which roles are needed for a regional newspaper with its journalists, editors, freelancers, ad customers and so on will build the suitable structure within the scheme for him once. And he only has to use this “preset” in daily work (and maybe sometimes refine it a little bit).

Last edited by saccade (2006-01-16 18:11:29)

Textpattern CMS

Textpattern CMS support forum

#121 2006-01-15 23:13:08

Re: Rights and Permissions Workgroup

#122 2006-01-15 23:14:53

Re: Rights and Permissions Workgroup

#123 2006-01-16 02:03:43

Re: Rights and Permissions Workgroup

#124 2006-01-16 09:22:45

Re: Rights and Permissions Workgroup

#125 2006-01-16 10:45:34

Re: Rights and Permissions Workgroup

#126 2006-01-16 12:00:42

Re: Rights and Permissions Workgroup

#127 2006-01-16 12:07:02

Re: Rights and Permissions Workgroup

#128 2006-01-16 13:47:50

Re: Rights and Permissions Workgroup

#129 2006-01-16 14:41:15

Re: Rights and Permissions Workgroup

#130 2006-01-16 15:19:08

Re: Rights and Permissions Workgroup

#131 2006-01-16 17:49:44

Re: Rights and Permissions Workgroup

#132 2006-01-16 18:06:18

Re: Rights and Permissions Workgroup

Board footer