This defect allows to assign issue to user that is not permitted to have issued assigned to him.
Screenshots attached.
--------------------------------------------------------------------------------
The author of an issue is always on the list. I think it is the expected behavior added in r4240.
--------------------------------------------------------------------------------
I think that is not OK. If role does not permit user to have issues assigned to him, the role settings should be respected.

Look at this scenario:
- The reporter (user that should not have issues assigned to him) creates the issue.
- The developer (another user) is assigned through category (as default assigner for that category) of that issue.
- The developer changes status of that issue, and reasigns the issue to the reporter (by chance)
- The reporter updates the issue (the issue that is unfortunately assigned to him),
- That issue remains assigned to reporter after update.

That is wrong, especialy when the reporter have no ability to set assigner (remember that the issue is set through category defined assigner).
Even more serious is that, if reporter updates the issue, no email notification will ever come to initial assigner (developer) to further work on that issue. The developer will never know that issue is lost out of his sight.

Is there possibility to override or disable current unwanted behaviour?

--------------------------------------------------------------------------------
Is there possibility to override or disable current unwanted behaviour?
--------------------------------------------------------------------------------
The behavior may be ”unwanted” for you, but it is not unwanted for other people. Please see #4199.
--------------------------------------------------------------------------------
I agree that some users find that behaviour useful, but some as a defect.
I suppose that it would be nice to have ability to set/unset this functionality on project settings. Maybe you can consider it as a feature.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
If you assign it back to the author, who has no role on the project, they can never assign it to anyone else. What's the intended workaround for this "feature"?
--------------------------------------------------------------------------------
I found this post since we also noticed this "feature" has been making communication troubles in our organization.

It may be useful in some case according from the ticket (almost 10 years ago though), but from our point of view, we can’t even think of a reason why it is possible to assign a ticket to someone who can’t even see it.

We hope that the design is re-considered and make it optional in the project Settings page.
Thank you for your consideration!
--------------------------------------------------------------------------------
I changed this unwanted "Feature" with following dirty fix.

In file @/opt/redmine-4.0.0-0/apps/redmine/htdocs/app/models/issue.rb@ found this code block:
<pre>
# Users the issue can be assigned to
def assignable_users
users = project.assignable_users(tracker).to_a
users << author if author && author.active?
if assigned_to_id_was.present? && assignee = Principal.find_by_id(assigned_to_id_was)
users << assignee
end
users.uniq.sort
end

</pre>
... and commented line "users << author if author && author.active?":
<pre>
# Users the issue can be assigned to
def assignable_users
users = project.assignable_users(tracker).to_a
# users << author if author && author.active?
if assigned_to_id_was.present? && assignee = Principal.find_by_id(assigned_to_id_was)
users << assignee
end
users.uniq.sort
end
</pre>

That's all.

I hope that this unwanted Feature might be considered for fixing in future releases.

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

duplicates,Closed,31466,Error assigning a task to a user whose role does not allow it