On 11/7/12 9:58 PM, Gary Martin wrote:
On 7 November 2012 09:29, Branko Čibej <[email protected]> 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/model.py). 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.
Cheers,
Jure
