Hi

Here's what's going on:
I have three Workflow states set up (Draft, Review and Approved) so that I can have an editor functionality. In the "access control" matrix for workflow I have set it up so that only editors and admins can edit or delete content once it has entered the "Approved state".
I am using Rules to trigger certain actions (sending of mail and such) when the workflow states change.
All this works like a charm, bar the fact that the authors still can edit their content through their workspace.
Now, in the Core permission matrix the authors can edit their own content... but I thought the workflow settings would override that.

Does the workspace module ignore the workflow settings in terms of permissions or is it the fact that I use Rules to control the actions that disturb things?

Any tips would be greatly appreciated

Yours

Omkara

Comments

hutch’s picture

hutch commented
Version: 6.x-1.3 » 6.x-1.x-dev

Workspace permissions are handled by the function workspace_access(), presumably that would have to be modded to handle additional permissions.

Omkara’s picture

Omkara commented
Version: 6.x-1.x-dev » 6.x-1.3

Hi Hutch

Thank you for the reply.

I looked at the function:

function workspace_access($account, $module_enabled = TRUE) {
  global $user;
  return user_access('access content')     // If you may not see content, you may not see workspaces.
    && (user_access('view all workspaces') // Must either have permission to see all workspaces
        || (($user->uid == $account->uid)  // or must be your workspace
        && ($user->uid != 0)))             // and you must not be an anonymous user
    && $module_enabled;                    // If, e.g., comment module is disabled, remove comment local task.
}

I'll be the first to admit that I don't know much about how things work "under the bonnet" here, but it seems that this function just determines if you get to the see the workspace or not and if it is to list content and/or comments and/or files.

Following a tip from another thread I tried to remove edit rights from the Core permissions to see if the workflow permissions would then "surface", but no luck.

BTW, is this really a workflow / node access issue... and so might be slightly misplaced here?

Yours

Omkara

hutch’s picture

hutch commented

I would have assumed that the workflow permissions was another layer that goes on top of existing permissions, eg if a user 'owns' a given node then they have write permissions unless overriden by the state imposed by Workflow rules. The current state that a node is in must be recorded somewhere and there is probably a function that will provide information on that state, or it may even be in the $node object, I don't know offhand and haven't got an example I can delve into. The devel module has a useful function dd(). If you added dd($node) to your code somewhere and had a look in /tmp/ you might find out more.

If you can find out how the Workflow rules are defined you could add code to the workspace_build_rows() function to prevent that node from being accessed for editing.

I just downloaded the Workflow module and see that there is a function workflow_node_current_state(), might be worth looking at.

Omkara’s picture

Omkara commented

Hi

I've made a hack in the workspace_build_rows function (workspace.module) that checks the workflow permissions and alters the variables that decides if the edit and/or delete links will appear in the list. However, if the user doesn't have edit/delete rights for the node type, then the links won't do anything ... and vice versa; if a user have edit/delete rights and know the node id and the path to edit and/or delete (for example ..../node//edit) then he or she can indeed edit/delete his or her own node.

.
.
.
     else {
        // If we can't find an access function, deny by default.
        continue;
      }
      
      // Start: Omkara's workflow permission extras 
      // Get the security id from workflow module
      $sid = db_result(db_query('SELECT sid FROM {workflow_node} WHERE nid = %d', $row->nid));
      
      If ($sid) {
      	//We can assume that the $row variable only contains rows for which the user is an author (i.e. rid = -1)	
      	if ($WorkflowPermissions = db_fetch_object(db_query('SELECT * FROM {workflow_access} WHERE sid = %d AND rid = -1', $sid))) {
	      	if ($WorkflowPermissions->grant_update == 1) {
	      		$may_edit = TRUE;
	      	} else {
	      		$may_edit = FALSE;
	      	}
	      	
	      	if ($WorkflowPermissions->grant_delete == 1) {
	      		$may_delete = TRUE;
	      	} else {
	      		$may_delete = FALSE;
	      	}
      	}
      }
      // End: Omkara's workflow permission extras 
      
      // The name of the owner of this node.
      $name = ($user->uid == $row->uid) ? $user->name : db_result(db_query('SELECT name FROM {users} WHERE uid = %d', $row->uid));
      $rows[] = array(
.
.
.

Also, this does not seem to be very elegant at all.

Unless someone has any really good ideas, I think I'll try posing these questions in a workflow module thread.

Yours

Omkara

verta’s picture

verta commented
Title: Author can still edit nodes in workspace after approval (ivolves Workflow and Rules) » Author can still edit nodes in workspace after approval (involves Workflow and Rules)

subscribing, ... (and updated title)

frank ralf’s picture

frank ralf commented
Category: support » feature
Status: Active » Postponed

Thanks for the suggestions and the code.

Workspace is intended as a lightweight module for providing easy access to a users content. Handling a full fledged Workflow is possibly beyond its scope so should indeed better be handled by the Workflow module(s).