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)

Production
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: glob, Assigned: dylan)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

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.
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.
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
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: nobody → dylan
Priority: -- → P2
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
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)
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)
(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)
Attached patch 825946_1.patch (obsolete) — Splinter Review
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)
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
Blocks: 1158209
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-
Attached patch 825946_2.patchSplinter Review
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 on attachment 8602350 [details] [diff] [review]
825946_2.patch

Review of attachment 8602350 [details] [diff] [review]:
-----------------------------------------------------------------

r=dkl
Attachment #8602350 - Flags: review?(dkl) → review+
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   ca30cab..379d122  master -> master
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Component: Extensions: TrackingFlags → Extensions
You need to log in before you can comment on or make changes to this bug.