Make UserGroup more OOP-y

[skippy]

The UserGroup class should be modified from using static methods to a more object-oriented implementation by extending the QueryRecord object, as described in this post: http://groups.google.com/group/habari-dev/msg/59d9e06675929e23

Attached is an untested work-in-progress effort to that effect.

UserGroups can be created using a static method. All other interactions are done through member properties:

// create the editors group $editors= new UserGroup( array( 'name' => 'editors') ); // allow editors to publish posts $editors->grant( 'publish posts' ); // editors should be explicitly forbidden from changing the theme $editors->deny( 'change theme'); // add a user to the editors group $editors->add( User::get_by_name('skippy')->id );

[skippy]

With respect to UserGroup::can(): as indicated in the habari-dev discussion of this issue, this needs to be a ternary value: * if a permission is explicitly denied, return false * if a permission is permitted, return true * if a permission is neither permitted nor denied, return null

Then, inside ACL::user_can() (invoked by $user->can() ), the user's groups can be iterated to evaluate each group's permissions. If any group denies the permission, ACL::user_can() would immediately exit with false. If no groups deny a permission and at least one group permits the permission, ACL::user_can() would return true, permitting the action. If no group denies nor permits the action, ACL::user_can() would return false to deny the action.

Any other opinions on this?

[michaeltwofish]

Perhaps when adding a permission we should add a default, and use that if the permission is not explicitly granted or denied for that group.

[michaeltwofish]

The attached patch is built on Skippy's usergroup.php (but patched from the original usergroup.php). It ties together group and member management in adminhandler.php, the admin/groups.php template and usergroup.php. Also attached is usergroups.php (note the plural).

There are many outstanding issues, and it's very much preliminary work. Specifically: * I have not worked on permissions at all. * The UI for the groups template is woeful. * The adminhandler could do with some DRY management. * Testing group membership is not implemented.

Criticism, feedback, patches, slaps around the head are most welcome.

[skippy]

revised version of usergroup.php with new methods and better logic

[skippy]

Attaching a revised version of usergroup.php with some substantial changes:

• Integrate additional methods get(), get_by_id(), get_by_name(), and exists() from Michael's patch
• Update permission assignment to groups. Introduce a $toggle_permissions array to hold an array of permissions to change. Rather than perform a DELETE and then INSERT the new data, simply UPDATE the value of the "denied" column.

Use usergroup.2.php in the list of attachments above.

[skippy]

minor tweak to logic in UserGroup::update()

[skippy]

r1326: usergroup.php is now more OOP-y. Closing this ticket.

I suggest we add a Permissions class to provide static methods Permissions::add(), Permissions::delete(), and helper methods necessary to convert back and forth between Permission names and IDs.