Open Bug 997228 Opened 6 years ago Updated 5 years ago
Renaming flags will destroy bug history for those flag values
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?
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
(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
You need to log in before you can comment on or make changes to this bug.