tracking flags should be cleared when a bug is moved to a product/component where they are not valid

RESOLVED FIXED

Status

()

bugzilla.mozilla.org
Extensions: TrackingFlags
P2
normal
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: glob, Assigned: dylan)

Tracking

(Blocks: 1 bug)

Production

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 2

6 years ago
(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. :)
(Reporter)

Comment 4

6 years ago
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.
(Reporter)

Comment 6

4 years ago
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

3 years ago
Assignee: nobody → dylan
(Assignee)

Updated

3 years ago
Priority: -- → P2
(Assignee)

Comment 7

3 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

3 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)
(Reporter)

Comment 9

3 years ago
(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

3 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

3 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

3 years ago
Created attachment 8597315 [details] [diff] [review]
825946_1.patch

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

3 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
(Assignee)

Updated

3 years ago
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-
(Assignee)

Comment 14

3 years ago
Created attachment 8602350 [details] [diff] [review]
825946_2.patch

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+
(Assignee)

Comment 16

3 years ago
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   ca30cab..379d122  master -> master
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.