On 10/25/07, Danek Duvall <[EMAIL PROTECTED]> wrote: > Perhaps one of you bugzilla folks knows this ... on the buglist.cgi page, I > have to click on the teeny little link that's the bugid, despite the fact > that each line highlights as I mouse over it, and the pointer changes to > indicate that I should be able to click anywhere in that line. > > Is that possible to implement with whatever normal customizations one does > to bugzilla, or is that something where bugzilla has to be modified?
Two links to read (cheating) and then a longer description http://www.bugzilla.org/docs/3.0/html/cust-templates.html http://mxr.landfill.bugzilla.org/bugzilla3.0.x/source/template/en/default/list/table.html.tmpl The second is to the relevant file. A longer description of how to find what to change: 1. load a buglist (or whichever thing bothers you today) and view source. 2. look for a unique string, "first-child" looked good to me. 3. load http://mxr.landfill.bugzilla.org/bugzilla3.0.x/source/ 4. search for first-child 4' http://mxr.landfill.bugzilla.org/bugzilla3.0.x/search?find=%2F&string=first-child 5. pick the one that's not CSS, :) -- OK, that's cheating, pick the one that matches the content you saw in view-source :). 5' http://mxr.landfill.bugzilla.org/bugzilla3.0.x/source/template/en/default/list/table.html.tmpl 6. load http://www.bugzilla.org/docs/3.0/html/customization.html 7. read 6.2. Template Customization http://www.bugzilla.org/docs/3.0/html/cust-templates.html 8. In 6.2.2. Choosing a Customization Method http://www.bugzilla.org/docs/3.0/html/cust-templates.html#template-method you have a choice. I'll assume The second method is to copy the templates to be modified into a mirrored directory structure under template/en/custom. Templates in this directory structure automatically override any identically-named and identically-located templates in the default directory. See footnote [1]. 9. cp template/en/default/list/table.html.tmpl template/en/custom/list/table.html.tmpl 10. load template/en/custom/list/table.html.tmpl 182 <td class="first-child"> 183 <a name="b[% bug.bug_id %]" 184 href="show_bug.cgi?id=[% bug.bug_id %]">[% bug.bug_id %]</a> 185 <span style="display: none">[%+ '[SEC]' IF bug.secure_mode %]</span> 186 </td> ... 189 <td [% 'style="white-space: nowrap"' IF NOT abbrev.$column.wrap %]> + <a name="b[% bug.bug_id %]" + href="show_bug.cgi?id=[% bug.bug_id %]"> 190 202 + </a> 203 </td> 204 [% END %] 11. save 12. from the instructions: It is required that you run ./checksetup.pl after creating a new template in the custom directory. Failure to do so will raise an incomprehensible error message. 13. ./checksetup.pl It's that simple. However, I think an explanation as to why this wasn't done might be in order. When Bugzilla was originally developed, CSS was not well established (I'm not even sure if it existed at all, I only have history back to Bugzilla 2.0, not 1.0), which means having underlines across the entire row would make reading things harder. The CSS hover/cursor stuff is of course much newer. But why not just globally implement this? Imagine you have a query that returns thousands of results. A nice feature would be drill down searching, where clicking on a field (e.g., component, OS, version, reporter, assignee) would restrict the query to just that value. Also, the email fields (reporter, assignee, qa contact) would be more expected as mailto: links (yes, it doesn't do that, but it could), and when someone gets around to adding the url field, that too would be more expected as a link to its value instead of just linking to the bug. Note: I think there are other ways to implement the above, so it's likely that just upstreaming this is right, but it'd be nice if people kept this in mind before they make customizations. > And if it's the former, Stephen, could you do that, or show me where to go > poking to do it? It's really frustrating me. (Or perhaps we should just > have super-long bugids so they're easier to click. ;-) Given Sun's bug numbers tend to have 7+ digits, I think that's easier to achieve (mozilla.org's only have 6, but when I started there they had 4, and those were easy enough). And this is of course fairly important to keep in mind, you only get a couple of small bug numbers, they'll quickly disappear. However the other fields (e.g. summary if you're unlucky) can end up being very narrow. So, it's better for muscle memory to train people to click the bug number (which is always the first field). footnote [1]: I'm not actually sure which approach is best, in the end either way will require some care when you upgrade, note that upgrades should of course be staged with a copy of the file system and a copy of the database, if you use in place, you'll clearly see merge conflicts and know what changes you need to resolve. If you click CVS Log from that file, you'll see: http://bonsai.mozilla.org/cvslog.cgi?file=/mozilla/webtools/bugzilla/template/en/default/list/table.html.tmpl&rev=BUGZILLA-3_0-BRANCH&mark=1.32.2.1 Essentially, that file hasn't changed in over a year (except for a small change, made by me, oddly enough). footnote [2]: Perhaps more interesting 1.32 lpsolit%gmail.com 2006-10-20 08:50 Bug 357396: Mass-change broken due to the undesired onClick="document.location='show_bug.cgi?id=XXX'" - Patch by Frédéric Buclin <[EMAIL PROTECTED]> r=wurblzap a=myk If you click on 1.32, you'll see: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=table.html.tmpl&branch=BUGZILLA-3_0-BRANCH&root=/cvsroot&subdir=/mozilla/webtools/bugzilla/template/en/default/list&command=DIFF_FRAMESET&rev1=1.31&rev2=1.32 Which is basically reverting javascript which implemented what you (danek) asked for. Now's a very good time to read the bug, https://bugzilla.mozilla.org/show_bug.cgi?id=357396 Anyway, it's definitely a good idea to review change history before deciding what or how to implement things. In this case, it's clear that if you choose "Change several bugs at once", you'll get a checkbox in the row, and you don't want clicking the checkbox to take you to the bug <g> (but if you haven't used Bugzilla a lot, you wouldn't know this). This already shows one reason not to make the change: there will be at least one element that must not behave the way you wanted to make the row behave. Sorry for the delay, I meant to reply yesterday but got sleepy. _______________________________________________ tools-discuss mailing list [email protected]
