TracAccountManager may corrupt ticket_change entries where field = 'comment' when changing a user ID in ticket_change entries where field = 'cc'
|Reported by:||anonymous||Owned by:||hasienda|
TracAccountManager 0.5dev-r13381 with all *IdChanger Module enabled may corrupt ticket_change entries when changing a user ID, leading to Trac detected an internal error: ValueError: invalid literal for int() with base 10: 'newuser'. This does not apply to all ticket_changes, but to isolated cc field changes only.
Sample entries before change:
sqlite> select * from ticket_change where ticket = 1364 limit 4; 1364|1389367881566265|someuser|cc|newuser|olduser 1364|1389367881566265|someuser|comment|1| 1364|1389367939770929|someuser|cc|olduser|newuser 1364|1389367939770929|someuser|comment|2|
As can be seen, someuser was unsure as to what username should be in cc (which by the way is the reason i updated the account manager from stable to trunk to get rid of olduser entirely using this cool new feature ).
Unfortunately, the corrupt entries after the change lead to exceptions when rendering the ticket:
sqlite> select * from ticket_change where ticket = 1364 limit 4; 1364|1389367881566265|someuser|cc|newuser|newuser 1364|1389367881566265|someuser|comment|1|newuser 1364|1389367939770929|someuser|cc|newuser|newuser 1364|1389367939770929|someuser|comment|newuser|
its the last line 1364|1389367939770929|someuser|comment|newuser| that trac cannot render, it should have stayed 1364|1389367939770929|someuser|comment|2|
The other lines also seem to be wrong, but they do not lead to an exception, just read strange when rendered.
I think the best option is to leave ticket_change where field in ('cc','comment') unchanged, my guess is that it's ok to show the olduser in the cc field change history, while the important thing is to change the actual cc field in the ticket.