On 9 September 2013 17:20, Gary Martin <[email protected]> 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* e. [email protected] twitter @jdreimann <https://twitter.com/jdreimann>
