On Mon, Sep 9, 2013 at 11:20 AM, Gary Martin <[email protected]>wrote:
> On 09/09/13 14:00, Matevž Bradač wrote: > >> Hi, >> >> :) [...] > 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: >> > > [...] > 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've been running BH without default product since a while ago and there is something related to this that I find annoying . Currently QCT product initial value is set considering context . That's ok . Nevertheless after creating the first ticket and/or clearing QCT form it turns out that another product is activated by JS code . Based on my experience this results in a frequent kind of *blindness* (resembling akinetopsia or achromatopsia or alike , without being a pathology but a consequence of the brain assuming a pre-existent condition) . This leads to a number of mistakes related to product selection. > That suggests that it should go to the global scope, why not bind it to product if accessed on that context ? > though I wonder if there is anything that makes it unwise to allow the > selection of a different product on any product newticket path. > > afaict , the fact that components, milestones, ... will (may) be different across different products , and drop down displays values for current context. By submitting tickets with values not defined in selected products things get messy , and milestones might even break the site , an effect similar to #613 > > 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. > > IMO this should not apply to reports , definitely sure it goes for the timeline , though there are already parts of the system that are currently aggregated in the global timeline e.g. version control events . > Presumably we will also want to provide specific reports that take > products into account which could be useful. > > ... but difficult to handler afaict and maybe a target for security breaches by bypassing product isolation . > Cheers, > Gary > -- Regards, Olemis - @olemislc Apache™ Bloodhound contributor http://issues.apache.org/bloodhound http://blood-hound.net Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
