You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Peter Koželj <pe...@digiverse.si> on 2012/11/14 16:45:24 UTC
[BEP-0003] Per product ticket workflow (Was: Re: [Apache Bloodhound]
Proposals/BEP-0003 modified)
> +=== Per product ticket workflow
>> +Depending on the product, different ticket workflows should be supported.
>> +
>>
>
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.
2. Most products will end up using the same workflow so this needs to be
optional feature
Peter
Re: [BEP-0003] Per product ticket workflow (Was: Re: [Apache
Bloodhound] Proposals/BEP-0003 modified)
Posted by Peter Koželj <pe...@digiverse.si>.
On 14 November 2012 17:47, Gary Martin <ga...@wandisco.com> 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
>
Re: [BEP-0003] Per product ticket workflow (Was: Re: [Apache Bloodhound]
Proposals/BEP-0003 modified)
Posted by Gary Martin <ga...@wandisco.com>.
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