Patch #16045

Add "Previous Assignee" entry when changing issue assignee

Added by Gurvan Le Dromaguet over 4 years ago. Updated about 1 month ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-

Description

Intention : assign ticket back to previous assignee easily, without scrolling down the list until I found it.

attached proposed implementation as svn patch. It needs to run "db:migrate"

Missing in the implementation:
- previous assignee in contextual menu
- maybe reusing changes done in r12419

Works good and very popular in my firm.

previous-assignee-v1.0.patch Magnifier (4.92 KB) Gurvan Le Dromaguet, 2014-02-06 18:37

20131010000000_add_previous_assignee.rb Magnifier (213 Bytes) Gurvan Le Dromaguet, 2014-03-03 12:07

last_assignee_wip.diff Magnifier (3 KB) Luka Lüdicke, 2016-11-17 11:43

previous-assignee-v2.0.patch Magnifier (4.34 KB) Mizuki ISHIKAWA, 2018-07-25 06:55

previous-assignee-v2.1.patch Magnifier (4.46 KB) Mizuki ISHIKAWA, 2018-07-25 06:55


Related issues

Related to Redmine - Feature #19501: Assign issue to <<author>> New
Duplicated by Redmine - Feature #24319: Last assigned to option in the Assignee selection list Closed

History

#1 Updated by Gurvan Le Dromaguet over 4 years ago

Works against 2.4-stable rev 12697

#2 Updated by Toshi MARUYAMA over 4 years ago

  • Description updated (diff)

#3 Updated by Toshi MARUYAMA over 4 years ago

  • You missed db migrate file.
  • mix tabs and spaces
  • please add tests

#4 Updated by Gurvan Le Dromaguet over 4 years ago

Thanks for pointing out !!! attached file, I will work on adding a test.

#5 Updated by Gurvan Le Dromaguet over 4 years ago

Toshi MARUYAMA wrote:

  • mix tabs and spaces

What is the rule for Redmine ?

#6 Updated by Toshi MARUYAMA over 4 years ago

Gurvan Le Dromaguet wrote:

Toshi MARUYAMA wrote:

  • mix tabs and spaces

What is the rule for Redmine ?

two spaces for indent.

#7 Updated by Samuel Samfra over 4 years ago

dear all, how do I install this ? patch -p0 for the patch ? What about the rb file ? thank you.. I come from the Java world :)

#8 Updated by Gurvan Le Dromaguet over 4 years ago

Samuel Samfra wrote:

dear all, how do I install this ? patch -p0 for the patch ? What about the rb file ? thank you.. I come from the Java world :)

1- apply "patch -p0"
2- copy rb file to db/migrate
3- run "RAILS_ENV=production rake db:migrate"

#9 Updated by Go MAEDA almost 2 years ago

  • Duplicated by Feature #24319: Last assigned to option in the Assignee selection list added

#10 Updated by Luka Lüdicke almost 2 years ago

I have a solution for this which does not require an extra column in the database for this, the information can be gathered from the journal_details

I am mentioning it just in case the reason for ignoring this proposal is the extra column.

#11 Updated by Go MAEDA almost 2 years ago

Luka Lüdicke wrote:

I have a solution for this which does not require an extra column in the database for this, the information can be gathered from the journal_details

Sounds great. Could you attach your patch to this issue?

#12 Updated by Luka Lüdicke almost 2 years ago

Alright, this from how I patched it at our company.

As you can see from the comments, it is a work in progress.
If you like it and want to include it, I can make a "cleaner" diff and add a unit test for the last_assignee method.

(my colleagues really love the feature)

things to look out for:

  • the option should not come up if current user und last_assignee are the same
  • the option should not come up if last_assignee is nil
  • when there is old assignee (new issue), the last_assignee should be the author (TODO)
  • the option should not appear in issue category and bulk update

#14 Updated by Luka Lüdicke about 1 year ago

Luka Lüdicke wrote:

If you like it and want to include it, I can make a "cleaner" diff and add a unit test for the last_assignee method.

like I said, if you like it I would make the effort for a clean patch that you could "just" apply...

#15 Updated by Luka Lüdicke about 1 year ago

suggestions for specs

Test Plan

Edit Issue

  1. open issue edit form
  2. use select box
  3. expect: last assignee is shown in the fist options
  4. expect: assignment to that user is successful

bulk edit

  1. open multiple issues with batch edit
  2. expect: successful page load and no last assignee option in assigned_to select box

