1220070 - component rename lacks appropriate entry in bugs_activity table

Status: UNCONFIRMED

(Bugzilla :: Bugzilla-General, defect)

Description

[Andreas Bader]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; InfoPath.3; rv:11.0) like Gecko

Steps to reproduce:

Change the name of a component in the Administration perspective that already has open bugs assigned to it. Let's assume we change the name from 'oldComponentName' to 'newComponentName'.


Actual results:

The table bugs_activity does not reflect this change in the component name when checking the entries of field_id = 15 of bugs assigned to the component that was just renamed.


Expected results:

Bugs_activity table seems to store the real component names in the fields "added", "removed" instead of the component_id.
Thus I would expect that renaming a component leads to an entry for field_id = 15 with "added" = 'newComponentName' and "removed" = 'oldComponentName' to reflect the renaming. (a)

Having the component_id being stored instead of the component name would also solve the problem and would be consistent with the normalized component data storage in table BUGS and COMPONENTS. (b)

Introducing Versions for components as suggested in Bug 313355 might solve the issue as well. (c)

The current behavior makes its practically impossible to caluclate the historical number of open bugs of a certain component at a cetain point in time in the past in a correct way. Thus I would vote to thrive for a quick solution e.g. (a).

Thx and best regards,
Andreas

Comment 1

[Frédéric Buclin]

The bugs_activity table contains changes which were made at the time they were made, with field values defined at that time. Some people suggested to use the value ID instead of the value name, so that renaming a product, a component or any other field value is correctly propagated, but problems occur once a field value (e.g. a product or a component) is deleted. Data integrity would suddenly be broken and deleted values would no longer be displayed. Keeping the original values prevents deletions from being a problem, though it may generate some other troubles, such as bug 326236.

Comment 2

[Andreas Bader]

Can the renaming of a component be considered a logical move of all related bugs from the old component name to a component with the new name?
If so I suggest to add a change event in bugs_activity table that reflects this change (field_id = 15 with "added" = 'newComponentName' and "removed" = 'oldComponentName').