Currently, if a product, group, login_name, component, or version is renamed, the bug activity log becomes disjointed. To solve this, we would need to roll through the history whenever doing a rename. The simplest case of this is in cases of a product or group rename (ignoring deletion and resurrection for now) UPDATE bugs_activity SET removed = 'newname' WHERE removed = 'oldname' AND field = getfielded('product') UPDATE bugs_activity SET added = 'newname' WHERE added = 'oldname' AND field = getfielded('product') When a product or group is deleted, we may want to prevent it from being changed further... That's a bit strange, but we could do something like.... UPDATE bugs_activity SET removed = 'DEFUNCT(name)' WHERE removed = 'name' AND field = getfielded('product') UPDATE bugs_activity SET added = 'DEFUNCT(name)' WHERE added = 'name' AND field = getfielded('product') So far, so good (we can debate how to mark the defunct items later)... This should work for email addresses, products, groups, platforms, priorities, etc... For components and versions, this is a bit trickier... say we have a component "foo" of product "a" and a component "foo" of product "b" and we rename a/foo to a/bar while leaving b/foo alone..... We need to UPDATE bugs_activity SET removed ='bar' WHERE removed='foo' AND field = getfieldid('component') AND **this** (ditto for added) Where **this** means that either the next change to product AFTER this entry removed "a" OR (there is no later change to product AND the bug is still in product "a") This is a bit hairy, but only has to be written once and executed rarely. If we do this properly, then the acitvity logs will start to be accurate even through renames and schema changes. This is vital if we want to do good reporting. This requires a new function.... HistoryRename(fieldid, productname, oldname, newname) To rename all the history entries in a particular field. If productname is defined and not "", then the changes will only apply to history entries in the specified product.

This definitely needs to be done, although I'll feel a lot more comfortable about it when we have transactions. I think there should be a column that is on the activity table and gets displayed to the users, that indicates this was a rename and not a normal operation. With the increase in ID-usage recently, and the likelihood of it increasing further to almost every field, this really needs to be a generic solution.

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.