Similar problem is in #2096, but different solution
--------------------------------------------------------------------------------
yes, I had the same problem several times...

it's pretty common to look for something that someone has worked on...
--------------------------------------------------------------------------------
There seem to be many people who have the similar problem.

#3001
#2096

--------------------------------------------------------------------------------
yusuke kokubo wrote:
> #3001

correct is #408
I'm sorry.

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
Well such a assignee history could be added and included like the watchers.
They could be displayed in the sidebar or better in the tabbed issue history.
--------------------------------------------------------------------------------
Not exactly the same, but two new filters in Redmine 3.4 can help : see #17720
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

duplicates,Closed,17932,[Feature Request] History Assignee filter