ticket reassign dropdown should show who it is assigned to currently

[thomas@…]

I am annoyed every time when I'm reviewing a bug report, get to the bottom, then don't know anymore who the bug was assigned to when I reach the "reassign to" dropdown box. Is it mine already ? Did I assign it to the right person ? Who knows!

The following one-liner changes the "reassign to (dropdownbox)" line to "reassign from (owner) to (dropdownbox) and is a simple one-line patch.

Also I assure you that your assessment of my ticket as 59% spam probability is 100% FALSE!

[osimons]

I was ready to follow your approach that seemed intuitive at first. Testing my first patch made me change standpoint:

• by far the most common reassign action is reassigning to oneself.
• restrict_owner (dropdown) or text field should have the same default value - and you should not have to type in your authname to change it from current owner.

So, I've made a slightly different approach by appending a (*) next to the current owner if it exists in the list. That gives a very useful visual indication in line with how we use it in related contexts.

trac/ticket/default_workflow.py

@@ -223 +223 @@
                 control.append(tag('to %s' % owners[0]))
                 hints.append(_("The owner will change to %s") % owners[0])
             else:
+                current_owner = ticket.values.get('owner', '')
                 control.append(tag([_("to "), tag.select(
-                    [tag.option(x, selected=(x == selected_owner or None))
+                    [tag.option(
+                            x + (current_owner == x and ' (*)' or ''),
+                            value=x,
+                            selected=(x == selected_owner or None))
                      for x in owners],
                     id=id, name=id)]))
                 hints.append(_("The owner will change"))

Comments on this approach - and patch review - most welcome.

[Thomas Vander Stichele <thomas@…>]

Hi,

Thanks for looking at this. I'm confused by your comments. I do not disagree with them, but I don't see why they invalidate my approach.

It sounds and looks like you were thinking that my patch is selecting by default in the drop down box who the ticket currently is assigned to. Is that what you are thinking ?

This is not the case. My patch adds a bit of text, like it says above: changes the "reassign to (dropdownbox)" line to "reassign from (owner) to (dropdownbox)"

ie, it adds "from (current owner)" inbetween "reassign" and the dropdown box/edit field, not touching the dropdown box/edit field at all.

I think it's not a good idea to just put an asterisk after the owner name in the dropdown box, because I have seen some huge dropdown boxes, and if it's a text entry field instead of a dropdown box, I'm not even sure what your patch does in that case ?

Let me know what you think.

[osimons]

Using 0.11 workflow action hints to show the 'from' information.

[osimons]

You're right. I was reading the summary about 'dropdown should show…' and just into my approach too quickly.

With 0.11 this is completely different as you might know, but one of the new things is that it allows 'hints' next to the actions giving more information. Discreetly in low-key grey by default.

I've made the patch to show the information there instead - see t5984-r6259-a-reassign_info.diff​

A better and cleaner approach. Thanks for keeping a watchful eye on things :-)

[Remy Blank]

Updated patch for 0.11-stable [7522]

[Remy Blank]

The second patch doesn't apply to 0.11-stable anymore, so I have updated it by hand. All unit tests pass, and I have done some limited functionality testing. A very useful addition.

[Christian Boos]

Looks good to me as well.

[osimons]

Further fix that fetches the true ticket owner instead of using the current preview owner.

[osimons]

Turned out the previous patches got things mixed up when using 'Preview' before further edits - it would use the future owner as current owner in hint text.

Could someone please test the latest patch? It's been so long since i made the first patch, that I'm not quite sure I've covered all use cases…

[osimons]

Gah. Identing error with 'accept' status.

[Remy Blank]

Right, I didn't notice this problem.

But I'm not sure about the solution. It feels like a hack to have to query the DB to get the original fields, when you had them a few lines up. Am I correct in assuming the problem originates with these two lines​, which update ticket.values before render_ticket_action_control() is run?

Does this even make sense? I think this is the source of another preview problem: if you select "resolve as fixed" on a ticket in state "new", and click "Preview", on the next page the first proposed action is "leave as closed" instead of "leave as new".

Maybe we can just move the ticket.values update after the action box rendering?

[Remy Blank]

My assumption above was wrong, it seems that the update to ticket.values is there by design (it is still a bit strange, as the same two lines appear a second time further down​).

However, the pre-change values of the ticket fields can be retrieved from ticket._old, and this is already done in several places in default_workflow.py. This also allows fixing the state display problem mentioned above.

Here's an updated patch that works for me in all cases I could test.

[Remy Blank]

Get pre-change field values from ticket._old

[osimons]

Thanks Remy - I knew I had seen references to old values somewhere before, but just didn't spot it when I needed it.

I think it works well now too, and applied the latest to 0.11 in [7529].

[osimons]

(and [7530] for trunk…)