bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Multi product enhancements
Date Wed, 14 Nov 2012 08:38:25 GMT
On 11/13/12, Jure Zitnik <> wrote:
> On 11/7/12 9:58 PM, Gary Martin wrote:
>> On 7 November 2012 09:29, Branko Čibej <> wrote:
>>> On 07.11.2012 08:42, Jure Zitnik wrote:
> I did a bit of code digging to get an idea how the product ticket
> namespace could be implemented and I came up with a problem described
> below ...
> In my opinion the most obvious way to keep the product ticket namespace
> would be to introduce a new database table that would link the product
> to the ticket by adding additional info,

If you need a new product-specific ticket number sequence (which I
don't think is really needed , at least for the moment) maybe that's
ok *IF* other mechanism like custom ticket fields is not enough.

> such as ticket sequence in that
> namespace.

btw , what's the decision on having consecutive ticket sequence
per-product ? Is it a design goal ? That will only make things harder
at the beginning while we try to sort out more important puzzles . Can
we make it clear whether consecutive ticket sequence per-product will
be included or not ?

fwiw ... I'm -1 about adding it soon ... maybe later

> But as we want to perform the database inserts prior to sending out
> email notifications (let's say we want to include newly generated URLs
> from the product ticket namespace in the notification emails) we can't
> really simply call the original/trac methods. So, to accomplish this
> (single transaction for both inserts, product ticket namespace URLs in
> notifications), we would need to literally copy parts of the trac code
> to the overriden methods and add/modify the code to handle product
> ticket namespace and notifications ...

The solution for adjustment of product resource URLs should happen
transparently . That's what «product environments» [1]_ are for . I'll
explain how they'd work soon once I continue writing BEP 3 . Feel free
to drop some ideas in there too ;)

> Patching trac would
> possibly solve this but if we want to keep the plugin functionality
> separate from trac that's really not the proper way of doing things.

Please let's try to modify (copy , duplicate ...) code rarely , and
only if there's a very good reason to do so . Changing things in there
may break many other parts of the system and external plugins .

> Using the trac code copy in overridden methods is also suboptimal. I
> noticed though that the bloodhound theme (quick ticket create) sort of
> uses this second approach.

Kind of ... but create_ticket has been copied from XmlRpcPlugin , so
it's a well-known , reliable (and tested ;) implementation .

> I'm bringing this up partly because I have a strong suspicion that we'll
> come across the same issues if/when we start thinking of implementing
> per product wiki, components, milestones, versions, etc.

Yes . So the solution should not be to start patching Trac all over
and (it does not stop there) merging subsequent changes with time .

.. [1] Some ideas on Multiproduct architecture



Blog ES:
Blog EN:

Featured article:

View raw message