bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
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 <gary.martin@wandisco.com>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:

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