369489 - Link for "Target Milestone:" goes to wrong place on new bug page (remove milestoneurl)

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Mark Clements]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: 

On the 'edit bug' page, the "Target milestone" field is made into a link to your URL describing the milestones (if such a link is defined).

However, on the 'new bug' page (where you really need the reminder!) the link always goes to the "Bug life cycle" help page, which makes no mention of milestones at all.

The behaviour should be consistent, and the link should always go to your URL if you specified one, and not be a link at all if it doesn't (though see comments on bug 61634 for some alternative options for this second case).

Reproducible: Always

Comment 1

[Max Kanat-Alexander]

Okay, here's what I think about this:

The label "Target Milestone" should always go to a description of the field on fields.html, for consistency with how all the other label links work.

If there is a milestoneurl specified, then there should be an [about] link next to the target milestone field that goes to the milestoneurl. That would make the milestoneurl information much more discoverable.

Comment 2

[Max Kanat-Alexander]

Actually, instead of this, I'm just going to remove the milestoneurl feature. I don't know of any organization that uses it in any significant fashion with the default templates of Bugzilla. I think it's mostly just a leftover from old Mozilla processes.

Comment 3

[Max Kanat-Alexander]

Attachment: v1

Okay, here's a patch that removes milestoneurl and adds docs for Target Milestone to fields.html.

Comment 4

[Mark Clements]

