Essentially make the timeline code dumb about ticket states, and leave it up to the workflow to tell the timeline what to do. A new operation like note_in_timeline(sent to qa) might work. For i18n support, keep the default workflow words in the localization files and refer to them using an identifier, such as note_in_timeline(i18n:created). Not perfect, but it may be good enough for now.
To make that work for new tickets though, you'd probably need the ticket creation to invoke a specific workflow action automatically, so it would have a chance to run that operation. That might be handy anyway to run other operations as well, or even set a different starting status.
Eli, to answer your initial question, I think the way it is now is odd but usable. Since it's not impeding the use of tickets or custom workflow, and seeing as 0.11 is already in rc, I think 0.11.1 would be ok.
-Jeff On May 17, 2008, at 4:39 PM, osimons wrote:
Actually, the problem reaches even further. As far as I can tell, and remember from earlier workflow discussions, only 'new' and 'closed' are actually system-supported states (both kinds of 'new'...). Everything else is configured by workflow (including 'reopened'). It may not exist, or it may exist but have a different contextual importance from our default meaning. So, it really does not belong in that list.... I've just briefly tried it out, and concluded that it does need fixing somehow - and that as you say, we don't have any good past-tense words for individual statuses. Reading this past-tense from config will lead to a painful localized message with i18n now in trunk... Anyway, it has worked like this for a long time (also predating workflow), so I don't think it is critical for 0.11. Nice if it gets done of course, but no problem for a 0.11 release. 0.11.1 milestone is fine by me.
smime.p7s
Description: S/MIME cryptographic signature
