Template selection for new pages per role

[Soma]

I want to be able to say on a per template basis, what role can use the template for new pages.

Further considerations regarding templates setups

I got pretty big setup with many different types of templates. I have each of them set up to allow only certain children and/or parents etc. This is great to reduce the selection one has when creating new pages, and allows for some great control. Sometimes it is may even needed to only allow a certain template in a certain section. But this may goes too far, but depending on how you use PW to build sites, it can be a neccessary feature. THis can get endless I thought and I can't wrap my head around this particular problem what is best way to go.

This is very nice but can get a little cumbersome to manage and maintain, as there's no overview (especially for new admin that are new to a project). Mainly it's hard to keep track of what is where how it inherits. It is easy if there's only a handful of templates, but I got around 40 templates and it's still growing. But I guess that's the nature of having so much templates. And I fear that the level of complexity can get worse as a project grows. What would be the best practices, or would there be a way to solve it all different and more convinent?

I would like to discuss this a little more and like to hear what others think.

Also what are your plans on this subject Ryan?

[ryan]

I'm not sure that I understand your setup well enough to be able to provide a good answer on how you should change it. So I'll just mention some general guidelines. For sites where you need to maintain multiple points of access, t's best to narrow in on your primary points of access change in your site, and use a unique template to serve as the access parent. Then let everything below it inherit that access, and control what can go where with family settings in the templates.

To get template selection of new pages per role, you would give the role edit access to that template (or let it inherit it from another). Then in family, select the allowed parent templates. You've now defined what roles can create new pages using that template.

