Tasks drag to re-order without task edit permission

I agree with otakikam, and will look into this. Users should have as simple interface as possible.

Not regarding the simplicity issue - it is a bit inconsistent with the permissions, and there are several other places in Storm that happens which could do with fixing.

Would it be as simple as an if (edit permission) { click and drag function } else { standard table } ?

Should be something like that:

In function theme_stormtask_tasks (in stormtask.theme.inc) only this line is important to make rows draggable:

    $row['class'] = empty($row['class']) ? 'draggable' : $row['class'] .' draggable';

and in function stormtask_tasks_form (in stormtask.admin.inc) omitting this code will prevent user form saving.

  $form['submit'] = array(
    '#type' => 'submit',
    '#submit' => array('stormtask_tasks_submit'),
    '#value' => t('Save'),
  );

but that is only template side, there is more work to make it really secure. This two changes should fix presentation side but I searching how to really prevent (even malicious) users from modifying list.

Would it be enough to add check for permissions in function stormtask_tasks_submit (in stormtask.admin.inc) or it is enough not to show $form['submit'] ?

Personally, I'd do both, i.e. add permission check for display and submit just to make sure.

Just to add an extra question - say a user has the permission 'edit own', how should this be handled for this purpose?

---

I'd like to solve this issue before the release of 6.x-1.24.

(See #540212: Testing of -dev version before 6.x-1.24 release)

The issue that I mentioned previously relates to that if a user does not have a simple edit permission, it may be that the user is supposed to be allowed to be edit some nodes that are listed and not others. Therefore, in the attached patches, I have simply used the user_access('stormtask: edit all') rather than stormtask_user_access().

However - it does seem to be a bit of a hack method, which I don't like all that much (small changes all over the place).

Did anyone have any more thoughts on this one?

As this only applies to a projects task, can we check permissions on the project instead of all tasks, i.e. if they're allowed to edit the project then they're allowed to re-order the tasks?

Sounds like it might be better.

In terms of the node and where the data is stored - we'd be bypassing the permissions by changing the weight and/or parent task fields when the user may not have permission to, but conceptually I guess those fields only have a relevance when seen together on the project.

Very pleased to say that this one has been fixed, should have got this in ages ago.

Committed to both D6 and D7. Dev within 12 hours.

Its not the neatest possible unfortunately, checks for stormproject_access('update', $project->nid) a fair bit.

I gave a user all the task permissions. Theoretically it should allow him to reorder but it doesn't (was reported here ). There are also two extra empty and therefore useless column headers now.

As stated in #677830: Ajax crossed arrow icons missing in hierarchical task view and above, this has been applied so that if you can edit the project of the tasks, you can reorder the tasks for that project using the ajax 'clickndrag'.

There should not be empty column headers appearing. I will check this, but I seem to remember putting the access checks on them as well so that they would not appear if the user did not have permission to reorder the tasks.

I've just checked to see whether empty column headers appear on the demo site, with users with all then limited permissions.

All appeared correctly.

That the user could not re-order had to do with the project permission (they apparently come into play too). With no project permissions set, no re-ordering is possible and the two empty columns don't appear either, but I can give an exact permission combination that will make the columns appear and I don't understand really why it should be prohibited to re-order:

• Storm: access dashboard
• Storm project: delete own
• Storm project: edit if project manager
• Storm project: edit own
• Storm project: view if assigned to project
• Storm project: view if project manager
• Storm project: view own
• Storm task: all permissions enabled
• All other Storm permission disabled

That is for a project where the user:

• created it
• is the project manager
• is assigned to it

The tasks in the list were both created by the user and the user was assigned to them.

Can you reproduce that on your test system?

OK - I see the additional columns there - will have a look at why its happening.

OK - does this patch solve the issue?

Yes, user with the indicated permission does not see the empty columns any more and can now reorder through Ajax. Thanks!

Committed. Thanks.