278823 - "Back to bug xxx" is incorrect for dependency

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[Vlad Dascalu]

After pushing "Commit" (when changing, let's say, the resolution of a bug),
emails go out, first to the CC list of that bug, and then to the dependency list.

All of those have "Back to bug XXX" in their right side. However, only the first
bug was ever visited. The dependency list was probably not visited and "Back"
doesn't make sense for them.

Comment 1

[Max Kanat-Alexander]

This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to [e-mail] or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.

Comment 2

[Olav Vitters]

Attachment: Patch v1

I decided that only for type bug it should say 'Back To' and for the rest 'Go
To', because:
votes: is when you confirmed it, you do this from the vote page, not from the
bug
dupe: you submitted it from another bug
created: bug didn't exist before (you can't go back before the existance of a
bug). Maybe the entire message isn't needed because the template will show the
new bug.
dep: see original description

There is probably a better name for the variable (currently 'text'). Also all
those 'Go To' are repeated, but I did that for consistency with how the title
worked.

Comment 3

[Dave Miller [:justdave]]

Comment on attachment 176456 [details] [diff] [review]
Patch v1

This patch seems to have a conflict with the patch from bug 284446, which
landed earlier today, and thus no longer applies cleanly. :( This new wording
makes a lot of sense, though, if we could get a refresh on the patch.

Even after correcting the conflict, though, we have a test error with this
applied:

not ok 135 - (en/default) template/en/default/bug/process/results.html.tmpl has
unfiltered directives:
#   65: text.$type 
# --ERROR

This means there's no filter being used on the [% text.$type %] on line 65. 
It's static text in the template however, and we know it's safe.  There's two
ways to fix that.  One is to add FILTER html after it (which isn't really
necessary, but probably harmless).  The other is to add it to the exception
list in template/en/default/filterexceptions.pl, which is probably the
more-correct thing to do in this case.

Comment 4

[Olav Vitters]

Attachment: Patch v2: Updated for cvs changes, add filterexception

Updated for latest changes, added text.$type to the filterexceptions.pl

Comment 5

[Frédéric Buclin]

Comment on attachment 177602 [details] [diff] [review]
Patch v2: Updated for cvs changes, add filterexception

I like it! And runtests.pl is happy too! :)

r=LpSolit

Comment 6

[Dave Miller [:justdave]]

Checking in template/en/default/filterexceptions.pl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/filterexceptions.pl,v 
<--  filterexceptions.pl
new revision: 1.38; previous revision: 1.37
done
Checking in template/en/default/bug/process/results.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/results.html.tmpl,v
 <--  results.html.tmpl
new revision: 1.9; previous revision: 1.8
done

Comment 7

[timeless]

the removal of the # hurts my ability to use typeaheadfind. i want my # back.

Comment 8

[Olav Vitters]

(In reply to comment #7)
> the removal of the # hurts my ability to use typeaheadfind. i want my # back.

I suggest greasemonkey. Bug 278823 (without evil #) is the one true way.