Project

General

Profile

Actions

Defect #30771

closed

Author of issue is listed at assignee drop box

Added by VD DV almost 6 years ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Permissions and roles
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Wont fix
Affected version:

Description

The issue author that has role with disabled "Issues can be assigned to this role" is still listed at Assignee dropbox (while editing the issue).


Files


Related issues

Has duplicate Redmine - Defect #31466: Error assigning a task to a user whose role does not allow itClosed

Actions
Actions #1

Updated by VD DV almost 6 years ago

This defect allows to assign issue to user that is not permitted to have issued assigned to him.
Screenshots attached.

Actions #2

Updated by Go MAEDA almost 6 years ago

The author of an issue is always on the list. I think it is the expected behavior added in r4240.

Actions #3

Updated by VD DV almost 6 years ago

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?

Actions #4

Updated by VD DV almost 6 years ago

Is there possibility to override or disable current unwanted behaviour?

Actions #5

Updated by Go MAEDA almost 6 years ago

The behavior may be ”unwanted” for you, but it is not unwanted for other people. Please see #4199.

Actions #6

Updated by VD DV almost 6 years ago

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.

Actions #7

Updated by Go MAEDA over 5 years ago

  • Has duplicate Defect #31466: Error assigning a task to a user whose role does not allow it added
Actions #8

Updated by Jon Schell about 5 years ago

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"?

Actions #9

Updated by Simon Hori over 4 years ago

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!

Actions #10

Updated by VD DV over 2 years ago

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:

  # 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


... and commented line "users << author if author && author.active?":
  # 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

That's all.

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

Actions #11

Updated by Go MAEDA 4 months ago

  • Status changed from New to Closed
  • Resolution set to Wont fix

I am closing this issue because this is not a defect but an expected behavior.

Actions

Also available in: Atom PDF