canmove, Confirmed users
637
edits
BugzillaImprovements: Difference between revisions
→Make More Field Visibilities Configurable Per Product
| (22 intermediate revisions by 3 users not shown) | |||
| Line 13: | Line 13: | ||
* {{bug|373418}} | * {{bug|373418}} | ||
* Note that we are unlikely to add a user preference for this, but we might remember the shown/hidden state in a cookie. -mkanat | * Note that we are unlikely to add a user preference for this, but we might remember the shown/hidden state in a cookie. -mkanat | ||
Another option would be to have some of the key fields, plus the Commit button, as position:fixed at the top of the Window. This means that the general status of the bug is always visible, even if you visited a #comment-id link. And your muscle memory always knows where Commit is, as well. -- gerv | |||
=== Text Area Visible On Filing === | === Text Area Visible On Filing === | ||
| Line 20: | Line 22: | ||
* Essentially fixed in Bugzilla 3.4, because the bug entry page is simpler by default. -- mkanat | * Essentially fixed in Bugzilla 3.4, because the bug entry page is simpler by default. -- mkanat | ||
** Not if your screen is 1024x768 -- gerv. | ** Not if your screen is 1024x768 -- gerv. | ||
*** I see part of the Description field above the fold at that resolution, even including an extra toolbar from a plugin in my browser. That's enough that it can be clicked on. -mkanat | |||
=== Fix Mid-Air Collisions === | === Fix Mid-Air Collisions === | ||
| Line 35: | Line 38: | ||
* Note that this is somewhat difficult and unlikely to happen in any near-term Bugzilla release. -- mkanat | * Note that this is somewhat difficult and unlikely to happen in any near-term Bugzilla release. -- mkanat | ||
** mkanat: can you point me at any technical analysis which has been done on the problem? -- gerv | ** mkanat: can you point me at any technical analysis which has been done on the problem? -- gerv | ||
*** No, but I have a general idea of how it would be implemented, in my mind, if you want to talk about it. I think we should probably be looking at having a Bugzilla::ChangeSet object first (which we need for other things, also) -mkanat | |||
=== Historical Queries === | === Historical Queries === | ||
| Line 57: | Line 61: | ||
I guess that finding out a better way to have "fixed here, but needs fixing somewhere else" would be cool, and support for that in queries. -- axel (endorsed by bsmedberg) | I guess that finding out a better way to have "fixed here, but needs fixing somewhere else" would be cool, and support for that in queries. -- axel (endorsed by bsmedberg) | ||
* There is an existing custom feature on b.m.o., but it is considered inadequate. | * There is an existing custom feature on b.m.o., but it is considered inadequate. (any solution that results in 118 "fixed" keywords and an equal number "verified" keywords is horrible, not to mention the stack of "blocking" flags cluttering up each bug.) | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=bz-branch Bug 55970] - Bugzilla needs to deal better with branches. | * [https://bugzilla.mozilla.org/show_bug.cgi?id=bz-branch Bug 55970] - Bugzilla needs to deal better with branches. | ||
* Despite the WONTFIX I still prefer the simpler [https://bugzilla.mozilla.org/show_bug.cgi?id=336790 Bug 336790] --dveditz | |||
** Of course, as extensively explained in that bug, while that might serve Mozilla's requirements, it would not serve the general requirements of all Bugzilla installations, and it also would not be very flexible once you wanted more and more things per-branch, or if you wanted to say things like "this is the same bug in two different products". -mkanat | |||
(I get the impression the requirements for this are complex! -- gerv) | (I get the impression the requirements for this are complex! -- gerv) | ||
| Line 84: | Line 90: | ||
Bug: too many to list. ;-) | Bug: too many to list. ;-) | ||
Repeating my (dveditz) earlier comment in the "historical data" section, the "new" charts need | |||
* the ability to make datasets public or shared with specific groups (like named queries). I mean user-created datasets, there do seem to be a few public ones I assume created by admins. | |||
* don't show 100's of datasets that the user isn't allowed to use. The clutter hides the ones I'm looking for, the interesting-looking names are a tease, and it's just overall frustrating. Just show me my own datasets, the public ones, and the ones that have been shared with me. | |||
** this one is [https://bugzilla.mozilla.org/show_bug.cgi?id=389396 bug 389396] | |||
=== Remove Severity Field === | === Remove Severity Field === | ||
The "blocker" and "enhancement" severities actually mean something to us currently, but everything inbetween is basically "a bug of some sort" without much actionable difference. I think we should instead have a "blocking trunk" flag which we use to mark bugs which should close the mozilla-central tree, and an enhancement keyword to mark enhancement bugs. -- bsmedberg. | * The "blocker" and "enhancement" severities actually mean something to us currently, but everything inbetween is basically "a bug of some sort" without much actionable difference. I think we should instead have a "blocking trunk" flag which we use to mark bugs which should close the mozilla-central tree, and an enhancement keyword to mark enhancement bugs. -- bsmedberg. | ||
**The Bugzilla project definitely uses this field -- mkanat. | |||
The Bugzilla project definitely uses this field -- mkanat. | * We should still split "enhancement" from "defects" rather than lumping them in the same severity field. In particular the current scheme means we cannot assign "severity" (importance?) to an enhancement, which can range from a minor polish thing to major new functionality. --dveditz | ||
** {{bug|9412}} | |||
=== Remove Platform/Hardware and OS === | === Remove Platform/Hardware and OS === | ||
| Line 110: | Line 122: | ||
No, it wouldn't, but it would require a fair bit of re-working that we're in-progress on, in terms of architecture, in Bugzilla. -mkanat | No, it wouldn't, but it would require a fair bit of re-working that we're in-progress on, in terms of architecture, in Bugzilla. -mkanat | ||
The ''presence'' of a field could be easily customized in each site's local CSS if we had a few tweaks to the bug layout: | |||
* each item must have an id. A lot of 'em do, but some the field itself has an id but its label does not, making it hard to style them as a group (e.g. target milestone and many others). | |||
* The body should have a product class in addition to the existing component class, that is "bz_product_Core" alongside "bz_component_JavaScript_Engine" <br>(dveditz) | |||
===Integrate Comments Into Bug History=== | ===Integrate Comments Into Bug History=== | ||
If I'm reading a bug report for the first time, and trying to familiarize myself with what has happened on the bug so far, it's hard to know what actions in the bug comments correspond with what action in the bug history (renaming, changing component, change of status, etc.). If you could incorporate bug history and bug comments[1], it would make it much easier to put the bug history and comments into context. -- Chris Ilias. (zomg +1 -- beltzner) | If I'm reading a bug report for the first time, and trying to familiarize myself with what has happened on the bug so far, it's hard to know what actions in the bug comments correspond with what action in the bug history (renaming, changing component, change of status, etc.). If you could incorporate bug history and bug comments[1], it would make it much easier to put the bug history and comments into context. -- Chris Ilias. (zomg +1 -- beltzner) (+1 -- dveditz, can't tell you the amount of time I spend on the history page trying to match state changes to explanatory comments) | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=11368 Bug 11368] - Move all bug activity onto main bug screen. | * [https://bugzilla.mozilla.org/show_bug.cgi?id=11368 Bug 11368] - Move all bug activity onto main bug screen. | ||
| Line 141: | Line 157: | ||
There have been several calls for greater linkage between Bugzilla and Hg, although there are different views about the appropriate extent of the scope, and the UI, for such linkage. The problem they are attempting to solve is easily finding the appropriate checkins for the bug. | There have been several calls for greater linkage between Bugzilla and Hg, although there are different views about the appropriate extent of the scope, and the UI, for such linkage. The problem they are attempting to solve is easily finding the appropriate checkins for the bug. | ||
===Editable Description/Summarization=== | |||
Sometimes it takes a while to hone in on what a bug really is, with several of the initial comments being overbroad or over-vague. Sometimes a bug is "mostly" fixed but left open, but you have to find comment 87 to figure out what the bug is still open for. It would be nice if a bug could be resummarized, and if it is the new summary would appear above the initial comment 0. Creating and editing this field would be restricted to the editbugs group, and if one is added it might have to be somewhat visually set off from the stream of comments starting with #c0. --dveditz | |||
A specific Bugzilla feature for this appears to be WONTFIX because supposedly there's enough support for this as a customization. [https://bugzilla.mozilla.org/show_bug.cgi?id=99240#c6 bug 99240]: | |||
::Since Bugzilla 3.1.2, you can create a custom textarea and then paste the bug description in it. We won't implement a specific "long summary" field as you are free to create one yourself when you need it. | |||
I'm not sure who the "you" is there, it certainly doesn't seem to be me. The same concept was also requested in [https://bugzilla.mozilla.org/show_bug.cgi?id=262087 bug 262087] | |||
== Accounts == | == Accounts == | ||
| Line 172: | Line 197: | ||
Access-Control-Allow-Origin header support for cross-site XML-RPC - asutherland. | Access-Control-Allow-Origin header support for cross-site XML-RPC - asutherland. | ||
* for public (no cookies) data only, I hope --dveditz | |||
=== Bounce Tracking === | === Bounce Tracking === | ||
| Line 186: | Line 212: | ||
** I think what Axel wanted was just a way of getting the tabular data in a programmatic format, which we can already do (CSV). -mkanat | ** I think what Axel wanted was just a way of getting the tabular data in a programmatic format, which we can already do (CSV). -mkanat | ||
*** Yes, this is neat. Looked at reports and didn't understand the UI before, but now I get it. Including this into a JSON API would be nice for consistency. -Axel | *** Yes, this is neat. Looked at reports and didn't understand the UI before, but now I get it. Including this into a JSON API would be nice for consistency. -Axel | ||
*** Yeah, that's what I wanted. Could do with support for grouping by flag/requests/requestee (and "fixed-in" if ever BMO gets to use that) but otherwise covers what I was thinking of. | |||
===Search=== | ===Search=== | ||
| Line 255: | Line 282: | ||
===Default-Uncheck Flag Assignment Acceptance=== | ===Default-Uncheck Flag Assignment Acceptance=== | ||
b.m.o. has a local customization allowing people to define whether they are accepting flag assignments (e.g. review requests) for each flag. These should be default-unchecked rather than default-checked. Perhaps we could also have a flag day (groan) where we uncheck everyone's flags, then check them again for all people who have plussed a flag of that type in the past. This would be a good first guess at the set of people who actually accept such requests. | * b.m.o. has a local customization allowing people to define whether they are accepting flag assignments (e.g. review requests) for each flag. These should be default-unchecked rather than default-checked. Perhaps we could also have a flag day (groan) where we uncheck everyone's flags, then check them again for all people who have plussed a flag of that type in the past. This would be a good first guess at the set of people who actually accept such requests. | ||
** This wouldn't work, because sometimes I want to request review from somebody who's not a reviewer--say, somebody who can tell me whether or not their problem is fixed, or some expert in some area that I'm working on, and if their flags defaulted to off, then I couldn't ask them. -mkanat | |||
Later, this acceptance data should be tied into the autocomplete system. | * Later, this acceptance data should be tied into the autocomplete system. | ||
= Bugs = | = Bugs = | ||
* Can't put an alias in a bookmarkable template. | * Can't put an alias in a bookmarkable template. | ||
* Add Core to the pretty picker {{bug|384603}} | |||
= Already Implemented = | = Already Implemented = | ||