Open
Bug 96616
Opened 23 years ago
Updated 11 years ago
Hide the UNCONFIRMED state if no products use it
Categories
(Bugzilla :: Query/Bug List, enhancement, P3)
Tracking
()
NEW
People
(Reporter: roni_abusch, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
patch
|
mkanat
:
review-
|
Details | Diff | Splinter Review |
In our installation of Bugzilla, we do not use the UNCONFIRMED state. There is
no special problem with this, but we still can see it in the query page. Is
there a way to hide it?
Comment 1•23 years ago
|
||
I'm doing something similar for resolutions over at bug #94534. My current
policy is that it appears on the query page if it's active (to avoid "where is
it?" questions) or it's in the database.
At the moment statuses aren't customised (bug #37613), but even while they're
hardcoded, the UNCONFIRMED status should still follow the same rules and not
appear if it's not used for any products and is not on any bugs.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.16
Comment 2•23 years ago
|
||
Moving to new Bugzilla product ...
Assignee: justdave → endico
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: Bugzilla 2.12 → 2.10
Comment 4•23 years ago
|
||
This should come free as a part of an implementation of customised statuses (bug
#101179).
Comment 5•23 years ago
|
||
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut. Thus this is being retargetted at 2.18. If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Updated•23 years ago
|
Depends on: bz-custstat
Comment 6•23 years ago
|
||
I'll do that as a part of customised statuses.
Assignee: endico → matty
URL: http://http://
Updated•23 years ago
|
Status: NEW → ASSIGNED
Updated•21 years ago
|
OS: Windows 2000 → All
Hardware: PC → All
Updated•21 years ago
|
Severity: minor → enhancement
Comment 7•21 years ago
|
||
Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18.
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comment 8•20 years ago
|
||
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged
enhancement that hasn't already landed is being pushed out. If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•15 years ago
|
Assignee: matty_is_a_geek → query-and-buglist
Status: ASSIGNED → NEW
Here is a simple little trick to strip out UNCONFIRMED if there are NO active products that use it. Should be all that is needed, since UNCONFIRMED doesn't appear to be injected at any point.
Attachment #512798 -
Flags: review?(mkanat)
Updated•14 years ago
|
Summary: Hiding the UNCONFIRMED state → Hide the UNCONFIRMED state if no products use it
Comment 10•14 years ago
|
||
Comment on attachment 512798 [details] [diff] [review]
Code Patch Ver 1
This is not the right fix. What we need to do is to not hardcode UNCONFIRMED anymore.
Comment 11•14 years ago
|
||
Comment on attachment 512798 [details] [diff] [review]
Code Patch Ver 1
Ah, no, removing it from get_all isn't the right solution--I think that you want some frontend solution instead.
Also, why not just tell people to disable the unconfirmed status itself in Field Values (perhaps we don't allow that)?
Attachment #512798 -
Flags: review?(mkanat) → review-
Comment 12•14 years ago
|
||
(In reply to comment #11)
> Ah, no, removing it from get_all isn't the right solution--I think that you
> want some frontend solution instead.
I don't want a front end solution, it could touch too many places. If UNCONFIRMED isn't used anywhere, then it shouldn't be listed as a valid status.
> Also, why not just tell people to disable the unconfirmed status itself in
> Field Values (perhaps we don't allow that)?
Unconfirmed cannot be disabled:
"Enabled for bugs: This value is non-deletable and cannot be disabled. "
You need to log in
before you can comment on or make changes to this bug.
Description
•