Project

General

Profile

Actions

Patch #212

open

Assign To limited by workflow

Added by Amedeo Amedeo almost 17 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Issues workflow
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

First of all, thanks for this great product!

I had the problem of showing only the list of users involved in the new issue status rather than the whole list, so
I have applied this little change. Probably could have be done in a better way :)

Index: issues_controller.rb
===================================================================
--- issues_controller.rb        (revision 359)
+++ issues_controller.rb        (working copy)
@@ -105,7 +105,8 @@
         flash[:notice] = l(:notice_locking_conflict)
       end
     end    
-    @assignable_to = @project.members.find(:all, :include => :user).collect{ |m| m.user }
+    # @assignable_to = @project.members.find(:all, :include => :user).collect{ |m| m.user }
+    @assignable_to = Workflow.find(:all, :conditions => ["old_status_id = ?", @new_status]).collect {|w| w.role}.collect {|r| r.members}.flatten.collect {|m| m.user}.uniq
   end

   def destroy

Related issues

Related to Redmine - Feature #2937: Filter assignable users based on workflowNew2009-03-09

Actions
Related to Redmine - Feature #8313: Restrict Assignee List by RoleNew2011-05-06

Actions
Actions #1

Updated by Alessio Spadaro almost 17 years ago

Don't know if it is the right way to do it, but sure is the right
thing to do IMHO

Actions #2

Updated by Balazs Dan over 16 years ago

Hello Jean-Philippe,

I think something similar would be very very useful!
Now a user can come into a dead end if he assign the issue to
a user who is not involved in the new status. With a similar
solution we could avoid it.

I've tested this modification and I had to complete conditions
with tracker_id and I had to use @assignable_to in
change_status.rhtml. It is working but I'm sure it is not the
correct implementation! So I cant submit a patch at the moment.

BR,
Balazs

Actions #3

Updated by Marcin Gil over 16 years ago

There should also be a permission settings that only a user who's
currently assigned to a task (+ some manager) can reassign the
task.

So that I, as a simple team member, cannot reassign my colleague's
ticket and reassign it to someone else.

Actions #4

Updated by Joseph M almost 14 years ago

Is this issue fixed in newer versions? Or could someone please detail the steps to resolve it? I think it is really problematic that the workflow can come to a dead end like this.

Joseph

Actions #5

Updated by Thomas Pihl almost 14 years ago

This might depend on how you utilize Redmine. We often assign an issue to someone who cannot change state of it. They will comment the issue and assign it back or to someone else. Since anyone can change the issue, it is not stuck.

But then again, i do like even better workflow control and would not mind some control over the assigned to field (both what it contains and who may change it and to what).

Actions #6

Updated by Toshi MARUYAMA almost 13 years ago

  • Category set to Issues workflow
Actions #7

Updated by Daniel Felix over 11 years ago

Hey there,

this seems to be solved?

You can define special rights for a user if he is the ticket owner and if he just is assigned to it.

Please correct me if i'm wrong? Otherwise this could be closed?

Actions #8

Updated by Toshi MARUYAMA almost 8 years ago

  • Description updated (diff)
Actions #9

Updated by Toshi MARUYAMA almost 8 years ago

Actions #10

Updated by Dipan Mehta over 6 years ago

Under a given state of the issue - specific people should only be assigned. For example - when issue moves from development to QA and vice-versa.

However, the possible people who can be assigned should be 'role' based and not individual. Because, if workflow has many state, in each state, we need to add list of people who can be assigned. Further, the when people change, new get added, or some exit the project - you need to do the same exercise all over again.

Thus, the assignment restriction should be 'role' based only. As it is this is currently working in Redmine. Also, multiple roles per person is also permissible making it to create a finer role based assignments.

Should this issue be closed by now?

Actions #11

Updated by Toshi MARUYAMA over 6 years ago

  • Description updated (diff)
Actions

Also available in: Atom PDF