Closed
Bug 825946
Opened 11 years ago
Closed 9 years ago
tracking flags should be cleared when a bug is moved to a product/component where they are not valid
Categories
(bugzilla.mozilla.org :: Extensions, defect, P2)
Tracking
()
RESOLVED
FIXED
People
(Reporter: glob, Assigned: dylan)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
4.11 KB,
patch
|
dkl
:
review+
|
Details | Diff | Splinter Review |
tracking/status flags should be cleared when a bug is moved to a product/component where they are not valid. steps: 1. create a bug in "Core :: Networking: HTTP" 2. set blocking-basecamp --> ? 3. move the bug to "Websites :: Other" the blocking-basecamp field will remain set, and will show up in queries, however the field is hidden from the UI and cannot be unset. the field should have been cleared when the bug's component changed.
Comment 1•11 years ago
|
||
IIRC this actually was this way originally, and that feature got removed because flags were getting accidentally lost when someone moved something somewhere it shouldn't have been moved to.
(In reply to Dave Miller [:justdave] from comment #1) > IIRC this actually was this way originally, and that feature got removed > because flags were getting accidentally lost when someone moved something > somewhere it shouldn't have been moved to. the current behavour for real bugzilla flags is they are cleared when this scenario occurs. i don't think it's unreasonable for the status/tracking/etc "flags" (actually custom fields) to behave the same way.
Comment 3•11 years ago
|
||
yeah, go for it. :) That's what the bug history is for I guess. :)
this impacts all custom fields that we hide (see bug 826777).
Summary: tracking/status flags should be cleared when a bug is moved to a product/component where they are not valid → custom fields hidden by the bmo extension should be cleared when a bug is moved to a product/component where they are not valid
Comment 5•10 years ago
|
||
I am experiencing the same issue with bug 1008321.
this still applies to custom fields managed by the BMO extension, however it's much more visible on the tracking flags fields. updating summary an component.
Component: General → Extensions: TrackingFlags
Summary: custom fields hidden by the bmo extension should be cleared when a bug is moved to a product/component where they are not valid → tracking flags and custom fields hidden by the bmo extension should be cleared when a bug is moved to a product/component where they are not valid
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → dylan
Assignee | ||
Updated•9 years ago
|
Priority: -- → P2
Assignee | ||
Comment 7•9 years ago
|
||
It looks like the fix two changes -- one that clears tracking flags in bug_end_of_update in TrackingFlags extension. The exact way of clearing the custom fields yet eludes me.
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Assignee | ||
Comment 8•9 years ago
|
||
When a tracking flag is no longer applicable, should I generate an activity entry that says the tracking flag was set to ---? That is, removed: value, added: ---?
Flags: needinfo?(dkl)
(In reply to Dylan William Hardison [:dylan] from comment #8) > When a tracking flag is no longer applicable, should I generate an activity > entry that says the tracking flag was set to ---? That is, removed: value, > added: ---? yes (likewise for custom fields).
Flags: needinfo?(dkl)
Assignee | ||
Comment 10•9 years ago
|
||
I think we should split out the custom fields part into another bug, as it is a bit more complicated and the tracking flags part is ready for review, but the custom fields part I'm not happy with. Thoughts?
Flags: needinfo?(glob)
Reporter | ||
Comment 11•9 years ago
|
||
(In reply to Dylan William Hardison [:dylan] from comment #10) > I think we should split out the custom fields part into another bug, as it > is a bit more complicated and the tracking flags part is ready for review, > but the custom fields part I'm not happy with. Thoughts? i'm ok with that.
Flags: needinfo?(glob)
Assignee | ||
Comment 12•9 years ago
|
||
This fixes the tracking flag portion of the problem, and includes a script to bulk-fix the existing problems. Please pay special attention to the bulk script. :-)
Attachment #8597315 -
Flags: review?(dkl)
Assignee | ||
Updated•9 years ago
|
Summary: tracking flags and custom fields hidden by the bmo extension should be cleared when a bug is moved to a product/component where they are not valid → tracking flags should be cleared when a bug is moved to a product/component where they are not valid
Comment 13•9 years ago
|
||
Comment on attachment 8597315 [details] [diff] [review] 825946_1.patch Review of attachment 8597315 [details] [diff] [review]: ----------------------------------------------------------------- Looks/works good in Extension.pm. Just need addition to the fix up script. ::: extensions/TrackingFlags/bin/bug_825946.pl @@ +61,5 @@ > +$dbh->bz_start_transaction(); > +foreach my $tf_bug (@$tf_bugs) { > + my ($bug_id, $tf_id, $product_id, $component_id) = @$tf_bug; > + unless ($visible{$tf_id}{$product_id}{$component_id} || $visible{$tf_id}{$product_id}{ALL}) { > + $dbh->do("DELETE FROM tracking_flags_bugs WHERE tracking_flag_id = ? AND bug_id = ?", undef, $tf_id, $bug_id); You will need to add an insert into bugs_activity showing the removal. Similar to what u do in Extension.pm.
Attachment #8597315 -
Flags: review?(dkl) → review-
Assignee | ||
Comment 14•9 years ago
|
||
With log entries. Testing this more than once is a little "fun", backup tracking_flags_bugs first. :-)
Attachment #8597315 -
Attachment is obsolete: true
Attachment #8602350 -
Flags: review?(dkl)
Comment 15•9 years ago
|
||
Comment on attachment 8602350 [details] [diff] [review] 825946_2.patch Review of attachment 8602350 [details] [diff] [review]: ----------------------------------------------------------------- r=dkl
Attachment #8602350 -
Flags: review?(dkl) → review+
Assignee | ||
Comment 16•9 years ago
|
||
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git ca30cab..379d122 master -> master
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Component: Extensions: TrackingFlags → Extensions
You need to log in
before you can comment on or make changes to this bug.
Description
•