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

Reply via email to