You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Mat Booth <ma...@wandisco.com> on 2012/02/17 10:59:41 UTC
MultiProduct -- Was: Re: svn commit: r1242755
On 17 February 2012 09:47, Gary <ga...@wandisco.com> wrote:
> On 02/16/2012 06:50 PM, Mat Booth wrote:
>>
>> Also relevant:
>>
>> Now that I have fixed my personal website, I'd like to share a couple
>> of plug-ins I've written in the past for Trac. The first is
>> rudimentary support for multiple products, as a patch to the Trac core
>> and a companion plug-in, rather uninventively named MultiProduct:
>>
>> http://matbooth.co.uk/trac/wiki/MultiProductStart
>>
>> It was written a couple of years ago now so it was written for Trac
>> 0.11 but it does exciting things like add a new ticket field type to
>> facilitate having product dependant components and product dependant
>> versions. You can read more at the link above and by all means Gary,
>> steal as much of it as you like if it is useful to your multi-product
>> effort -- it's proven too as I know of at least two companies using it
>> in production in their internal Trac installs in addition to my
>> personal Trac at matbooth.co.uk :-)
>>
>> We should sit down and discuss merging our efforts, maybe. What are
>> your thoughts Gary?
>>
>> The second plug-in I'm responsible for is called TicketValidation:
>>
>> http://matbooth.co.uk/trac/wiki/TicketValidationStart
>>
>> Which was created in response to make certain ticket fields mandatory
>> for certain ticket types. Basically it's a way of configuring boolean
>> expressions to determine if a ticket field is mandatory based on the
>> values of the other fields. It also supports hiding fields from view
>> in a similar way. It's a little more rough and ready than my
>> MultiProduct plug-in, but again there is at least company I know of
>> using it production.
>>
>> I would be happy to move these two plug-ins wholesale to the
>> BloodHound project if you guys like them. I can then spend some time
>> updating them to work with the latest version of the Trac code base.
>>
>> Enjoy!
>>
>
> That is fantastic. Personally I would be very happy to see this work put
> into bloodhound as there is some very useful work there. I was under the
> impression that your multiproduct plugin was looking at a different level to
> my work but, even if that is true, it should go a long way towards solving
> other problems.
>
> Thanks Mat!
>
> Cheers,
> Gary
>
Changed the subject cause I hijacked the thread ;-)
Yes, I guess it does work at a different level. If what you want to is
to make products or projects a way of partitioning lists of tickets a
la Jira then you can think of my plug-in more as merely adding
per-component subcomponents and per-component versions. But you can
use the new field type that the patch adds to define relationships
between any drop-down selection fields you can think of.
It just met my need for a crude multiple project support in my Trac
instance. :-)
--
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com
Re: MultiProduct -- Was: Re: svn commit: r1242755
Posted by Mat Booth <ma...@wandisco.com>.
On 24 February 2012 01:29, Gary <ga...@wandisco.com> wrote:
> On 17/02/12 12:53, Mat Booth wrote:
>>
>> On 17 February 2012 10:06, Gary<ga...@wandisco.com> wrote:
>>>
>>>
>>> I think that subcomponents is something that we are likely to want at
>>> some
>>> point so that should be perfect.
>>>
>>> I wonder if there are now appropriate extension points in Trac to allow
>>> this
>>> to work without patching. Possibly something to consider further down the
>>> line though.
>>>
>>> Cheers,
>>> Gary
>>>
>> As I say on http://matbooth.co.uk/trac/wiki/MultiProductStart I had
>> planned to eliminate the need for a patch eventually. When I find some
>> time, I will investigate this.
>>
>>
> I had a quick look at your multiproduct work this evening. I think I have
> got it working for 0.13. There was one part of the patch that I couldn't
> seem to find an equivalent part of trac to modify. I'll have to consult you
> on that.
>
> Cheers,
> Gary
>
Nice work, I look forward to seeing some patches :-)
--
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com
Re: MultiProduct -- Was: Re: svn commit: r1242755
Posted by Gary <ga...@wandisco.com>.
On 17/02/12 12:53, Mat Booth wrote:
> On 17 February 2012 10:06, Gary<ga...@wandisco.com> wrote:
>>
>> I think that subcomponents is something that we are likely to want at some
>> point so that should be perfect.
>>
>> I wonder if there are now appropriate extension points in Trac to allow this
>> to work without patching. Possibly something to consider further down the
>> line though.
>>
>> Cheers,
>> Gary
>>
> As I say on http://matbooth.co.uk/trac/wiki/MultiProductStart I had
> planned to eliminate the need for a patch eventually. When I find some
> time, I will investigate this.
>
>
I had a quick look at your multiproduct work this evening. I think I
have got it working for 0.13. There was one part of the patch that I
couldn't seem to find an equivalent part of trac to modify. I'll have to
consult you on that.
Cheers,
Gary
Re: MultiProduct -- Was: Re: svn commit: r1242755
Posted by Mat Booth <ma...@wandisco.com>.
On 17 February 2012 10:06, Gary <ga...@wandisco.com> wrote:
> On 02/17/2012 09:59 AM, Mat Booth wrote:
>>
>> On 17 February 2012 09:47, Gary<ga...@wandisco.com> wrote:
>>>
>>> On 02/16/2012 06:50 PM, Mat Booth wrote:
>>>>
>>>> Also relevant:
>>>>
>>>> Now that I have fixed my personal website, I'd like to share a couple
>>>> of plug-ins I've written in the past for Trac. The first is
>>>> rudimentary support for multiple products, as a patch to the Trac core
>>>> and a companion plug-in, rather uninventively named MultiProduct:
>>>>
>>>> http://matbooth.co.uk/trac/wiki/MultiProductStart
>>>>
>>>> It was written a couple of years ago now so it was written for Trac
>>>> 0.11 but it does exciting things like add a new ticket field type to
>>>> facilitate having product dependant components and product dependant
>>>> versions. You can read more at the link above and by all means Gary,
>>>> steal as much of it as you like if it is useful to your multi-product
>>>> effort -- it's proven too as I know of at least two companies using it
>>>> in production in their internal Trac installs in addition to my
>>>> personal Trac at matbooth.co.uk :-)
>>>>
>>>> We should sit down and discuss merging our efforts, maybe. What are
>>>> your thoughts Gary?
>>>>
>>>> The second plug-in I'm responsible for is called TicketValidation:
>>>>
>>>> http://matbooth.co.uk/trac/wiki/TicketValidationStart
>>>>
>>>> Which was created in response to make certain ticket fields mandatory
>>>> for certain ticket types. Basically it's a way of configuring boolean
>>>> expressions to determine if a ticket field is mandatory based on the
>>>> values of the other fields. It also supports hiding fields from view
>>>> in a similar way. It's a little more rough and ready than my
>>>> MultiProduct plug-in, but again there is at least company I know of
>>>> using it production.
>>>>
>>>> I would be happy to move these two plug-ins wholesale to the
>>>> BloodHound project if you guys like them. I can then spend some time
>>>> updating them to work with the latest version of the Trac code base.
>>>>
>>>> Enjoy!
>>>>
>>> That is fantastic. Personally I would be very happy to see this work put
>>> into bloodhound as there is some very useful work there. I was under the
>>> impression that your multiproduct plugin was looking at a different level
>>> to
>>> my work but, even if that is true, it should go a long way towards
>>> solving
>>> other problems.
>>>
>>> Thanks Mat!
>>>
>>> Cheers,
>>> Gary
>>>
>> Changed the subject cause I hijacked the thread ;-)
>
>
> Good move :)
>
>
>> Yes, I guess it does work at a different level. If what you want to is
>> to make products or projects a way of partitioning lists of tickets a
>> la Jira then you can think of my plug-in more as merely adding
>> per-component subcomponents and per-component versions. But you can
>> use the new field type that the patch adds to define relationships
>> between any drop-down selection fields you can think of.
>
>
> I think that subcomponents is something that we are likely to want at some
> point so that should be perfect.
>
> I wonder if there are now appropriate extension points in Trac to allow this
> to work without patching. Possibly something to consider further down the
> line though.
>
> Cheers,
> Gary
>
As I say on http://matbooth.co.uk/trac/wiki/MultiProductStart I had
planned to eliminate the need for a patch eventually. When I find some
time, I will investigate this.
--
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com
Re: MultiProduct -- Was: Re: svn commit: r1242755
Posted by Gary <ga...@wandisco.com>.
On 02/17/2012 09:59 AM, Mat Booth wrote:
> On 17 February 2012 09:47, Gary<ga...@wandisco.com> wrote:
>> On 02/16/2012 06:50 PM, Mat Booth wrote:
>>> Also relevant:
>>>
>>> Now that I have fixed my personal website, I'd like to share a couple
>>> of plug-ins I've written in the past for Trac. The first is
>>> rudimentary support for multiple products, as a patch to the Trac core
>>> and a companion plug-in, rather uninventively named MultiProduct:
>>>
>>> http://matbooth.co.uk/trac/wiki/MultiProductStart
>>>
>>> It was written a couple of years ago now so it was written for Trac
>>> 0.11 but it does exciting things like add a new ticket field type to
>>> facilitate having product dependant components and product dependant
>>> versions. You can read more at the link above and by all means Gary,
>>> steal as much of it as you like if it is useful to your multi-product
>>> effort -- it's proven too as I know of at least two companies using it
>>> in production in their internal Trac installs in addition to my
>>> personal Trac at matbooth.co.uk :-)
>>>
>>> We should sit down and discuss merging our efforts, maybe. What are
>>> your thoughts Gary?
>>>
>>> The second plug-in I'm responsible for is called TicketValidation:
>>>
>>> http://matbooth.co.uk/trac/wiki/TicketValidationStart
>>>
>>> Which was created in response to make certain ticket fields mandatory
>>> for certain ticket types. Basically it's a way of configuring boolean
>>> expressions to determine if a ticket field is mandatory based on the
>>> values of the other fields. It also supports hiding fields from view
>>> in a similar way. It's a little more rough and ready than my
>>> MultiProduct plug-in, but again there is at least company I know of
>>> using it production.
>>>
>>> I would be happy to move these two plug-ins wholesale to the
>>> BloodHound project if you guys like them. I can then spend some time
>>> updating them to work with the latest version of the Trac code base.
>>>
>>> Enjoy!
>>>
>> That is fantastic. Personally I would be very happy to see this work put
>> into bloodhound as there is some very useful work there. I was under the
>> impression that your multiproduct plugin was looking at a different level to
>> my work but, even if that is true, it should go a long way towards solving
>> other problems.
>>
>> Thanks Mat!
>>
>> Cheers,
>> Gary
>>
> Changed the subject cause I hijacked the thread ;-)
Good move :)
> Yes, I guess it does work at a different level. If what you want to is
> to make products or projects a way of partitioning lists of tickets a
> la Jira then you can think of my plug-in more as merely adding
> per-component subcomponents and per-component versions. But you can
> use the new field type that the patch adds to define relationships
> between any drop-down selection fields you can think of.
I think that subcomponents is something that we are likely to want at
some point so that should be perfect.
I wonder if there are now appropriate extension points in Trac to allow
this to work without patching. Possibly something to consider further
down the line though.
Cheers,
Gary