Context Navigation

Changes between Initial Version and Version 1 of Ticket #2045, comment 27

initial	v1
1		For the sake of consistency, I think it would be nice to have tickets in the assigned state whenever they have an owner. The issue has been raised numerous times in various tickets and on the mailing list ~~that many users find it confusing that a ticket can be in the new state and yet have an owner. This is confusing because we~~ say the ticket is //assigned to// the owner (see #8484).
	1	For the sake of consistency, I think it would be nice to have tickets in the assigned state whenever they have an owner. The issue has been raised numerous times in various tickets and on the mailing list, that many users find it confusing that a ticket can be in the new state and yet have an owner. This is confusing because we often say the ticket is //assigned to// the owner (see #8484).
2	2
3	3	I'm inclined to tackle this issue in a different ticket, and need to understand the constraint described in TracWorkflow that //There are a couple of hard-coded constraints to the workflow. In particular, tickets are created with status `new`, and tickets are expected to have a `closed` state.// I'd just want to make sure that having a ticket start in the `assigned` state doesn't break any of the internals of Trac. Most likely it could cause issues for plugins that are mining the `ticket_change` table for state transitions (e.g. it looks like the th:TimeVisualizerPlugin is doing this), so the change should probably be made on a major release.