bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: Multi product enhancements
Date Wed, 07 Nov 2012 09:29:44 GMT
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?

Gary and I talked about this the a couple days ago at ApacheCon;
specifically, about whether the product tag (as opposed to the product
name) should be immutable or not.

The assumption is that a "product" has two attributes:

    name: used for user-friendly display
    tag: shorter string, constrained syntax, unique

So, you could have a product named "Finnegan's Wake" with tag FW, and
ticket IDs within that product would have the format FW-123. Later on
you realize that your product is about the book, not the ballad, and you
rename it to "Finnegans Wake".

The some twit comes along and wants to change the tag to FWJOYCE. There
are conceptually two ways to do that:

  * Keep tags immutable, "rename" it by creating a new product, move all
    tickets to it and delete the new product.
  * Actually allow renaming the tag; a tag rename would still have to
    maintain the ticket ID history.

We came to the conclusion that it's best to keep tags immutable.
Eventually one could add a tag-rename helper to the UI that would do the
new-product/move-tickets/delete-old-product dance.

Another question that popped up was how to maintain eternal historical
uniqueness of ticket IDs when a tag for a previously deleted product
gets reused. One option is to never allow reusing historically used tags
in new products, but that seems a bit too restrictive. We came up with this:

  * along with the tag+number history for each ticket, remember the
    maximum ticket number per tag
  * when a tag gets reused, issue new ticket numbers from that
    remembered value, not from 1
  * this includes renumbering tickets that already have an ID with the
    reused tag, because it's never clear that the resurrected tag is
    used for the same product as before.
      o this might imply remembering the product name associated with a
        range of ticket numbers within a tag

-- Brane

View raw message