On 9 September 2013 17:20, Gary Martin <gary.martin@wandisco.com> 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. joachim.dreimann@wandisco.com
twitter @jdreimann <https://twitter.com/jdreimann>
|