= bug description =
When a bug being followed by the blocker tracking app is reassigned to another component, the component displayed in the tracker is never updated.
This is a pretty big problem because it causes the current blockers to be mis-represented if anything is re-assigned after it is proposed as a blocker.
= bug analysis =
I looked into this a little during F18 and it doesn't appear to be quite as simple as I was hoping. In theory, a full sync should take care of the out-of-date data but that didn't fix the problem and I didn't see anything obviously wrong with the sync code.
It is possible that #325 is interfering with the sync process - even though the hacky fix made it into production, the sync was still crashing on a regular basis.
= fix recommendation =
There are two parts to this bug. * updated information is not being stored in the database * change in component is not triggering an update
Changing the bugzilla query to pull in bugs when the component is updated should be pretty easy - it's the part about new information not making it into the database which is a bigger issue.
We think this was fixed with the field length changes from #325 but this needs to be confirmed before the ticket is closed.
Replying to [comment:2 tflink]:
I've tested this with the current devel version and component changes do trigger an update in the relevant database fields.
Please re-open the ticket if this issue re-appears
Well, this isn't fixed and I'm not sure that it ever could have been. The db update issue was fixed, but the bugzilla query is not set up to detect changes in component.
This should be a pretty simple fix of adding the component change to the bz query we're using.
Fixed in feature/t330-update-component-change and waiting for review:
https://reviewboard-tflink.rhcloud.com/r/26/
fixed in e6d9d4ce42c709cdc553ea06a66c6f084c233a41
merged into develop and master, released in 0.3.0.2 and deployed on stg and prod
Login to comment on this ticket.