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.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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)
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)
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.
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.
I will dive into this issue this weekend.
Great news! I was going to dig into this myself in a week or so. If you need any help testing, just ask.
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 http://www.flyspray.org/manual/editing_task_details/ 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
https://github.com/Flyspray/flyspray/blob/master/includes/modify.inc.php section
I have no time this weekend as I'm playing a tournament.. Well, I'm probably out on saturday, so sunday maybe back home.
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:
and future:
For Flyspray 1.0 and to keep things simple:
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.)
Did some quickfix work available in github master https://github.com/Flyspray/flyspray
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.
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/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.
In details.view.tpl (quick_edit) it is only checked for
But in details.edit.tpl are lines like
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..
Notes for future (Flyspray 1.1+ maybe)
Approach 2
Enhance the table groups by this fields:
(xmlschema03)
Approach 3a
An new table group_taskfield_permissions
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.
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.