On 09/09/13 19:47, Olemis Lang wrote:
On Mon, Sep 9, 2013 at 11:20 AM, Gary Martin <[email protected]>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
