Editor Can't See Unpublished Pages in Admin Lister

[prestoav]

Hi all,

PW 3.0.200

It seems a user with editor permissions can't list unpublished pages (even if they themselves created them) in the lister within the admin > pages > find function. Superusers can see them but editors can't. Having searched the forums I can only see fixes for page select fields using hooks but nothing that would allow a permission for this to be granted.

This is quite an issue for a couple of sites I have. For example, a manufacturer who needs to administer a list of their resellers (all have separate pages) that needs to be turned on / off regularly. There are well over 1k reseller pages so the find function is a god-send for this type of thing.

Does anyone have a way around this or a way to set this as a permission that can be granted?

Is this feature available in ProLister perhaps?

If this can't be easily changed maybe this option should be greyed out in the admin page lister for editor type users?

All help very gratefully received!

[Robin S]

By default Lister should automatically show unpublished pages that the user is allowed to edit as long as the Lister filters are limiting by template.

So if your user is allowed to edit template "basic-page", and the Lister filters include "template=basic-page" then the user will be able to see unpublished pages (without needing to have a specific "include" item in the Lister filters). But if you don't have a "template=" item in the filters, or you are filtering by multiple templates and the user doesn't have edit permission for all the included templates, then the user will not be allowed to see unpublished pages.

See here for the relevant code.

[adrian]

I use this to allow the use of include=all in the default selector in the config

$this->wire()->addHookBefore('ProcessPageLister::getSelector', function($event) {
    $event->object->allowIncludeAll = true;
});

 

[prestoav]

15 hours ago, adrian said:

I use this to allow the use of include=all in the default selector in the config

$this->wire()->addHookBefore('ProcessPageLister::getSelector', function($event) {
    $event->object->allowIncludeAll = true;
});

 

Hi Adrian,

I tried adding his to ready.php bug got this error when logged in as an editor:

 No templates specified so 'include=hidden' is max allowed include mode

18 hours ago, Robin S said:

By default Lister should automatically show unpublished pages that the user is allowed to edit as long as the Lister filters are limiting by template.

So if your user is allowed to edit template "basic-page", and the Lister filters include "template=basic-page" then the user will be able to see unpublished pages (without needing to have a specific "include" item in the Lister filters). But if you don't have a "template=" item in the filters, or you are filtering by multiple templates and the user doesn't have edit permission for all the included templates, then the user will not be allowed to see unpublished pages.

See here for the relevant code.

Hi Robin,

Yes, this does work, thank you.

[prestoav]

On 12/17/2022 at 2:44 PM, prestoav said:

Hi Adrian,

I tried adding his to ready.php bug got this error when logged in as an editor:

 No templates specified so 'include=hidden' is max allowed include mode

Hi Robin,

Yes, this does work, thank you.

Well actually, it sadly doesn't seem to always work...

This method worked on one of my sites but on a sister site (a near identical site actually) it doesn't work for one particular template.  It does work on the previous site (same template structure).

Looking at the template in question, neither it or its parent have any access control restrictions and the user is free to edit that page and its parent.

Anyone have any experience of this or further suggestions?

All help appreciated as always!

 

[prestoav]

For some more info, I've attached a small truth table as to what is possible in the page lister for the editor in question (first Lister filter set to template = template editor can edit).

It shows that, although the 'hidden' filter works ok when used independently, setting the page to 'Unpublished' means they don't show when the page is unpublished and this overrides the 'hidden' filter too so that pages that are both hidden and unpublished are not listed, even when the page is set to hidden and the filter is set to show pages that are hidden.

Again, any help is really appreciated.

[Robin S]

7 hours ago, prestoav said:

Looking at the template in question, neither it or its parent have any access control restrictions and the user is free to edit that page and its parent.

Anyone have any experience of this or further suggestions?

Does the template in question explicitly allow the role to edit, or is the access inherited from parent pages? If you haven't explicitly set the template access I think the likely solution is to set that access.

You have to remember that Lister is not creating its list by individually checking the access of every page and every page's parents.  Rather it's creating a selector string that produces the list. I can see some code in Lister that looks like it does take inheritance from the immediate parent into account if there is a "parent=" item in the Lister filters. But I think it would be more practical for you to explicitly set the edit access on templates that you want a role to be able to edit.

Personally I always set the access for every template in my site because I want to be sure I've made a conscious decision to control that access rather than let it potentially drift down unnoticed from some parent. I've never understood what reason there could be to not explicitly set the access controls on a template (maybe someone can explain the scenario where that is useful?)

Getting off topic now, but I have a module that makes it quick to check and set the access controls on templates across the site - I'll write up the readme and release it soon.

[prestoav]

On 12/19/2022 at 8:18 PM, Robin S said:

Does the template in question explicitly allow the role to edit, or is the access inherited from parent pages? If you haven't explicitly set the template access I think the likely solution is to set that access.

You have to remember that Lister is not creating its list by individually checking the access of every page and every page's parents.  Rather it's creating a selector string that produces the list. I can see some code in Lister that looks like it does take inheritance from the immediate parent into account if there is a "parent=" item in the Lister filters. But I think it would be more practical for you to explicitly set the edit access on templates that you want a role to be able to edit.

Personally I always set the access for every template in my site because I want to be sure I've made a conscious decision to control that access rather than let it potentially drift down unnoticed from some parent. I've never understood what reason there could be to not explicitly set the access controls on a template (maybe someone can explain the scenario where that is useful?)

Getting off topic now, but I have a module that makes it quick to check and set the access controls on templates across the site - I'll write up the readme and release it soon.

Hi @Robin S thanks for your input here.

You were right, for the admin lister to work for editor logins looking to find unpublished pages the following is needed:

1) The template must have explicit edit access for editors, not access settings inherited from a parent template
2) The template must be specified in the search alongside the 'Status has Unpublished' rule

The requirement for explicit access settings seems a little overbearing to me. If a user has inherited access to create and edit pages using a specific template then it seems sensible that those privileges shouldn't be limited by Lister. I think they should be able to find them in Lister without the template having explicit settings for access. From a UX point of view I think the current situation is misleading, especially as searching for hidden pages does work in the same scenario.

Thank you again for you input. This has meant a working solution for the client which is the important bit!