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 modify.inc.php 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.

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.

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 modify.inc.php

Task edit - template details.edit.tpl and currently modify.inc.php

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.)

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.

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/modify.inc.php 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.

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>
</table>

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.