since our upgrade to RT 3.6.4, the "resolve multiple tickets"
functionality shows erratic behavior in my installation. When before, it
only showed the privileged users (which are in the ballpark of 3-10 per
queue), it then started to show all users who ever submitted tickets,
including obvious spam and bogus users.
This leads to inacceptable long loading times (the “resolve multiple
tickets” page takes about 3 minutes to load). We’re currently around
ticket #74000 in our installation, so there are quite some ticket owners
in the database…
Unfortunately, I am not completely sure if the update to 3.6.4 is the
actual reason for this change in behavior, since I have also made some
minor changes in the configuration (which, of course, I don’t remember
now).
Is there a switch in the config files that might have caused this behavior?
Thanks for pointers,
–ck
Christopher Kunz | Geschï¿œftsfï¿œhrung | chris@filoo.de
since our upgrade to RT 3.6.4, the “resolve multiple tickets”
functionality shows erratic behavior in my installation. When before, it
only showed the privileged users (which are in the ballpark of 3-10 per
queue), it then started to show all users who ever submitted tickets,
including obvious spam and bogus users.
you seems to gave OwnTicket right to everyone or unprivileged users,
check your permissions.
you seems to gave OwnTicket right to everyone or unprivileged users,
check your permissions.
Currently, global Group Rights are as follows:
Everyone: CreateTicket
Privileged: ShowOutgoingEmail
Unprivileged: CreateTicket, ReplyToTicket, ShowOutgoingEmail, Watch
Requestor: CreateTicket, ModifyTicket, ReplyToTicket
All other relevant groups: No rights granted.
For testing, I have now removed ShowOutgoingEmail and Watch from the
Unprivileged group and the behavior does not seem to have changed.
I have checked queue-specific groups and there are no additional default
privileges.
Any other ideas?
Regards,
–ck
Christopher Kunz | Gesch�ftsf�hrung | chris@filoo.de
From: Christopher Kunz (Filoo GmbH) chris@de-punkt.de
Subject: [rt-users] RT 3.6.4, user list too long when resolving multiple tickets
To: RT-Users@lists.bestpractical.com
Date: Monday, February 2, 2009, 6:15 AM
Hi all,
since our upgrade to RT 3.6.4, the “resolve multiple tickets”
functionality shows erratic behavior in my installation. When before, it
only showed the privileged users (which are in the ballpark of 3-10 per
queue), it then started to show all users who ever submitted tickets,
including obvious spam and bogus users.
This leads to inacceptable long loading times (the “resolve multiple
tickets” page takes about 3 minutes to load). We’re currently around
ticket #74000 in our installation, so there are quite some ticket owners
in the database…
Unfortunately, I am not completely sure if the update to 3.6.4 is the
actual reason for this change in behavior, since I have also made some
minor changes in the configuration (which, of course, I don’t remember
now).
Is there a switch in the config files that might have caused this behavior?
Thanks for pointers,
–ck
Christopher Kunz | Geschäftsführung | chris@filoo.de
Sorry you’ve already analyzed this with Emmanuel.On Mon, Feb 2, 2009 at 6:42 PM, Ruslan Zakirov ruslan.zakirov@gmail.com wrote:
SELECT * FROM ACL WHERE RightName = ‘OwnTicket’;
paste here
It can be a role on a queue.
On Mon, Feb 2, 2009 at 3:33 PM, Christopher Kunz (Filoo GmbH) chris@de-punkt.de wrote:
Emmanuel Lacour schrieb:
you seems to gave OwnTicket right to everyone or unprivileged users,
check your permissions.
Currently, global Group Rights are as follows:
Everyone: CreateTicket
Privileged: ShowOutgoingEmail
Unprivileged: CreateTicket, ReplyToTicket, ShowOutgoingEmail, Watch
Requestor: CreateTicket, ModifyTicket, ReplyToTicket
All other relevant groups: No rights granted.
For testing, I have now removed ShowOutgoingEmail and Watch from the
Unprivileged group and the behavior does not seem to have changed.
I have checked queue-specific groups and there are no additional default
privileges.
It can be a role on a queue.On Mon, Feb 2, 2009 at 3:33 PM, Christopher Kunz (Filoo GmbH) chris@de-punkt.de wrote:
Emmanuel Lacour schrieb:
you seems to gave OwnTicket right to everyone or unprivileged users,
check your permissions.
Currently, global Group Rights are as follows:
Everyone: CreateTicket
Privileged: ShowOutgoingEmail
Unprivileged: CreateTicket, ReplyToTicket, ShowOutgoingEmail, Watch
Requestor: CreateTicket, ModifyTicket, ReplyToTicket
All other relevant groups: No rights granted.
For testing, I have now removed ShowOutgoingEmail and Watch from the
Unprivileged group and the behavior does not seem to have changed.
I have checked queue-specific groups and there are no additional default
privileges.
On queue with Id 33, you gave right OwnTicket to Group 5 and Group 5 is
usually the “Unprivileged” group!
I removed that privilege from the respective queue (it is a test queue
that was never actually used), and double-checked all other queues.
However, I found a couple other queues in our installation that have
Rights like CreateTicket, CommentOnTicket, ReplyTicket, ModifyTicket or
others (not OwnTicket) set. Is this a problem, too?
The issue persists (I have tested it with Elements/SelectOwner).
Regards,
–ck
Christopher Kunz | Gesch�ftsf�hrung | chris@filoo.de
On queue with Id 33, you gave right OwnTicket to Group 5 and Group 5 is
usually the “Unprivileged” group!
I removed that privilege from the respective queue (it is a test queue
that was never actually used), and double-checked all other queues.
THere was also OwnTicket granted to “Everyone” on this queue, did you
removed it?
However, I found a couple other queues in our installation that have
Rights like CreateTicket, CommentOnTicket, ReplyTicket, ModifyTicket or
others (not OwnTicket) set. Is this a problem, too?
Shouldn’t.
The issue persists (I have tested it with Elements/SelectOwner).
About how many users do you get in SelectOwner? 10, 100, 1000, more?
If you removed the OwnTicket right on Unprivileged and Everyone group of
your test queue and still got a high number of people in SelectOwner,
then it’s probably because either one or more of your user groups
contains those people, or because you made too many people privileged.
Emmanuel Lacour schrieb:> On Mon, Feb 02, 2009 at 05:03:26PM +0100, Christopher Kunz (Filoo GmbH) wrote:
Emmanuel Lacour schrieb:
On queue with Id 33, you gave right OwnTicket to Group 5 and Group 5 is
usually the “Unprivileged” group!
I removed that privilege from the respective queue (it is a test queue
that was never actually used), and double-checked all other queues.
THere was also OwnTicket granted to “Everyone” on this queue, did you
removed it?
That did the trick. Thanks so much!
Regards,
–ck
Christopher Kunz | Gesch�ftsf�hrung | chris@filoo.de
I agree with Emmanuel that workaround does not really provide a “fix” on
this issue. I have read and followed this issue (of users list too long, or
QueryBuilder and Bulk update page takes too long to load) for a while. FYI:
I am running RT 3.8.1 on opensuse11; perl 5.10; mysql 5.0
I did not see same issue as described in “Message 5” below. But, I did
notice one of my queues had a permissions of “OwnTicket” to group 3. When I
looked; group 3 is “Everyone”, but the queue it was assigned to did not
exist! Not sure why, perhaps it was deleted by prior admin.
So, I removed that privilege from the “unknown” queue, and now my pages are
much faster (i.e; I do not have a long list of users in “Own Ticket” drop
down box).
you’ve already analyzed this with Emmanuel.On Mon, Feb 2, 2009 at 6:42 PM, Ruslan Zakirov