DB and setup dependent. ACL checks in RT are painful for all DBs,
however these days we at least know how to cook old queries and there
are a lot of knowledge on the web. This new feature changes balance.
New queries may need new indexes, new execution paths may need new
optimizations and bug fixes
> I suspect that with certain backends or SearchBuilder versions, the
> DB plans could be umm... non-optimal for this feature. :) I am trying
> it here as well.
Indeed. It's still largely experimental. I'd always been fairly certain
that it was "impossible", but Ruslan worked a whole bunch of mag
On Thu, Feb 05, 2009 at 10:59:13AM -0500, Rob Munsch wrote:
> On Thu, Feb 5, 2009 at 8:15 AM, Emmanuel Lacour
> wrote:
>
> > Depending on your RT version, you can try the following option:
> >
> > Set($UseSQLForACLChecks, 1);
> >
> > but read comment on it in RT_Config.pm before enabling it.
>
On Thu, Feb 5, 2009 at 8:15 AM, Emmanuel Lacour wrote:
> Depending on your RT version, you can try the following option:
>
> Set($UseSQLForACLChecks, 1);
>
> but read comment on it in RT_Config.pm before enabling it.
Go not to the docs for counsel, for they will say both no and yes.
"In some ca
On Wed, Feb 04, 2009 at 08:58:33PM -0500, Rob Munsch wrote:
> Hello list,
>
> After some initial confusion, i realized that a user's "10 latest"
> block gets the 10 latest tickets, and THEN filters it for what queues
> that user is allowed to see - sometimes resulting in 4 tickets, or 1
> ticket,
Hello list,
After some initial confusion, i realized that a user's "10 latest"
block gets the 10 latest tickets, and THEN filters it for what queues
that user is allowed to see - sometimes resulting in 4 tickets, or 1
ticket, or no tickets at all!
I'm not sure how, or if i can, change this behavi
