Two precisions wrt my previous comments ... On 9/11/13, Olemis Lang <[email protected]> wrote: > On 9/11/13, Gary Martin <[email protected]> wrote: >> On 11/09/13 17:25, Olemis Lang wrote: >>> On 9/11/13, Joachim Dreimann <[email protected]> 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