(In reply to comment #2)
> Actually, instead of this, I'm just going to remove the milestoneurl feature. I
> don't know of any organization that uses it in any significant fashion with the
> default templates of Bugzilla. I think it's mostly just a leftover from old
> Mozilla processes.

Please don't do this - we use it!  

The point about consistency made in comment 1 is fair enough, and the suggestion of an 'about' link that goes to the Milestone URL would be fine, but please don't remove this feature altogether!

(An alternative solution would be to handle it like components, and allow the descriptions to be entered directly into Bugzilla, and displayed on the enter/edit bug pages in the same way.)

Comment 5

[Max Kanat-Alexander]

(In reply to comment #4)
> Please don't do this - we use it!  

  Hmm. What do you use it for?

Comment 6

[Mark Clements]

As a quick lookup of what the milestones mean.  We have a page on our wiki for each project, indicating what the milestones refer to, and I often need to check the appropriate page when filing new bugs, particularly if it's not a project I'm deeply involved with, and having a direct link to it is an extremely useful time-saver.  I also know that other people in our organisation make use of this feature too, as we have discussed it on more than one occasion.

It would be even better if Bugzilla handled all this natively (like it does for component descriptions), as the pages sometimes get out of date, but certainly the current method is better than no explanation of these items at all.

Comment 7

[Max Kanat-Alexander]

  Hmm. Well, possibly it could be moved into an extension.

  Though since the link is on your Wiki, the engineers could also just *know* that that's the TM description location, right? Also, you can add HTML to Product descriptions, so you could link to it in the Product description, if you wanted.

Comment 8

[Mark Clements]

Well, we have quite a number of products, so that's a lot URLs to remember!  We could set up an index I guess, but then it's several clicks to get to the information.

I didn't realise you could add HTML to the product description, so perhaps that is a way round the problem.

Perhaps our situation is unusual, because our milestones are not just a list of version numbers, but things like 'January sign-off' or 'Client testing, phase 2'.

In my opinion, the 'correct' solution would be to add a description field to the milestones table, so they work like components.  In general, milestones and components are the items that can cause the most confusion - more so than classifications/products, for example.  The text we enter for those doesn't often add much (e.g. "Product Foo", "This product contains all bugs relating to Product Foo.") whereas milestones and components have very specific and important distinctions which could do with an explanation.  Therefore, if this is something that is better suited to an extension, then product/classification descriptions should probably go the same way.

Comment 9

[Frédéric Buclin]

(In reply to comment #8)
> Therefore, if this
> is something that is better suited to an extension, then product/classification
> descriptions should probably go the same way.

You cannot compare product and component descriptions with milestones descriptions. You *have to* choose a product and component when reporting a bug, and so you need to know about them in all cases. But you *never have to* set the milestone; you can ignore it when reporting a bug. Only people who knows what the milestone means should set it.

Comment 10

[Mark Clements]

I guess that's true.  In our case the descriptions for classifications/products are not very useful, but I can see why other people would find them useful.

> Only people who knows what the milestone means should set it.

Well, that's kind of true, but not really relevant in our situation.  We run Bugzilla in almost the opposite way to Mozilla - we have a small group of people working on many products at the same time, and bugs only get into Bugzilla via the developers, therefore the link serves as a valuable reminder to the developer about where the bug should be put.  We don't have the Mozilla situation of many, many reporters, most of whom are not developers and who therefore have no right to set milestones.  In your situation your assertion (that only people who know what the milestone means should set it) is an argument for not linking, but in ours (where everyone knows what the milestone means, but may not be able to remember the details off-hand) it is not, I'm afraid.

Comment 11

[Max Kanat-Alexander]

I think an extension or modifying the production description might be a good solution in your case, Mark. My concern is that we're supporting this feature upstream when in reality very few organizations will actually be using it (it is, after all, pretty much entirely hidden in some random secret location--the label of Target Milestone on one or two pages).

Comment 12

[Mark Clements]

Personally, the solution I would like to see is to add allow a description field for all list fields (including priority/platform/etc. plus any user-defined fields) so all items in all lists can be suitable documented, and then to auto generate fields.html (or perhaps make that an index page linking to separate pages for individual fields).  You could then have a 'help' link of some sort (e.g. a discreet question mark) next to each field that links directly to the correct location.

I am aware that this is a lot of work and perhaps over-kill for other users, I'm just suggesting it as the solution that would suit our company best.

I am also aware of the burden of supporting up-stream users, and can confirm that using a link in the description (now that I am aware that it allows HTML) would be a workable solution for our use case.  

If there are lots of other users like us then it would be worth considering the above implementation suggestion.  If we have a somewhat unusual use-case for this kind of information then I agree that it is not worth you supporting it.

Comment 13

[Max Kanat-Alexander]

Actually, once bug 529201 is done, I'd be interested in supporting descriptions for every global select field, and then *maybe* for per-product select fields after that. But that would be a separate bug.

Comment 14

[Frédéric Buclin]

Wow, I hope you are not suggesting to have a description field for each *value*. This would be more confusing than helpful. When you add "Windows 7" as OS, it's self-explicit. When you add "Firefox 3.5.5" as Version, it's self-explicit, etc... Admin would quickly give up providing descriptions for everything, I'm pretty sure.

Comment 15

[Max Kanat-Alexander]

(In reply to comment #14)
> Wow, I hope you are not suggesting to have a description field for each
> *value*. This would be more confusing than helpful. When you add "Windows 7" as
> OS, it's self-explicit. When you add "Firefox 3.5.5" as Version, it's
> self-explicit, etc... Admin would quickly give up providing descriptions for
> everything, I'm pretty sure.

  Maybe, maybe not. In any case, descriptions for some fields are valuable, like bug_severity. We can discuss it in another bug some time.

Comment 16

[Mark Clements]

(In reply to comment #14)
> Wow, I hope you are not suggesting to have a description field for each
> *value*. This would be more confusing than helpful. When you add "Windows 7" as
> OS, it's self-explicit. When you add "Firefox 3.5.5" as Version, it's
> self-explicit, etc... Admin would quickly give up providing descriptions for
> everything, I'm pretty sure.

That is what I am suggesting, however it is (as you say) not relevant to all fields.  If a field doesn't warrant a description, then simply don't give it one.  

However, what may be obvious in one scenario might not be obvious in another.  For example, if you have a lot of non-techy users and all they know is "I'm using Windows" then you may need a bit of description with a little more info to help them figure out which version to use (and those instructions may be different for Mac users).  Or you may want some instructions to the reporter, e.g. "Only for original Windows 7 release - if you are using SP1/SP2 you should select the appropriate alternative" or "We don't officially support Windows 7 yet, so your bug is unlikely to be fixed very quickly".

The point is that you can use them or not as you see fit, but that just because you can't see a point, it doesn't mean that other people won't find a use for them.

Comment 17

[Frédéric Buclin]

Comment on attachment 412735 [details] [diff] [review]
v1

>Index: Bugzilla/Install/DB.pm

>+    $dbh->bz_drop_column('products', 'milestoneurl');

You must also remove

    # The products table lacked sensible defaults.
    $dbh->bz_alter_column('products', 'milestoneurl',
                          {TYPE => 'TINYTEXT', NOTNULL => 1, DEFAULT => "''"});

at line 462, else checksetup.pl crashes the 2nd time you run it, because this column no longer exists:

Not a reference at Bugzilla/DB/Schema.pm line 2623.
 at Bugzilla/DB/Schema.pm line 2623
        Bugzilla::DB::Schema::columns_equal('Bugzilla::DB::Schema::Pg=HASH(0xafa0e88)', undef, 'HASH(0xb1c9f20)') called at Bugzilla/DB.pm line 527
        Bugzilla::DB::bz_alter_column('Bugzilla::DB::Pg=HASH(0xaf90058)', 'products', 'milestoneurl', 'HASH(0xb1c9f20)') called at Bugzilla/Install/DB.pm line 462
        Bugzilla::Install::DB::update_table_definitions('HASH(0x9562358)') called at ./checksetup.pl line 192


r=LpSolit with this fix on checkin.

Comment 18

[Max Kanat-Alexander]

Okay. I'm actually going to hold off until the "document all fields" patch is checked in, because these conflict and that one is much larger.

Comment 19

[Max Kanat-Alexander]

Okay, I checked in everything except for fields.html.tmpl.

Checking in editproducts.cgi;
/cvsroot/mozilla/webtools/bugzilla/editproducts.cgi,v  <--  editproducts.cgi
new revision: 1.153; previous revision: 1.152
done
Checking in Bugzilla/Bug.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v  <--  Bug.pm
new revision: 1.305; previous revision: 1.304
done
Checking in Bugzilla/Product.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Product.pm,v  <--  Product.pm
new revision: 1.43; previous revision: 1.42
done
Checking in Bugzilla/DB/Schema.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB/Schema.pm,v  <--  Schema.pm
new revision: 1.127; previous revision: 1.126
done
Checking in Bugzilla/Install/DB.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/DB.pm,v  <--  DB.pm
new revision: 1.79; previous revision: 1.78
done
Checking in template/en/default/admin/products/edit-common.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/products/edit-common.html.tmpl,v  <--  edit-common.html.tmpl
new revision: 1.12; previous revision: 1.11
done
Checking in template/en/default/admin/products/updated.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/products/updated.html.tmpl,v  <--  updated.html.tmpl
new revision: 1.10; previous revision: 1.9
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--  edit.html.tmpl
new revision: 1.171; previous revision: 1.170
done