User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR 1.0.3705) Build Identifier: for a QA engineer who recives printed reports on their desk, it would help if he knew which bugzilla instance it came from. Many sites leave their header as the default "This is Bugzilla" Reproducible: Always Steps to Reproduce:

how do I get the server and url base in templates???

[% Param("urlbase") %]

Comment on attachment 160892 [details] [diff] [review] bugzilla-208711-v1.02.diff Bug needs to be replaced with a template variable since it can be customized to "issue" or other things by Bugzilla administrators. I think it's [% terms.Bug %], check template\en\default\global\variables.none.tmpl to be sure. (A) The URL of a bug shouldn't be displayed when viewing a bug report, since it's already available in the address field of the browser. (B) The URL of a bug could be displayed when viewing multiple bugs. It's useful to copy-paste the URL of a bug when viewing multiple ones, for example. (C) The URL of a bug could be displayed on the "Format for printing" page, since this would solve item0. Since (B) and (C) use the same thing, your patches implements the correct behaviour for all three cases. This is ready to go in regarding my point of view if you address the previous issue. :)

Comment on attachment 160892 [details] [diff] [review] bugzilla-208711-v1.02.diff Oh, and it makes sense to make it clickable, to be similar with the URL field and to enable easy copy-pasting.

changes made.

re comment 5, this just purely for citation reasons

Comment on attachment 160904 [details] [diff] [review] bugzilla-208711-v1.03.diff It's not clickable (see comment 5).

Well, yeah, but it would still be nice to open the bugs you're interested in new tabs. Or to copy-paste it in IRC or in an IM window. It's difficult to do either of those if it's not clickable.

AFAIK, almost all URLs in Bugzilla are clickable as well.

cliky too

I am against this change. If the site administrator hasn't customized his header, adding adding a visible link to the long list output seems like a hideous hack to help an engineer identify what bugzilla that list refers to. We don't want to make long list any wordier than it should be -- it already is packed full with data. Most printouts of web pages include URLs in the header anyway. Reopen if you can find good justification for this.

Certain versions of acrobat do not make header/footer with url in it. Certain version of IE, crop the url in the footer. modifing the header to include the whole url does it for all the pages. modifing just this page, is 'too much' for a novice admin to do. this is just for the print bug page. may be we should de discussing placement instead.

I honestly think this has no place in mainline Bugzilla, and should be implemented as a site-specific change; I know it's frustrating to hear this, but it's a trivial template change that can be easily ported, and doesn't bring enough benefit to justify adding it. If you still feel strongly about this, I'd say ask Dave as he has the authority to pronouce a final decision here.

If knowing template toolkit is a requirement to admin bz, then yes. But since the docs for bz don't really get into [% Param('this or that')%] nor do they give a file tree to cross reference 'Format For Printing' -> 'show-multiple.html.tmpl' I don't think it is reasonable to ask an admin to do this type of change. Printouts, by their very nature, are used in contexts outside of bugzilla. Making it imperative to provide ALL the information to the reader, especially the link. It would be analogous to a published paper not having the publisher's info and page numbers.

(In reply to comment #15) > If knowing template toolkit is a requirement to admin bz, then yes. > But since the docs for bz don't really get into [% Param('this or that')%] nor > do they give a file tree to cross reference > 'Format For Printing' -> 'show-multiple.html.tmpl' > > I don't think it is reasonable to ask an admin to do this type of change. Then the docs are lacking, and we should fix them up. This is by all means expected of Bugzilla admins who want to change what the site looks like. TT is a lot easier to learn than Perl. :) That said, the format for printing page really needs a complete overhaul anyway, in my opinion. There's been a lot of data added to the "bug" over the last couple years, and everyone always ignores the long format template when adding stuff to the single bug template.

Comment on attachment 160906 [details] [diff] [review] bugzilla-208711-v1.04.diff Adding URLs is a good idea for users who work from printouts, but we shouldn't display it in the web version of the page, just the print version. Use a print-specific stylesheet with a style rule like the following to get that behavior: a.bug:after { content: " <" attr(href) ">"; } (You'll also have to add class="bug" to bug link anchors.)

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Max, can we find a mentor for this bug?

@jmaher: Max won't answer that as he unCCed from any tickets on 2013‑08‑01 (see user activity)

Still watching this. If you need the patch updated, let me know.