"Assign to" history in filter or etc.
It will be nice if you implement possibility to filter by tasks fields hitory.
Situation for example:
I fix some bug and assign task to testers, and if my Boss want to watch list of tasks which I fix, he cant do it. But if you add filter "Has been assigned to:" it slove that problem.
Sorry for my english. Thanks.
#5 Updated by Dipan Mehta about 7 years ago
No! I beg to differ - the author is not asking that multiple users be assigned "simultaneously". Suppose 10 issues, have been assigned to me, i work on them and then state the state and assign to 'testers' - now if you search issues that have been assigned to me, are NONE!
Also, the current model of assigning multiple users is also not quite sufficient. Mostly, instead of 1 user- it assigns it to a group. Now, it is straight forward that I assign to "developers" group or "testers" group, but specifically, we cann't really pick specifically 2 or 3 people whoever gets time to work on. This is a major limitation. If that is solved, the above ticket can also be solved. For example, the above stated 10 issues are assigned to me, along with testers are 'added' amongst assigned users (but I still remain assignee as long as I am author) and may be till the ticket is closed! So in this model, assignee is not the currently assigned to but set of all assignees who are jointly responsible till the end of the ticket!
In many organization it is important to know, whether or not testing done properly or bugs are found, the ownership lies with the person who has originally designed for or coded for the work. Where as in current model, he/she no longer assignee after it has been handed over to testers. the PM has to then go back and find and re-assign the ticket to that person if more work is required. Also, trying to find which assignee has been through maximum accumulated or not closed (i.e. not gone to market as they have now gone to QC, review etc.) ticket is actually hidden,unknown or even undefined.
Understand that in a typical organizations, we see there is 1 manager - 2 - 3 developers, and 1 or 2 testers are associated for a given ticket- where as project team can have larger developer groups and testing groups etc. So assigning the ticket to whole group almost always means no specific ownership! This is a real challenge - and this specific issue shows only one of the potential use cases.
this of course, could be a major change in the issue's model - so not quite sure when can this be accomplished.