• Status Confirmed
  • Percent Complete
  • Task Type Feature Request
  • Category Backend/Core
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Medium
  • Reported Version 1.0-rc9
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Flyspray
Opened by dango - 05.08.2019
Last edited by peterdd - 08.08.2019

FS#2561 - ability to limit assignee permissions (was:User without Privileges to edit tasks can do so)

I gave a role the following privileges:

  • view own tasks
  • modify own tasks
  • view comments
  • add comments

I think there is a bug.
Is there a fix or walk around?

Project Manager

Could you please show the permissions and in which global group and maybe project group the user is? (screenshot)

Do you mean that user can edit task description and details for all tasks of a project or even all projects? Not only 'own'?
Maybe that user has that permission got being in a global group?

dango commented on 05.08.2019 17:43

I created a group "Gast" (Flyspray_Groups.png).
I created a user "Bauleitung". (Flyspray_User_Bauleitung.png)
User "Bauleitung" ist Member of Group "Gast". (Flyspray_Group_Members.png)

As example I have three Tasks (Flyspray_Tasks.png)

Task #116 is not assigned to User "Bauleitung" and cannot be edited. (Flyspray_Task_116.png). –> That is correct.

Task #115/#114 are assigned to User "Bauleitung" and can be edited by that user. (Flyspray_Task_115.png) According to the Role-Settings for Group "Gast", that should not be possible. –> Problem

The problem exists for all Tasks which are assigned to the user "Bauleitung.
The user does not have access to other projects and therefore cannot modify other Tasks. –> That ist correct.

What I would like to attempt is, that user "Bauleitung" gets Tasks assigned. He should only be allowed to add comments, but not to change the titel of the Task or the Task-Description. According to the privileges in the Group, this should be possible.
Hope these informations help.

Thanks for your support.

Project Manager

It seems the logic changed a bit with in 2015.

Previously the modify_own_tasks permission was used only to check with assigned users. (probably what you had in mind)

Now the modify_own_tasks permission is used for the user who created/opened the task. And permission to edit the task is given to all assignees of that task regardless of the missing modify_own_task.

So the 'own' of a task is a bit ambiguous over time. In the previous logic, what is the use case of having an assignee of a task without permission to edit that task permission?

dango commented on 06.08.2019 09:36

Let's consider you are working in a project with people that are not familiar with bug-tracking tools. In this case, you might want to keep the whole story simple. Create a task as a project manager, assign the task to someone (assignee) who should complete the task. You end up, that the project manager decides, if a task is completed or not. In this case, you probably don't want the assignee to change the original order.

Otherwise, there is a chance, that the assignee writes his comments directly in the task field and not in the comments section.

Flyspray ist very powerful and all the features are not only helpful for software projects but for all sort of task(lists) and project management in general. My experiences in these cases is, that it is very helpful, if you can guide the (not so sophisticated) users that they only can change, what they are supposed to.

Project Manager

Yeah, I understand. Would revert the change from 2015 linked in my first comment solve your use case?

Probably splitting the ambiguous modify_own_task permission into 2 separate permissions required.

  1. one to implement your construction/projectmanagment use case (limit the permissions what an assignee can do with a assigned task in Flyspray, an assignee then is more like tracking who is doing the real work outside Flyspray, and reports back only to the project management, not changing task fields)
  2. and the ticket/bugreporting use case - permission what a task creator can do with a task) - (which could work more like an automated ‘selfassign’ when creating a task, mmh..)

This task overlaps a bit with other feature requests like the wish to more granulary define which task fields are allowed to edit by which edit task sub permissions (project manager-all, edit project tasks - most, edit only assigned tasks - limited, edit only selfcreated tasks - limited)

Project Manager

related: close own task permission

What own means?

Should be reviewed together to make the UI and documentation/tooltips consistent.

dango commented on 08.08.2019 21:04

I think the revert of the change from 2015 would work fine. In my option it would be ok, if it could be configured that an assignee couldn't change the title of a task and the task description, meaning that an assignee can still change other metadata of a Task. As far as I understand flyspray, the creator of a task receives updates for tasks by E-Mail. From the point of view of the task creator, the most important thing is to have a valid chain from creating a task until the closure with the complete history of all comments (a sort of an audit trail). If an assignee "plays" around with the meta-information of a task (like % of completion, category, …) that is less "harmful" to reconstruct what happened in the task history, because all the text entries (Task description, all comments) are still valid and in correct order. The task creator can always fix such information, but if the task description gets messed up, the task history is more likely difficult to reconstruct.

Your assumption 1 is valid and would help as far as I understand.
Assumption 2 is not clear to me, because I haven't come across problems as Task creator, so far.


Available keyboard shortcuts


Task Details

Task Editing