Disallow page edit, but allow moving children

[Beetrootman]

Hello,

I've run into a case where I don't want a user to be able to edit a parent page, but do want them to be able to sort/move its children. I know that the page-sort permission depends upon the same role having page-edit permissions on the parent, but I wandered if there was a way around this? For now I hide the "Edit" button with CSS if the user is not a superuser, but this is not an ideal solution as they could still potentially edit that page via the correct url.

Is there anything I could hook into if a certain user tried to load the edit page for that particular parent template? Something like this, but I don't know how to actually prevent the page loading:

$config->addHookAfter('Page::loaded', function (HookEvent $event) {
  $page = $event->object;

  if ($page->template == 'projects' && $user->id !== 41) {
	// Do something to stop that page being edited
  }
});

Thank you for any help

[Robin S]

It seems that the user needs to have the page-edit permission for both the parent page and the child page in order to sort the child page. I hadn't noticed this before. It's a shame that the page-sort permission can't be granted independently of page-edit as it seems like they involve quite different levels of risk/responsibility. I opened a request at GitHub: https://github.com/processwire/processwire-requests/issues/290

As for a hook you could use this in/site/ready.php:

// Just for your target role
if($user->hasRole('editor')) {
	$wire->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) {
		/* @var ProcessPageEdit $ppe */
		$ppe = $event->object;
		$page = $ppe->getPage();
		// The names of templates that the user is not allowed to edit
		$disallowed_templates = ['colours', 'colour'];
		if(in_array($page->template->name, $disallowed_templates)) {
			// Replace the Page Edit markup
			$event->return = 'You do not have permission to edit this page.';
		}
	});
}

This may not be 100% secure in that a person could theoretically create their own edit form in their browser dev tools (although I think that's a very unlikely possibility). But if you wanted to be extra safe you could follow an alternative approach of limiting access at the field level for all the fields in the relevant templates. Depending on the number of fields that could be a hassle via the admin interface so you could look into doing it via the API.

[jonatan]

@Robin S Any news on this?