bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: [BEP-0003] Per product ticket workflow (Was: Re: [Apache Bloodhound] Proposals/BEP-0003 modified)
Date Wed, 14 Nov 2012 16:47:33 GMT
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
  * 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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message