Closed Bug 163643 Opened 22 years ago Closed 14 years ago

Maintain integrity of bugs_activity during renames and deletions

Categories

(Bugzilla :: Administration, task, P3)

2.17

Tracking

()

RESOLVED DUPLICATE of bug 100090

People

(Reporter: bugreport, Assigned: bugreport)

References

Details

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.
Status: NEW → ASSIGNED
Depends on: 157756
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.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Summary: Maintain integrity of bugs_actitivity during renames and deletions → Maintain integrity of bugs_activity during renames and deletions
Target Milestone: Bugzilla 2.22 → ---
QA Contact: mattyt-bugzilla → default-qa
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.