On 14 November 2012 17:47, Gary Martin <[email protected]> wrote:
> 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 > yes, this is exactly what I had in mind, so +1 > * 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 > +1 > > Cheers, > Gary >
