Page 21 of 22

Re: FE User and User/Group Rights-Management Development

Posted: Thu 13. Nov 2008, 18:00
by rushclub
try the following scenario:

you have an business that sells to retailer.
you produce different products in different price-ranges.
now you classify your retailer in two categories: normal and high end.
the high end retailer sells the top and normal products of your company.
the normal dealer only the normal products.

now you make a retailer-zone on your website with technical information and marketing tipps.
the high-end dealer becomes different information then the normal dealer.
so you add the group "high-end dealer" to see those sites and the normal dealer to see these sites not.
you have to do this one time and not for each retailer again and again ...

that was the frontend-thing.

in backend imagine the following.
there are the groups: editor, designer, manager
the editor only creates and write articles. he dont need access to templates.
the designer need access to templates and css and create structure and articles, upload images, ...
if there a 10 editors they all have the same permissions in backend, when they where added to the group editors.

thats, why we need group-support.

regards
rush

Re: FE User and User/Group Rights-Management Development

Posted: Thu 13. Nov 2008, 18:10
by nebenaube
Hmm... wouldn't the structure I proposed in the previous post support that scenario as well? Hint... it's post 300 on page 20 of this thread.

Re: FE User and User/Group Rights-Management Development

Posted: Thu 13. Nov 2008, 18:20
by nebenaube
rushclub wrote:try the following scenario:
[SNIP]

in backend imagine the following.
there are the groups: editor, designer, manager
the editor only creates and write articles. he dont need access to templates.
the designer need access to templates and css and create structure and articles, upload images, ...
if there a 10 editors they all have the same permissions in backend, when they where added to the group editors.

thats, why we need group-support.

regards
rush
What rights does the Manager need? Or better yet, what should Managers be prevent from accessing?
What should the designer be prevented from doing? Why is the admin role not sufficient for either user?

Isn't a backend user by default a editor already?

Re: FE User and User/Group Rights-Management Development

Posted: Thu 13. Nov 2008, 18:31
by nebenaube
What rights does the Manager need? Or better yet, what should Managers be prevent from accessing?
What should the designer be prevented from doing? Why is the admin role not sufficient for either user?
The reason I ask this is because it only creates more headaches as the system grows and is configured in a specialized way. And still what I proposed would seem to support it with similar checks in the backend as well. The difficulty is deciding which backend actions/functions and modules belong to which backend group. Since the list of modules will never be complete I supposed what we would need is a list of backend actions/functions that would be limited to specific groups and a mechanism to assign groups to a module (or would the group membership of the module fall on the module designer)

on edit: hmm each backend function/action is really a non-logging on but active user record that belongs to one or more of the backend groups...

on another edit: hmm... for the backend users phpwcms.usr_admin could be changed from a bool to a enum value and then one wouldn't need to check the user's group membership via a function call with every action in the backend since usr_admin is stored in a session variable. we wouldn't need a editors group, a managers group and a designer's group that way either... just hard code the check against the session variable.

Re: FE User and User/Group Rights-Management Development

Posted: Thu 13. Nov 2008, 18:57
by nebenaube
Someone asked if I was working for Oliver...

Well, no I am not. I am not unlike yourself although I have not contributed to the fund. Such actions are difficult because I am self-employed (under-employed)and must feed the family and keep the heat on.

It seems like many are waiting for this feature set. It also seems that many have suggested I contribute something to the community and to Oliver for using phpwcms in my own work.

I am invested in and enamored with using phpwcms for several of my clients. I have been playing with it since 1.2.5 Dev and it is to my benefit to ensure that this community continues to exist so that support exists for phpwcms. After all, this community provides a resource I can go to when something is broken or I can't get it to work the way my customer wants it to.

I'm hungry and I am tired of waiting and I'm tired of telling those I support that I can't do that yet; maybe tomorrow. that is as they say in my country 'bullshit' and no way for me to run a business.

I say that we work this out, get the feature set working, collaborate to test it and Oliver can then take it and put the final touchs on it. I don't give a damn who gets credit for it and as far as the fundible is concerned Oliver is the one who has to support the system over the long haul. So I don't care, I'm sure he's already eaten those funds anyway.

Re: FE User and User/Group Rights-Management Development

Posted: Thu 13. Nov 2008, 19:15
by update
Thanks for clarification!

Re: FE User and User/Group Rights-Management Development

