• Status Confirmed
  • Percent Complete
  • Task Type Bug Report
  • Category Backend/Core
  • Assigned To No-one
  • Operating System Linux
  • Severity High
  • Priority High
  • Reported Version 1.0-rc
  • Due in Version 1.0
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Flyspray
Opened by thess - 07.06.2016
Last edited by peterdd - 07.07.2016

FS#2135 - "Modify own tasks" does not function correctly when added to "Reporters"

“Oh, there are some incompatible properties set that must be resolved before moving this task to a different project.”

Oh, but I am not moving the task to a different project. Just trying to edit my own submission.

“Edit this task” → “Save details”

See attached screen capture.

Project Manager

Do you have a screenshot of index.php?do=pm&area=groups&project=1

(replace 1 with your project id)

In what groups is the actual user. (global group and project group)

thess commented on 08.06.2016 14:40

Result of query: index.php?do=pm&area=groups&project=5

Error #16: You are not a project manager

The user is in the global 'reporters' group with some additional privs. I also tried a project group and get the same error (as reported)

thess commented on 10.06.2016 18:25

It appears the fields with the complaints are those which the user is not permitted to change (which is correct). Furthermore, the values shown in this fields are the "defaults" and not the values currently in them (that is wrong).

Both the details.edit.tpl display and the checks are at fault here. You should see the current values AND should should not be permitted to change them. The modify code should default to the current values or just not look for disabled values in the POST.

Same issue here.
I really don't understand what should I do in order to modify tasks using button and not fast edit from the above comment. Can you please explain more elaborate to a newbie?

The fields that I cannot change are task status, percentage, priority, due version.
Task status should be changeable; percentage also, priority. The due version doesn't matter for me.

What should I do? Only the project manager and admin can modify tasks, which isn't a solution.

Project Manager

I will dive into this issue this weekend.

thess commented on 23.06.2016 18:52

Great news! I was going to dig into this myself in a week or so. If you need any help testing, just ask.

Project Manager

I wasn't aware that the modify_own_tasks permission has some intended field change limitation when I was working on the move-task checks, sorry.

This was not documented nowhere, nothing about that limitation noted on Damn!

Beside that annoyence it reveals a small security issue if you trust that 'modify_own_tasks' limitations as that field overwrite permissions are not checked serverside at the moment. So a user with only 'modify_own_tasks' can modify all task fields of that task by sending the full edit form.

I made now comments for work on this section

case 'details.update':

I have no time this weekend as I'm playing a tournament.. Well, I'm probably out on saturday, so sunday maybe back home. ;-)

Project Manager

To solve the field-change limitation of modify_own_tasks without redundancy, the fields that are allowed or forbidden to change should be defined central in Flyspray 1.0, so that information is consistent available for:

  • Mass task operation feature - form template and currently
  • Task edit - template details.edit.tpl and currently
  • Task quick edit feature - template and form processing serverside
  • show it on admin and project area: permissions overview page - maybe as tooltip on edit_all_tasks and modfiy_own_tasks rows
  • maybe on users my permissions table as tooltip too

and future:

  • API must respect this too
  • other views for instance: drag-n-drop of tasks on a timeline or ganttchart

For Flyspray 1.0 and to keep things simple:

  • Define that field-change permissions hardcoded, not (yet) configurable for every project. Though I will probably use constructor of class.project.php for it ..
  • Only these 2 fixed levels of task edit permissions: modify_all_tasks and modify_own_tasks

Open question when it comes to implementing custom fields: When adding a new task field - And the field is added to the tasks-databasetable as custom_blabla, define also if it can be changed by *modify_own_tasks* permission.
E.g. by appending a central field-change permissions array?

(This may eventually expanded later to even limiting field values of some fields, like allowing some users only defined field values making building task workflows possible.)

Project Manager

Did some quickfix work available in github master

Do not forget to press F5 to reload the css file in web browser after update, because there are also some small CSS changes made for displaying error messages.

