Hi, * About the proposed default workflows: I think both opensource and enterprise wrokflow lacks an important state: a "needinfo"-like state, when some additional info / details / feedback from the reporter are required to refine the description of the ticket. (I would also have had a way to distinguish a ticket that has been "closed" in a branch and actually delivered to the trunk, but I guess this one is not generic enough to be part of a default workflow)
* About the storage of the workflow config: whatever the storage backend (ini, plugin, ...), I think Trac needs a admin plugin to define the whole workflow process with a user-friendly interface - especially for enterprise-grade workflows. So maybe a plugin that to execute the workflow + a plugin to manage the workflow configuration would be nice, the workflow configuration being stored in the DB? trac.ini solution may be too limited, but plugin solution is not enough: the workflow should be customizable without any Python skills. my 2 cents, Manu --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
