incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: Multi product enhancements
Date Wed, 14 Nov 2012 11:35:42 GMT
On 14 November 2012 09:38, Olemis Lang <olemis@gmail.com> wrote:

> On 11/13/12, Jure Zitnik <jure@digiverse.si> wrote:
> > On 11/7/12 9:58 PM, Gary Martin wrote:
> >> On 7 November 2012 09:29, Branko Čibej <brane@wandisco.com> 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:
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message