Maybe I am not doing something right, but I don't have the issue where I can't save changes to the task anymore. However I'd like for the original poster of task to change the status, which is blocked.

If I am fast editing task details it works, however when I have to edit the whole task, this comes inactive.

Attached a print screen.

   test.PNG (20.1 KiB)
Project Manager

Yeah, this is inconsistent at the moment!

As it looks like you are using Flyspray in a bigger setup: What fields a user with modify_own_tasks only permission should be editable or can be disabled for editing?

The 'disabled' fields are only disabled in the HTML, field permission currently not checked by the form handler on the server. So anybody with a litte bit knowledge of todays builtin browser tools can still send the 'disabled' fields, just by removing 'disabled' attributes from htmltags.

But I will fix this and then the field permissions will be enforced at every place. So I need some feedback by Flyspray community which fields should be allowed and forbidden to change by a user with only modify_own_tasks permission. (Flyspray 1.0)

I started to centralize that definitions, so the templates and the from handlers that write the changes to the database (currently includes/ and js/callbacks/quickedit.php) can use this consistent in future. But the more I think about it will require also some database changes, so this is for FS1.1 or later.

In details.view.tpl (quick_edit) it is only checked for


But in details.edit.tpl are lines like

<select id="status" name="item_status" <?php echo tpl_disableif(!$user->perms('modify_all_tasks')); ?>>

So a user with only modify_own_tasks permission sees some disabled fields. The fields which are disabled are currently hard defined in details.edit.tpl .

Approach 1 for Flyspray 1.0

No database change required: Hardcode the field permissions sitewide as nested arrays at the project constructor in includes/class.project.php
No per project definition..

  • Check the centralized, but hardcoded field permissions in and quickedit.php form handlers.
  • For quickedit on details.view page: make it visible which fields are editable by quickedit and which not.
  • For details.edit page (maybe):instead of disabled input fields only show the field values, so it doesn't look so ugly..(?)

Notes for future (Flyspray 1.1+ maybe)

Approach 2

Enhance the table groups by this fields:

<field name="canview_taskfields" type="C" size="1000"><descr>comma separated list of task fields</descr></field>
<field name="canview_owntaskfields" type="C" size="1000"><descr>comma separated list of task fields</descr></field>
<field name="canedit_taskfields" type="C" size="1000"><descr>comma separated list of task fields</descr></field>
<field name="canedit_owntaskfields" type="C" size="1000"><descr>comma separated list of task fields</descr></field>

Approach 3a

An new table group_taskfield_permissions

<table name="group_taskfield_permissions"><descr></descr>
  <field name="group_id" type="I" size="5"><descr>foreign key to table groups</descr></field>
  <field name="taskfield" type="C" size="40"><descr>a fieldname from tasks table, fieldnames can contain also custom_* fields in future probably!</descr></field>
  <field name="canview" type="I" size="1"></field>
  <field name="canview_own" type="I" size="1"></field>
  <field name="canedit" type="I" size="1"></field>
  <field name="canedit_own" type="I" size="1"></field>

Approach 3b

This variant enable even to define rules which values can be set for a field by a user group. (merge the permission rules of the groups the user is in to calculate for the current project/task)
This would make granular definition of workflows possible like
'Group Developer' can set task status from 'planned' or 'open' to 'implemented dev' and
'Group Tester' can set a task status from 'implemented dev' to 'tested ok' or reject by setting it to 'open'. (with a comment for instance)

But chances are that it gets too far and users are annoyed by complexity or gets bloated.

<field name="canedit" type="C" size="1000"><descr>1/0 or even rules of allowed values for that user group</descr></field>
<field name="canedit_own" type="C" size="1000"><descr>1=yes/0=no or even rules of allowed values for that group</descr></field>

This same issue being reported here also affects the "Basic" user group if "edit own tasks" is enabled for them. Would definitely be nice to see fixed up properly since it's one of two issues we've seen that currently prevent us from adopting Flyspray as a replacement for our existing bug tracker.


Available keyboard shortcuts


Task Details

Task Editing