On 14/11/12 15:45, Peter Koz(elj wrote:
+=== Per product ticket workflow
+Depending on the product, different ticket workflows should be supported.
+
I should probably note that we can live with a single workflow in the
short term so this may not be top priority. Saying that, it is still
good for people to see where we are likely to be going I think.
1. Not strictly a multiproduct feature but we should keep in mind: At some
point workflow should actually be per product and PER TICKET TYPE.
Yes, a bit off-topic. However..
I have my doubts about per ticket type workflow but I do understand that
it is something that people may well want. It could probably be achieved
through ticket type dependent transitions so that there is some sharing
of states and transitions. It should be remembered that tickets can
change type and the types should be expected to be modified by users.
2. Most products will end up using the same workflow so this needs to be
optional feature
I completely agree although I might suggest taking it a small step
further. If we get to the point where we are looking at supporting very
large numbers of products, we might want something like this:
* a base workflow - for when a product does not specify a workflow for
itself
* product specific workflows - used when a product requires a unique
workflow definition that is not expected to be shared
* named workflows - alternatives to the base workflow that are
potentially selectable for many products.. and perhaps the base
workflow could point to one of these by default
Cheers,
Gary