997228 - Renaming flags will destroy bug history for those flag values

Status: NEW

(Testing :: General, defect)

Description

[Kyle Lahnakoski [:ekyle]]

Either the bugs must be all changed to the new flag value, or the ETL layer needs to know what names changes happened.

This affects cf_blocking_b2g, which changed from 1.5 to 2.0


On 16/04/2014 10:38 AM, David Lawrence wrote:
> Depends. If we just disable a flag for any new bugs, then the flag and related history remains in the database, just
> not visible for new values. If we delete a flag, then the flag, history, and currently set values is removed. We do
> not normally do that. The other case is if we *rename* a flag's value like we did recently when we moved certain 1.5
> values to 2.0 for B2G, then the set values for bugs reflect the name change, but the recorded history does not. It
> will still have the previous value name. This was a casualty we were willing to accept at the time on the BMO side.
> Does this negatively affect your data collection and metrics?

Comment 1

[David Lawrence [:dkl]]

For reference the bug requesting the value name change from 1.5 to 2.0 was bug 989871. The bug where the code change was tracked to allow this in the Tracking Flags extension was bug 991477 which was pushed live before the value name change. In bug 989871, it was commented that the history (bugs_activity) would unfortunately still have the old value name of 1.5.

Thinking back now, glob, why couldn't we have just updated the added/removed entries in bugs_activity at the same time as well since tracking flags do not share bugs_activity rows as normal flags for?

dkl

Comment 2

[:glob ✱]

(In reply to David Lawrence [:dkl] from comment #1)
> Thinking back now, glob, why couldn't we have just updated the added/removed
> entries in bugs_activity at the same time as well since tracking flags do
> not share bugs_activity rows as normal flags for?

i don't agree that rewriting the bugs_activity table is the correct way to address the ETL issue - we don't touch bugs_activity when other objects are renamed (products, components, users, etc).

appropriate entries are inserted into the audit_log table, which the ETL can then use to track renames.  here's the row from the audit_log table which shows when i renamed the value:

user_id   13647
class     Bugzilla::Extension::TrackingFlags::Flag::Value
object_id 1430
field     value
removed   1.5+
added     2.0+
at_time   2014-04-02 21:52:14

Comment 3

[Andrew Tierney]

Attachment: same problem

Thanks from netdereasi1972.