On 14 November 2012 09:38, Olemis Lang <[email protected]> wrote: > On 11/13/12, Jure Zitnik <[email protected]> wrote: > > 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: > > > [...] > > > > 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 >
I am not particularly keen on true product number-space, but there is at least one very compelling reason to have at least limited support for this. Migrating from systems like Jira almost demands this. If I had a large Jira database, keeping the ticket id's during migration to BH would most certainly be a requirement. This could also be achieved with something like aliases that can act independently from products but at that point I think I prefer a single solution in the form of true product ticket number-space. > > > > > 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 > ( > https://issues.apache.org/bloodhound/attachment/wiki/Proposals/BEP-0003/Multiproduct.png > ) > > -- > Regards, > > Olemis. > > Blog ES: http://simelo-es.blogspot.com/ > Blog EN: http://simelo-en.blogspot.com/ > > Featured article: >
