Implementation of hook_access in iPaper does not play well with workflow_access

The way ipaper_access function was implemented, it does not play well with other node access modules. I particularly had a problem making the module work with workflow due to conflicts between the ipaper_access function and workflow_access.

I fixed it substituting the module's original ipaper_access function with the one described bellow:

/**
* Implementation of hook_access().
*/
function ipaper_access($op, $node) {
global $user;

if ($op == 'create') {
// Only users with permission to do so may create this node type.
return user_access('create ipaper');
}
// Users who create a node may edit or delete it later, assuming they have the
// necessary permissions.
if ($op == 'update') {
if ( user_access('edit own ipapers') && ($user->uid == $node->uid)) {
return true;
}
else if (user_access('edit ipapers')) {
return true;
}
}
if ($op == 'delete') {
if ( user_access('delete own ipapers') && ($user->uid == $node->uid)) {
return true;
}
else if (user_access('delete ipapers')) {
return true;
}
}
if ($op == 'view') {
if (user_access('view ipapers')) {
return true;
}
}

}

Before I had to give users at least "edit own ipapers" and "view ipapers" permissions and could not restrict view or edit access acording to workflow states. With the change described above I made iPaper behave correctly with workflow_access. Now I can give users only "create ipaper" permission and control further access through workflow_access.

I believe similar conflicts exists between ipaper and other content access modules and that the above implementation should make ipaper behave better with such modules.