bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <joachim.dreim...@wandisco.com>
Subject Re: Move away from "default product" concept
Date Wed, 11 Sep 2013 09:30:27 GMT
On 10 September 2013 20:35, Olemis Lang <olemis@gmail.com> wrote:

> On 9/10/13, Gary Martin <gary.martin@wandisco.com> 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 .
>

>From my observation the best predictor for which product I will raise a
ticket for next is the product for which I last raised one.

I've changed my view on this a few times, but I think (1) seems like out
best option.
When I raise tickets I:
- am working with a specific product, rather than switch between them
frequently
- frequently first search if a related tickets exists, which puts me in the
product context

(3) would be my second choice for the same reasons, but introduces many new
considerations regarding the implementation and just how persistent it
should be, for example across tabs. (Thanks Gary for challenging me on
this!)

I feel like option (2) will be annoying, mostly. (4) violates the idea of
the global header.


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

Reporting across products may be technologically problematic, but I'm
certain that this is a feature that will be expected by users.


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



-- 
Joachim Dreimann | *User Experience Manager*

WANdisco // *Non-Stop Data*

e. joachim.dreimann@wandisco.com
twitter @jdreimann <https://twitter.com/jdreimann>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message