On 9/10/13, Gary Martin <[email protected]> wrote: > On 09/09/13 19:47, Olemis Lang wrote: [...] >> >> 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. >
I'd choose (2) by also disabling submit button if product field is empty . [...] >>> 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.) > This has been reported before in #618 . I'm raising its priority to critical and scheduling for next milestone . [...] >>> 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? > Reporting across multiple products might be problematic. There's already limited support for aggregating events in global timeline , which is fine . >> >>> 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. > There are a sort of new factors making both scenarios different afaict , one of them being the possibility of enabling/disabling different sets of components in some products ... but maybe not the only one . -- Regards, Olemis - @olemislc
