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 Thu, 08 Nov 2012 06:36:24 GMT
On 11/7/12, 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.

In first place , after reading only this part I'll start by saying
that we better pay attention to the big picture since the beginning .
Whatever we come up with has to deal with the fact that multi-product
support is not limited to the immediate need of getting things done
for tickets, wiki , ... and other resources in default Trac
installation . It's also about plugins . Once core resources will be
supported then there will be a need to have per-product code reviews ,
whiteboards , configuration , enabled/disabled components , blogs ,
test cases , pastebins , ... Besides in practice there will be many
possible URL mappings . I mention some examples below , but there may
be more :

  1.<product>/ticket/<id> ...
      as it stands nowadays
  2. http://<product><id> ... i.e. something like
      e.g. t.e.o and
      sibling projects
  3. http://<product><id> ...
      consider Allura @ as an example ;)

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

IMO tickets should still have a unique ID . Hence there should be no
problem with moving them between products . History of previous
products will be recorded in ticket change log . In case of mismatch
e.g. considering URL mapping (2) above on accessing
http://<wrong_product><id> I suggest to include an
informative message of the form

<p>This ticket does not belong in this product . <a
href="http://<product><id>">Click here</a> to see
it .</p>

> 3. enhance query to limit the search to specific product

Yes, it'd be nice to have some of those ;)

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

Product-specific permissions , workflow , configuration , ... there
should be a way to get them done , yes .



Blog ES:
Blog EN:

Featured article:

View raw message