canmove, Confirmed users
637
edits
BugzillaImprovements: Difference between revisions
→Make More Field Visibilities Configurable Per Product
| (15 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 89: | Line 91: | ||
Bug: too many to list. ;-) | Bug: too many to list. ;-) | ||
Repeating my earlier comment in the "historical data" section, the "new" charts need | 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. | * 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. | * 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 === | ||
| Line 119: | 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 150: | 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 181: | 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 195: | 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 264: | 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 = | ||