bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: Move away from "default product" concept
Date Mon, 09 Sep 2013 16:20:23 GMT
On 09/09/13 14:00, Matevž Bradač wrote:
> Hi,
> As discussed previously on the devlist[1], the notion of "default product"
> doesn't make much sense after upgrade from single-product Trac/BH installations.
> Current implementation redirects most of the global requests into the default
> product (e.g. /roadmap -> /products/@/roadmap), with some exceptions (/wiki,
> /query etc.).
> I've been looking into removing the redirects and the first part of the code
> changes has been committed in r1521084 (#658). The new behaviour is outlined
> below:
> * Global requests are not redirected to the "default product" anymore.
> * Some of the URLs are handled in a special manner:
>      * /qct - This works same as before, the request is processed by the global
>        QCT handler and the user can specify a product from the dropdown.
>      * /newticket - Called from the QCT, it currently redirects to the first
>        product in the DB. This should probably be changed, so that either
>        /newticket is always executed in global scope with a product dropdown
>        (as in QCT), or that the request is redirected to the product currently
>        selected in the QCT dropdown.
>      * /ticket/<uid> - Looks up the ticket with specified UID and redirects to
>        the specific ticket page (e.g. /ticket/UID -> /products/prefix/ticket/ID).
>        For the default product UID equals ID, so the old URLs still work after
>        upgrading to multiproduct.
>      * /query - This was changed a while ago to allow queries to run in both
>        global and product scopes. When run in global scope all products are
>        queried (needed for global dashboard).
>      * /batchmodify - Same as /query.
>      * /wiki - Same as before, handles both global- and product-scoped wikis.

All sounds reasonable at the moment but I will have a play around and 
see if I can spot any issues. I agree that the /newticket behaviour does 
not quite sound right. Although I think we want /newticket to be 
populated with any values set in the QCT dropdown, I think that there 
should still be the opportunity to change the eventual product if 
desired. That suggests that it should go to the global scope, though I 
wonder if there is anything that makes it unwise to allow the selection 
of a different product on any product newticket path.

> There are a couple other requests that should probably be handled in a specific
> manner, namely /report and /timeline. IMO these should behave like /query - in
> global scope all products are referenced. In addition the /report should allow
> saving global, cross-product reports. Does this sound like the correct approach?

I think that makes sense as it seems reasonable that a user would want 
to see combined views of products. With the normal caveat that the 
content of these views have to respect the permissions of the content 
and the user attempting to access it.

Presumably we will also want to provide specific reports that take 
products into account which could be useful.


View raw message