bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <>
Subject Re: Multi product enhancements
Date Tue, 13 Nov 2012 15:33:04 GMT
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:
>>> Hi all,
>>> I was looking into enhancing multi product support within Bloodhound.
>>> afaik current multi product support consists of the ability to
>>> define/administer product(s) and the ability to assign product to a
>>> ticket. What I was thinking of starting with are the following rather
>>> simple features/functionalities:
>>> 1. product/ticket namespaces - product and ticket ID would form a two
>>> dimensional namespace, tickets would in addition to current URL scheme
>>> also be addressable through the product URL namespace, namely
>>> /ticket/<product>/<id>. Each product would have a separate numberspace
>>> for product ticket IDs. The same might also be applied for wikis, not
>>> sure about whether it's something that would come handy or not.
>>> 2. tickets should be moveable between products, old ticket product IDs
>>> (and URLs) should be remembered, making the same ticket accessible
>>> through old products namespaces.
>>> 3. enhance query to limit the search to specific product
>>> Down the line it'd be really useful to have per product permissions,
>>> versions, milestones, components, ticket lifecycles, predefined
>>> queries, etc., which is a bit more complex part that should be
>>> discussed in a separate thread.
>>> Any comments/suggestions on this?
> I think that this is broadly in line with what we want. I may comment more
> in the future on this. But for now, I will just say that I see no reason
> why the wiki should be restricted from being contained within a product.
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, such as ticket sequence in that 
namespace. As a consequence of that, ticket create would result in two 
table inserts, one for the ticket and one for the product namespace table.

To keep the database consistency, the two inserts should happen within 
the same transaction. Ticket insert happens within a database 
transaction rather deep in the trac core (trac/ticket/ Looking 
at the TransactionContextManager, it should be possible to create a 
database transaction higher on the stack that would eventually get 
reused in the trac core ticket insert. Higher in the stack in this case 
would mean to override the _do_create and _do_save from the trac 
TicketModule (as this is what ProductTicketModule derives from) - this 
is where ticket gets created/updated and notifications get sent out.

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 ...

Any opinions on what is the best approach to address this? Do we have 
sort of a 'strategy' on how to address issues like this - modified 
functionality that can't be implemented using extension points or by 
classical derive-override-call parent approach? 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. 
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.

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.


View raw message