Posted: Thu 13. Nov 2008, 19:30
by nebenaube
I've seen everyone but Oliver reading this forum this morning. Does anyone understand the structure of phpwcms well enough to comment on the plausibility of the proposed design?

Re: FE User and User/Group Rights-Management Development

Posted: Fri 14. Nov 2008, 00:36
by Jensensen
Let's get granular on some more aspects:

Who's allowed to:
A) add/activate MODs
B) add/edit site structure levels {articles} WHERE and/or WHERE NOT
C) add/edit page (layout) templates, custom content blocks...
(without FTP access the templates of content parts cannot get changed! same for front end render scripts and so for RT tags)
D) add/edit CSS
E) add/edit JS libraries, extensions...
F) add/edit NEWS 'Mod'
...

Right now: everybody, yes we can,
except only FE-User can't!

We'll know --> tomorrow...

Re: FE User and User/Group Rights-Management Development

Posted: Fri 14. Nov 2008, 01:45
by nebenaube
Jensensen wrote: Right now: everybody, yes we can,
Is this true... I have backend users initialized and they can't get to the Admin portion of the backend where most of that happens. I'll test more to confirm.

By the way phpwcms did help one district elect 'That One'... No contribution to that effort was too small or too indirect.

edited... Jensensen... some of that has to be managed at the server level with ownership and permissions. Even 'Panes' can be configured for that purpose. edited again: sorry for the pun.

Re: FE User and User/Group Rights-Management Development

Posted: Fri 14. Nov 2008, 09:08
by rushclub
nebenaube wrote:
What rights does the Manager need? Or better yet, what should Managers be prevent from accessing?
What should the designer be prevented from doing? Why is the admin role not sufficient for either user?
The reason I ask this is because it only creates more headaches as the system grows and is configured in a specialized way. And still what I proposed would seem to support it with similar checks in the backend as well. The difficulty is deciding which backend actions/functions and modules belong to which backend group. Since the list of modules will never be complete I supposed what we would need is a list of backend actions/functions that would be limited to specific groups and a mechanism to assign groups to a module (or would the group membership of the module fall on the module designer)

on edit: hmm each backend function/action is really a non-logging on but active user record that belongs to one or more of the backend groups...

on another edit: hmm... for the backend users phpwcms.usr_admin could be changed from a bool to a enum value and then one wouldn't need to check the user's group membership via a function call with every action in the backend since usr_admin is stored in a session variable. we wouldn't need a editors group, a managers group and a designer's group that way either... just hard code the check against the session variable.
look at be-support in other cms (typolight, typo3, ...). they have a detailed rights-management. the admin can define for every group any action. the groups designer, editor and manager where for example.

rush

Re: FE User and User/Group Rights-Management Development

Posted: Fri 14. Nov 2008, 09:11
by rushclub
Jensensen wrote:We'll know --> tomorrow...
of course, there will be some day in the future, where today is tomorrow.

rush

Re: FE User and User/Group Rights-Management Development

Posted: Fri 14. Nov 2008, 09:13
by juergen
:lol:

Re: FE User and User/Group Rights-Management Development

Posted: Fri 14. Nov 2008, 12:45
by update
Thinking aloud:
How come that yesterday's tomorrow is tomorrow's yesterday?
Is this really true?
Isn't it rather the truth that today is yesterday's tomorrow and tomorrow's yesterday?
Thus said we easily can see that yesterday is in fact tomorrow and both together are making our today.

We are caught in some kind of time machine steered by some invisible captain hovering through the times of neverwhere

Re: FE User and User/Group Rights-Management Development

Posted: Fri 14. Nov 2008, 12:49
by nebenaube
groups vs. roles... I can see groups in the front. Seems like backend users are roles. Silly semantics... Discuss


but remember KISS

Re: FE User and User/Group Rights-Management Development

Posted: Fri 14. Nov 2008, 13:40
by rushclub
update wrote:Thinking aloud:
How come that yesterday's tomorrow is tomorrow's yesterday?
Is this really true?
Isn't it rather the truth that today is yesterday's tomorrow and tomorrow's yesterday?
Thus said we easily can see that yesterday is in fact tomorrow and both together are making our today.

We are caught in some kind of time machine steered by some invisible captain hovering through the times of neverwhere
:lol:

you made my day. or was it tomorrow? ...

rush