On 11/7/12, Jure Zitnik <[email protected]> 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:
