bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <>
Subject Re: Move away from "default product" concept
Date Mon, 09 Sep 2013 17:11:41 GMT
On 9 September 2013 17:20, Gary Martin <> wrote:

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

I agree with that approach, to keep it in line with QCT.

> 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.
> Cheers,
> Gary

Joachim Dreimann | *User Experience Manager*

WANdisco // *Non-Stop Data*

twitter @jdreimann <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message