bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: Move away from "default product" concept
Date Tue, 10 Sep 2013 16:18:12 GMT
On 09/09/13 19:47, Olemis Lang wrote:
> 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.

Yeah, that does not sound good.

I may have missed something but there seem to be four basic choices that 
have varying levels of sense to them:

 1. Go back to the initial product based on current product context
 2. Clear the current product on each submission to force the choice
    each time
 3. Let the product selection remain persistent until it is changed for
    future choices
 4. Only allow users to raise tickets in the product that they are in

Of these, option 2 is least likely to cause user errors. Whether it is 
annoying for them is another question.

Options 1 and 4 are inconsistent with the idea of the header area being 
unscoped (have we finished that discussion yet?)

Option 3 may be tempting but the user may forget which product is 
currently set and it also brings up questions of whether the persistence 
should be maintained through an entire session.

>> That suggests that it should go to the global scope,
>
> why not bind it to product if accessed on that context ?

That depends on whether we want it to be easy to change the destination 
product.

>> 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

Obviously if we have the ability to change the product, field selections 
have to update to respect the options that are available. Without this 
ability, we probably can't have a global /newticket at all and it 
couldn't have a QCT form either (at least, not without a default product 
setting.)

>>   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 .

I am not clear what you mean by the above. Are you saying that you don't 
want global reports and timelines or is this something about permissions?

>
>> 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 .

Well, if we are unable to respect permissions then clearly we can't do 
this. Presumably if this was the case this would already be a problem 
for reports within a product where permissions are restricted though.

Cheers,
     Gary

Mime
View raw message