Alpha release: UserGroups (page based permissions)

[BitPoet]

Let me start with saying that UserGroups is one of the most important modules for me. Last week I noticed, though, that on our intranet (recently updated to PW 2.8 from 2.6) permission changes on a page weren't saved anymore. I tracked it down to the code in accessTabInput in UserGroupsHooks.module that somehow refused to assign the changed values from POST parameters.

I've built a (quick&dirty) workaround that accesses the raw post values and assigns from there, foregoing processInput() and isChanged() calls (processInput even fails to do its job if I instantiate my own InputfieldPage objects), but I don't want to rule out that I'm missing some setting or detail.

So if anybody has UserGroups working (or not working) in a 2.8 installation, it would be great to know so I know in which direction to take my further research.

[apeisa]

Thanks for the report BitPoet. We are little late on 2.8/3.0 train, so not yet tested this on it. How about @teppo?

[teppo]

Just now, apeisa said:

Thanks for the report BitPoet. We are little late on 2.8/3.0 train, so not yet tested this on it. How about @teppo?

Nope, nothing on this side either. Should find some time to test this soon.

[BitPoet]

I  found the time to test with a plain 2.8 installation, and it also refused to save changes. Just in case somebody needs a quick workaround too, I replaced the original code in UserGroupsHooks.module (starting at line 738):

		foreach(array('view_groups', 'edit_groups', 'manage_access') as $name) {
			$inputfield = $form->get($name);
			if ( $inputfield instanceof Inputfield ) {
				$inputfield->processInput($this->input->post);

				if( $inputfield->isChanged() ) {
					$page->set($name, $inputfield->value);
				}
			} else {
				$this->log->message("Not an input field in form: $name");
			}
		}

with this workaround for now:

		$fld = $this->modules->get("InputfieldCheckbox");
		$fld->attr('id+name', "manage_access");
		$fld->processInput($this->input->post);
		if($fld->value != $page->manage_access) {
			$page->set("manage_access", $fld->value);
		}

		if($page->manage_access) {
			$pa = new PageArray();
			foreach($this->input->post->view_groups as $grp) {
				$pa->add($this->pages->get($grp));
			}
			$pa->sort("id");
			$page->view_groups->sort("id");
			if($page->view_groups->implode("|", "id") != $pa->implode("|", "id"))
				$page->view_groups = $pa;
				
			$pa = new PageArray();
			foreach($this->input->post->edit_groups as $grp) {
				$pa->add($this->pages->get($grp));
			}
			$pa->sort("id");
			$page->edit_groups->sort("id");
			if($page->edit_groups->implode("|", "id") != $pa->implode("|", "id"))
				$page->edit_groups = $pa;
		}

The fix in Issue #45 is also necessary for PW 2.8.

[teppo]

Thanks, @BitPoet

I'll take a closer look at the code changes soon. Meanwhile I've created a new issue to the ProcessWire repository regarding UserGroups issue #45 and the related change in the ProcessWire core. I'd like to hear what Ryan thinks about that before implementing any kind of fix for that.

[lpa]

Is the latest version of this module at the GitHub repo? Is that version PW 3.0 compatible? I wish, you could update the GitHub repo with the latest version. 

[BitPoet]

Out of necessity, I wrote a little module that ties into UserGroups and allows admins to limit the available templates for new pages based on groups. The module is still very fresh but already in production use in our corporate intranet. If there's interest, I'd be happy to have it integrated into / shipped with the UserGroups module itself.

https://github.com/BitPoet/TemplateGroups

The settings are stored in their own database table (template_groups).