bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Move away from "default product" concept
Date Mon, 09 Sep 2013 18:47:09 GMT
On Mon, Sep 9, 2013 at 11:20 AM, Gary Martin <>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


Olemis - @olemislc

Apache™ Bloodhound contributor

Blog ES:
Blog EN:

Featured article:

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