Issue Category

  1. open project settings configuration
  2. open issue categories tab
  3. edit issue category
  4. expect: successful page load and no last assignee option in assigned_to select box

New Issue

  1. create new issue with an assignee
  2. open edit page of that issue
  3. expect: last assignee shows the author of the issue
  4. expect: assignment to the user is successful

#16 Updated by Albrecht Dreß 7 months ago

I applied the patch “last_assignee_wip.diff” to a standard Debian Stretch Redmine (v. 3.3.1), and it works somehow – only the value in the combo reads

<< <span class="translation_missing"; title="translation missing: en.issue.last_assignee">Last Assignee</span> >>
Anything I missed here?

BTW, it would be cool if the Last Assignee could be added to the Field Permissions in the workflow configuration, i.e. as an additional option for the Assignee field, which would actually force setting the previous assignee whenever the ticket is edited. Think of a typical (for me) use case: developer A needs feedback from reporter R, who has only the permission to set the Assignee field to the previous one. So A just sets the assignee to R. Now, when R edits the ticket, it will automatically be assigned back to A, avoiding all problems of a ticket mistakenly being assigned to another person. Would such an implementation be possible?

#17 Updated by Albrecht Dreß 7 months ago

Albrecht Dreß wrote:

I applied the patch “last_assignee_wip.diff” to a standard Debian Stretch Redmine (v. 3.3.1), and it works somehow – only the value in the combo reads

It appears that changing in app/helpers/application_helper.rb the line

     s << content_tag('option', "<< #{t('issue.last_assignee', name: User.find_by_id(last_assignee_id).try(:name))} >>",
                      value: last_assignee_id) if (last_assignee_id && (last_assignee_id != User.current.id))
to
     s << content_tag('option', "<< #{l(:last_assignee, name: User.find_by_id(last_assignee_id).try(:name))} >>",
                      value: last_assignee_id) if (last_assignee_id && (last_assignee_id != User.current.id))
fixes this.

However, now the wrong “last assignee” is displayed…

After printing some debugging output, it seems that the journals in app/models/issue.rb, last_assigned_to are actually sorted as latest first. Replacing

    journals.reverse_each do |j|
by
    journals.each do |j|
seems to do the right thing. Can you confirm this is the proper solution?

#18 Updated by Mizuki ISHIKAWA about 1 month ago

Thank you for sharing your patch, Luka Lüdicke.
I think this feature will be useful in projects with many users.

I made some changes, such as adding a test to your patch.( and I removed it because some changes for German were included. )
previous-assignee-v2.0.patch

Since I think that p"revious_assignee" is more appropriate than "last_assignee", I also created a version patch that replaced the "previous".
previous-assignee-v2.1.patch

Albrecht Dreß wrote:

However, now the wrong “last assignee” is displayed…

After printing some debugging output, it seems that the journals in app/models/issue.rb, last_assigned_to are actually sorted as latest first. Replacing [...] by [...] seems to do the right thing. Can you confirm this is the proper solution?

In my environment I seemed to work normally even with reverse_each.
Therefore, I use reverse_each also in the patch attached by me.

#19 Updated by Albrecht Dreß about 1 month ago

Mizuki ISHIKAWA wrote:

Albrecht Dreß wrote:

However, now the wrong “last assignee” is displayed…

After printing some debugging output, it seems that the journals in app/models/issue.rb, last_assigned_to are actually sorted as latest first. Replacing [...] by [...] seems to do the right thing. Can you confirm this is the proper solution?

In my environment I seemed to work normally even with reverse_each. Therefore, I use reverse_each also in the patch attached by me.

Hmmm, strange. Which Redmine version do you use?

#20 Updated by Mizuki ISHIKAWA about 1 month ago

Albrecht Dreß wrote:

Hmmm, strange. Which Redmine version do you use?

I tested on trunk( r17463 ) and 3.4 versions.

When I checked sql on rails console, it looks like ascending order.

  [1] pry(main)> puts Journal.all.to_sql
  SELECT "journals".* FROM "journals" 
  => nil
  [2] pry(main)> issue = Issue.first
  ~~
  [3] pry(main)> puts issue.journals.to_sql
  SELECT "journals".* FROM "journals" WHERE "journals"."journalized_id" = 1 AND "journals"."journalized_type" = 'Issue'
  => nil

thanks

#21 Updated by Go MAEDA about 1 month ago

Also available in: Atom PDF