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 Wed, 11 Sep 2013 20:08:29 GMT
Two precisions wrt my previous comments ...

On 9/11/13, Olemis Lang <olemis@gmail.com> wrote:
> On 9/11/13, Gary Martin <gary.martin@wandisco.com> wrote:
>> On 11/09/13 17:25, Olemis Lang wrote:
>>> On 9/11/13, Joachim Dreimann <joachim.dreimann@wandisco.com> wrote:
[...]
>
> My opinion on this subject is :
>
> (1) it's ok , but IMO not optimal
> (2) would be best , by also disabling submit button
> (3) definitely no
> (4) would work but provides limited UX
>

In any case making product field more prominent in QCT would help to
avoid mistakes , because it seems to me that the root cause is that
product context is assumed by the contents of current page , therefore
product selector is overlooked .

[...]
>>>>> Reporting across multiple products might be problematic. There's
>>>>> already limited support for aggregating events in global timeline ,
>>>>> which is fine .
>>>>>
>>>> Reporting across products may be technologically problematic, but I'm
>>>> certain that this is a feature that will be expected by users.
>>>>
>>> I didn't say it before because I considered it implicitly . The fact
>>> is that reports are arbitrary SQL . I'd rather suggest to (improve |
>>> extend | rethink) the query module and include MP features in there
>>> rather than in reports module .
>>>
>>> [...]
>>>
>>
>> The ultimate protection around this would be the permissions around
>> report creation. This means that they almost certainly require a health
>> warning and people will need to make sure that they are providing access
>> to the reports appropriately. Some users, however, are likely to require
>> the power provided. Improving upon the query module would be good of
>> course but I suspect that will take some time and a lot of thought.
>>
>
> AFAICT I see that this subject is more about who sees what , instead
> of creator . IMO it's much harder to ensure data protection upon
> ticket queries than free style SQL reports .
>

This is wrong . It's relatively easy to ensure data protection upon
ticket queries . It is harder to do so in the case of free-style SQL
reports .

-- 
Regards,

Olemis - @olemislc

Mime
View raw message