ProcessLister problems with unpublished pages and edit access inheritance

[poljpocket]

Hi all.

I just ran into a very strange problem. The solution is below but I am just not sure if this is a 'feature' or a bug ?!

My lister bookmark for selector:

'has_parent!=2, template=62, categories=1072, limit=25, sort=-modified, include=unpublished'

gets changed into below selector whenever I am not logged in as a superuser:

'has_parent!=2, template=62, categories=1072, limit=25, sort=-modified, include=hidden'

Note the 'include=' part which is changed. EDIT: Template with ID 62 is 'product' in this case. I am referring to it by name instead of ID.

From reading the source code, I can follow this exactly here:

// if all specified templates are editable, include=unpublished is allowed
if($numEditable == count($templates)) {
    // include=unpublished is allowed
} else if($includeMode == 'unpublished') {
    // include=unpublished is not allowed
    if($showIncludeWarnings) {
        $this->resultNotes[] = $this->_("Not all specified templates are editable. Only 'include=hidden' is allowed");
    }
    $includeSelector->value = 'hidden';
    $changed = true;
}

This is taken from ProcessPageLister here. The way the $numEditable variable gets determined is as follows:

foreach($templates as $template) {
    $test = $pages->newPage($template);
    $test->id = 999; // required (any ID number works)
    if($test->editable()) $numEditable++;
}

You can find this here, a few lines above the first snippet. The selector doesn't contain any parents, so these lines are the ones being used.

Whenever I am logged in as non-superuser, I can also see the error message "Not all specified templates are editable. Only 'include=hidden' is allowed". So everything behaves just as intended.

Now for the solution, which brings me to this possible bug:

Adding access control to the template 'product' and enabling editing for the specific role solves the problem. The lister now shows unpublished pages and the error message is gone. So far so good. But: Before the change, the user could still edit the products because access was inherited automatically from the home template. Hence on the surface, the configuration is exactly the same and the user can do exactly what they could before. Only the direct access has changed which has an impact on the 'editable' check.

The question now is, is this intended or am I looking at an edge case which isn't covered by the rather simple editability check using an arbitrary new page? @ryan: Could it be that Lister should add a parent to enable access inheritance in this check? I can imagine that this gets very complicated rather quickly...

Edited February 19 by poljpocket
add clarification for template 62=product

[poljpocket]

I have opened an issue on GitHub since this would be the right place to discuss this: https://github.com/processwire/processwire-issues/issues/1885

[poljpocket]

The issue has been discussed and closed directly on GitHub.