Permissions manager grid and Template grouping

[Joss]

Just finishing a site for someone and deciding to create an editor role.

Depending on how many templates you have it can be really long winded to work through them to sort out the permissions!

This is a problem common to many systems.

On Joomla (which has one of the most cross-eyed systems I have come across) one chap has made it a bit easier by creating a manager that basically creates an editable chart/grid. 

A ProcessWire equivalent would basically allow you to list all templates for each user group in a grid - templates down the left, permissions across the top.

Then, you would be able to change permissions on the grid itself, live updating via ajax as you go.

Apart from speeding up the process, it gives a nice holistic view.

Another thought is to be able to group templates arbitrarily together, so that permissions changed for one in the group can affect all in the group. This has probably only specific uses for things like complex news sites.

Though, that grouping ability might have other uses. Yesterday, I added a new field which I wanted to add to most but not all templates. If I had a group called "article templates" for instance, then there is the possibility to add a field to all templates within that group.

To a certain extent, we already have the grouping functionality with tags - though it maybe that we need to use multiple tags because you may want to group templates together in different ways for different reasons.

Anyway, two thoughts in one that are aimed at very complex sites.

Joss

[MatthewSchenker]

Hey Joss,

I am thinking along these lines as well. Maybe we can work together on a neat system. I'll have some time to work on things like this soon...

For the moment, I just could not resist your comment about Joomla's rights system. I am sharing some images so everyone here can sympathize with what you and I had to deal with before coming to ProcessWire...

WARNING: THESE IMAGES ARE NOT FOR ANYONE WITH NERVOUS OR ANXIOUS TENDENCIES.

http://docs.joomla.org/File:Screenshot_acl_tutorial_20110111-07.png

http://docs.joomla.org/File:Screenshot_acl_tutorial_20110111-16.png

http://docs.joomla.org/File:Acl_example_diagram1_20091018.png

Thanks,

Matthew

[Joss]

To be a little fair to Joomla, the theory behind the system was okay but the management is just dreadful.

The ACL manager (premium 3rd party plugin) made some sense of it - though not totally.

Mind you, if you want to see completely bonkers, try the Liferay version.

When you draw it out, it makes sense, which is a good start. Everything has a owner, administrator, manager and user. Each of those have the possibility to edit, create, delete, etc. You have additionally groups and roles which allows sensible combinations. 

Next you have scopes - so you can have a group who has global scopes - that means they can edit, for instance, on one type of asset where ever it is on the system. Others might just have local scope, so you can only edit on one type of asset within your organisation or site. (Liferay can have multiple organisations and/or sites all with every type of asset like blogs, forums, wikis and so on)

Okay, so a little head spinning, but actually quite logical when you start working with it.

But then they made it possible for fine grained permissions on everything, and I mean EVERYTHING.

If you did the same on PW, it would mean that you could create a full permissions structure of owner, administrator, manager, user on every single field, every page, every template, every module (including all core modules), every word, it feels like sometimes.

If you use Liferay the way it starts it is fine - but if you start messing around with the fine grained permissions it becomes a nightmare!

Just thinking about it, that is one thing that was rather nice in Liferay - the idea of an "Owner" of an asset. It was a bit different from just being the author as it gave implicit control rights over the asset and anything that was a child to that asset.

In the liferay world, it meant that if you were an owner of a Blog, you had automatic ownership over any posts made within that blog, even if you did not make the post (anything can have more than one owner). Ownership meant you also had control over other users, groups or roles, who had rights over that asset.

In a normal website that is not needed, but if anyone is thinking about making a community site with PW, looking at the two ideas of Scope (local and global) and ownership is strongly advised.

[Pete]

Great minds think alike: http://processwire.com/talk/topic/2374-batch-allow-template-edit-access-to-new-role/#entry22423

[ryan]

You guys probably already know this, but those permissions assigned at the template level are inherited through the page tree unless you choose "Yes" for defines access in your template settings. Meaning, you only have to define access on templates where you want to change something about the access.

For example, lets say you've got a /members/ page that requires a login. You would define access for the template used by the /members/ page. But you wouldn't need to define it on any other templates used on pages below that. Meaning the templates used by /members/cool-stuff/ and /members/great/content/ do not need to define access, because they inherit it from /members/. This is a simple example, but the same rule applies for page editing permissions and such. 

[MatthewSchenker]

Greeting All,

Thanks Ryan!

See, that's what I like so much about ProcessWire: in one paragraph of straightforward language, you explain something that takes a series of confusing graphics in other systems.

Thanks,

Matthew

PS: It seems, perhaps, that ProcessWire challenges the notion that a picture is worth a thousand words!

[Pete]

I wasn't aware of that ryan, thanks!

[apeisa]

Current method with template based access control works very well in most of the sites and apps. 

But if you have lots of "horizontal" needs, then it gets complicated. What I mean with horizontal needs is things like: we need to have 15 news sections with different editors and readers. Each of those news sections are in different parts of the site tree. Template based access control just falls short here, since we don't want to duplicate those 15 news templates (and create new duplicate each time we need new news section).

News section is just an example, it could be also things like "workgroup section", "blog" or "private room" etc.

CustomPageRoles module definitely helps here and I have been able to do all the things with it. But our sites usually are dynamic in a way that client themselves need to create those sections. Since CustomPageRoles build upon the template access control, it still needs quite a clicking on template access tabs etc. I have also made some tweaks to that module that I need to share.

I like the idea of "global" and "local" - you could add "local" access control that will be inherited from some part of the site. See this:

Home (home)

-- services (basic-page)

-- news (news)

-- -- news item 1 (news-item)

-- -- news item 2 (news-item)

-- -- office intranet (intranet) *

-- -- -- our rules (basic-page)

-- -- -- office news (news)

-- -- -- -- office news item 1 (news-item)

-- -- -- -- office news item 2 (news-item)

I would have defined my global template access like this:

home

guest role - view access

office-member role - edit access

* Then I would have added local template access to page "office intranet" and have defined there these rules:

intranet

guest role - no view access

office-member role - view access

office-admin - edit access

news

guest role - no view access

office-member role - view access

office-news-editor - edit access

office-admin - edit access

 

Not sure how complicated this would get, but I still find the current way a little bit cumbersome for our sites (with lots of "horizontal needs"). 

[Joss]

Yes, this sort of delegation can be useful for even basic sites where you have a couple of departments that need to update their own couple of pages

One of the things about having an Owner role is that the owner can then delegate responsibilities within their own hierarchy. 

That means they have full control over their space