incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: Multi product enhancements
Date Thu, 08 Nov 2012 06:36:24 GMT
On 11/7/12, Jure Zitnik <jure@digiverse.si> 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. http://server.com/path/to/bh/products/<product>/ticket/<id> ...
      as it stands nowadays
  2. http://<product>.server.com/ticket/<id> ... i.e. something like
      e.g. t.e.o and
      sibling projects
  3. http://<product>.server.com/path/to/bh/ticket/<id> ...
      consider Allura @ sf.net 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>.server.com/ticket/<id> I suggest to include an
informative message of the form

<p>This ticket does not belong in this product . <a
href="http://<product>.server.com/ticket/<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 .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Mime
View raw message