To keep it simple, inheritance is all or nothing in 2.1. You don't inherit some things from one parent and others from another, like in PW 2.0. You inherit everything from the access parent's template, which helps to reduce confusion (relative to 2.0). 40 templates is a lot even for a large site (more than I've ever used) so I do wonder if that is necessary, though I'm sure there are cases where it may be, but it's something to look at.

[Soma]

Thanks Ryan for the answer.

Well the setup of the templates so far work fine regarding access and family. I use it inheritely and am using the family settings sparely and only for allowed childs. I played around with it quite a lot. But what I'm requesting is not this, my idea is to be able to say "this" template is only allowed to be selected (when creating a new page) by a certain role. So that templates only I should be able to select aren't visible to the editor when creating new pages. For example a special form-template. So while I could make it not to be in the allowed family of one or another template, I would need to add it temporarely, just so I am able to create a page with it. Hope you understand what I mean.

I got that many because it demands that many (I was already cautious on not having too much), and they're not all for pages only. Some are for folders, different types of page elements (as childpages, guess this will get better once we have repeatable, flexible elements on page), some ar for different types of downloads (also as pages) and download folders to be able to select them and have all downloads listed from that folder. There no way to do it different or with less templates. While It was my first big, more complicated and multilangauge project with PW, I think some could be simplified. But I already got a main sub-page template which is used for the majority of page thoughout the site and has many fields and tabs for different elements, to keep it flexible and not create a template for each type of page.

Edit: I understand your suggestion to make this kinda work on a per role/template basis, but it's not practicable in my setup. May if you want I can give you acces to the site, so you could take a look?

[ryan]

Soma, just wanted to let you know I haven't forgotten this, but wanted to reply when I had time to put some more thought into it (early next week). If you want to send over the access that'd be great too.

[ryan]

But what I'm requesting is not this, my idea is to be able to say "this" template is only allowed to be selected (when creating a new page) by a certain role.

This was actually in early versions of 2.1 as the page-add permission (and it's probably still there just commented out). I took it out because I was worried about providing too many options and resulting confusion with so much crossover between that and the family settings. I like having lots of choices, but access control is one area where I think it's better to just have one way of achieving something. Though I do think we could add page-add permission back as an option, but something we'd probably want to do with an optional module.

So while I could make it not to be in the allowed family of one or another template, I would need to add it temporarely, just so I am able to create a page with it. Hope you understand what I mean.

I understand what you mean. The action you described is also the way family options are supposed to be used. Set things up where you need them, an then lock it down the way you want it. It's meant to be something to direct the flow after you've set the structure and determined who can edit, not at the same time.

There no way to do it different or with less templates.

If everything is working and you are happy then I wouldn't suggest changing it. There's nothing inherently good or bad about having lots of templates–it's generally adds more flexibility, but with the tradeoff of being more to manage. But if you want me to take a look and suggest ways you can do it with fewer templates, I'll be glad to. Though you may be right that you have exactly as many templates as you need too– I'm not familiar with the site or scope of it so can't speak to it. 

[Soma]

Ah, yeah I think that's what I'm looking for. page-add permission. I was a bit confused to why it isn't there.

So I went over it again where my main problem was and where I thought about having this option. It would be for pages I want to give the editor rights to edit but not add new pages with it. But when I give edit permission, it shows up in the template select.

I agree that we should keep this access things as straight and easy as possible, but such an option would greatly help and not add too much complexity. Though I was already a little confused not really because it's complicated but because I haven't slept much for a long time . I really  would like to have this out of the bo, maybe not installed but there in the package.

Yeah I'll be glad to give you access though PM. So only if you like, you don't have to. As I mentioned most templates are for having flexibility, and most are purely there for structuring. I know there would be different ways to archive the same, and have the logik in templates using let's say ID's or paths instead based of template name. I just think the ability to structure the templates with something like "tags,categories" could help to reduce the template list to what you're looking for. I think this can come in handy too when dealing with large sets. I know there's filters, but they're not the same.

[ryan]

You've convinced me, I changed my mind on this. I'm going to add page-create and page-delete columns to that template access control list and they will just be there. We can decide if we should move any to an advanced mode/option based on community feedback, but I don't want to exclude some access control scenarios for simplicity.

[ryan]

Soma, I plugged this into the dev branch yesterday so you should now have page-create permission back in the system, controlled on a per-template basis. Would you mind testing this when you have a moment? I wasn't sure exactly how to duplicate your access control scenario.

I left off the page-delete for now because deleting pages is a bit more of a complex question: "delete any pages of this type, or just pages the user created", and we'll answer that question with a separate permission or add a separate auto-assigned owner role.

[Soma]

Awesome, thanks Ryan for considering and reactivating this. I just pulled the latest and I see there's the option and it seems to work so far.

Only problem I got now is that for the language tree branch I have a template for the branch "/de-de/" and I've set it via page references in the user template to be a working space, so all pages in this branch can be edited by the editor role. I have a module for this, where it looks for if pages are in the branch the user has defined. I've set it up so they can't edit the "/de-de/" page but add "new" pages. For some reason after the update there's no "new" action anymore, only on subpages, although I have set the template to allow add pages. Even If I add "edit" permission there's still no "new" action.

Here again the code (already posted on multiple thread) I use for the user workspace

<?php
public function init() {
    if($this->user->hasRole("editor")) $this->addHookAfter("Page::editable", $this, 'checkpermission'); 
	if($this->user->hasRole("editor")) $this->addHookAfter("Page::addable", $this, 'checkpermission');

	//if($this->user->hasRole("editor")) $this->addHookAfter("Page::listable", $this, 'checkpermission');

	//if($this->user->hasRole("client")) $this->addHookAfter("Page::viewable", $this, 'checkpermission'); 
}

public function checkpermission(HookEvent $event) {

    // if it was already determined they don't have access, then abort
    if(!$event->return) return;

    $page = $event->object; 
    $parents = $page->parents;

	// root node access granted
	//if($page->url == "/") return true;

	// run check for parent pages and allow recursive inherit access 
	foreach($parents as $p){
		if($this->user->editable_pages->has($p)) return true;
	}

	// then run check on selected single pages
	if(!$this->user->editable_pages->has($page)) $event->return = false;

}

EDIT:

I just deinstalled the module and it doesn't change anything. Strange, the template has add children permission set on the editor role, though they can't add children pages to it...

[ryan]

Soma, does the 'new' show up where it should if you comment out the Page::addable hook? I'm just wondering if we need to look in the module you posted or in PW newly added code. Also, this could potentially be the problem:

if($this->user->editable_pages->has($p)) return true;

You should do this instead:

if($this->user->editable_pages->has($p)) {
    $event->return = true; 
    return;
}

or if you want to keep it on one line:

if($this->user->editable_pages->has($p)) return ($event->return = true); 

[Soma]

Edited my post, I deinstalled the module and it still not working on that root branch page like "/de-de/".

SO it doesn't matter on the module. Though the additional "create" pages on template role setting seems to work, just not on that one to add new children. Don't know what's going on. I just can say...  worked well before the update...

PS:

I don't understand you suggestion with the return, as it's working well as it is.

[Soma]

If you want to take a look at it, it's on the dev install I've sent you thru PM... you could see it yourself. There's also a editor/editor1 login you could test.

[ryan]

Can you check that the editor role has page-create permission on at least one template? And by that, I mean at least one template that is allowed in the place where you've given them the page-add permission? Since page-create was just added in, non-superuser roles aren't going to have that permission assigned anywhere at first.

Another thing to consider is family settings, which can affect permission. For instance, if they have page-create permission for template A and page-add permission on template B, then they should be able to create pages of type A as children of type B. However, [in the 'family' tab] if template A only allows template C as a parent, or template B only allows children of type D, then that restriction will prevent them from getting the permission.

I'm not sure that I can tell much from using the editor login, because all the relevant settings are accessible to superuser only. Though if you find it's still not working how it should, it would be good for me to duplicate it with a simple test case here so that I can more easily fix it.

I don't understand you suggestion with the return, as it's working well as it is.

I'm not sure if it matters to the function of that module, but just wanted to mention that "return true;" in an event function technically does nothing. The return value is not used for anything. In order to return something from the hooked function, you'd need to populate $event->return = true;  

---

Edit: found that you did send me a superuser account in PM. Sorry, missed that before. Trying that...

[ryan]

I just logged in and looked at your installation. The problem here is that you aren't actually using the page-create permission anywhere. I went through all the templates allowed as children on the 'language_tree' template, and none of them have 'Create Pages' checked for the editor role.

As a result, even though editor has page-add permission on language_tree, they didn't have page-create permission on any of the templates allowed there. So editor couldn't add any pages below de-de (language_tree). I went in and checked the page-create permission for one of the allowed templates 'ressort-page'. Once I did that, the 'new' link started showing up under de-de. So unless I'm misunderstanding what you are saying, I think it's working correctly, but you just need to check a few boxes.

I restored the ressort-page template back to how it was and removed the page-create permission there. But try adding it to one or more of those allowed templates to see what I mean.

[Soma]

Thanks a lot Ryan, after your previous post it ringed a bell

I forgot that on first level there's only ressort-page and some others allowed, but I did test with sub-page template access settings which isn't allowed there so that's why. Stupid me really.. I should have found out myself. You're right.

Sorry for bothering you for something simple.. maybe I should sleep a little more.

[ryan]

No problem, I'm actually glad to see it in action on that site because it's a great test case of the new permission. I like your 'Desktop' option of you've added in the admin too. And as always, your theme is looking great. Let me know when you are ready to make a 2.2 version of it and I can tell you what to add.