616987 - Search By Change History not working after a change of fields values for status, resolution, severity or priority.

Status: NEW

(Bugzilla :: Query/Bug List, defect)

Description

[nboist]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: 

If I change one of the values in Administration => Fields Values, I'll need to use the original value when using "Search By Change History" for status, resolution, severity or priority. Custom (changed) value can't be used.

Reproducible: Always

Steps to Reproduce:
1.Administration => Field Values => Status
2.Modifiy 'ASSIGNED' to 'ASSIGN' for example
3.Go to Advanced Search and use 'Search by change history' to search for bugs with status 'ASSIGN'
Actual Results:  
There are no bugs with modified status value (ASSIGN).


Expected Results:  
We should get all the bugs which value was 'ASSIGNED' and now is 'ASSIGN'

You have to use original value (ASSIGNED) to acces those bugs.

Comment 1

[nboist]

Table 'bugs_activity' is not updated when a field value is changed.
Is it normal?

Comment 2

[Frédéric Buclin]

(In reply to comment #1)
> Table 'bugs_activity' is not updated when a field value is changed.
> Is it normal?

Yes. Technically, we are not moving the bug to another status/resolution/priority/..., but only renaming the field value.

Also, the bugs_activity table contains hardcoded strings, and so doesn't rename old strings when renaming one. Not sure we will fix this problem, though.

Comment 3

[nboist]

Wouldn't it be better to use ids for status/resolution/priority/...
I don't understand why do we have values used for these fields in 'bugs' and 'bugs_activity' (and maybe somewhere else in database).
The use of reference is always better isn't it? Faster, less memory needed, easier to customize for internalization purpose.

Comment 4

[Frédéric Buclin]

(In reply to comment #3)
> Wouldn't it be better to use ids for status/resolution/priority/...

Of course it would, for all the reasons you mentioned. One of the reasons to store strings rather than IDs, AFAIK, was to prevent dataloss when an obsolete value was deleted. Also, this implementation exists since the early days of Bugzilla, when such problems were not the main priority of developers (almost everything was static, with no way to add/edit/remove values. Things became dynamic since Bugzilla 2.20 only).