Occasional problem of dis-owning tickets

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Several of our users have expressed a problem where, on resolve + reply, the
ticket will be given to ‘Nobody’ after they save.
I would blame ‘fat fingers’ here, but it’s been happening too often, and the
user the ticket is given to is always ‘Nobody’, not any other user in the
queue.
I’m not really sure where to start debugging this (to find out if it’s RT or
user error). Does anybody have any ideas about what might trigger this?

Some info about my installation:
RT 3.0.9
MySQL 4.0.14
Apache 1.3.29
mod_perl 1.29
mostly default scripts

  • -Doug

Douglas E. Warner dwarner@ctinetworks.com Network Engineer
CTI/PAdotNET http://ctinetworks.com +1 717 975 9000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAx1OJJV36su0A0xIRAoAuAJ4tQq2ngieWAq5fbC5Vv41Jf4nYTQCg/2zG
JyiDDje09cWSfTEC97odB3g=
=Thob
-----END PGP SIGNATURE-----

Douglas E. Warner wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Several of our users have expressed a problem where, on resolve + reply, the
ticket will be given to ‘Nobody’ after they save.
I would blame ‘fat fingers’ here, but it’s been happening too often, and the
user the ticket is given to is always ‘Nobody’, not any other user in the
queue.
I’m not really sure where to start debugging this (to find out if it’s RT or
user error). Does anybody have any ideas about what might trigger this?
I know only one legal case when ownership can be lost it’s ticket’s
Queue change. When you’re changing queue and current owner doesn’t have
right ‘OwnTicket’ on target queue then he loses ownership.

Doug Warner wrote:

Several of our users have expressed a problem where, on resolve + reply, the
ticket will be given to ‘Nobody’ after they save.
I would blame ‘fat fingers’ here, but it’s been happening too often, and the
user the ticket is given to is always ‘Nobody’, not any other user in the
queue.
I’m not really sure where to start debugging this (to find out if it’s RT or
user error). Does anybody have any ideas about what might trigger this?

We had a similar problem; I made a bug report of it in May.

See http://rt3.fsck.com/Ticket/Display.html?id=5627&user=guest&pass=guest
for my writeup of the problem. It doesn’t look like anything has been
done with it yet.

I was able to observe this happening on a fresh RT installation (RT 3.0.9,
Perl 5.8.3, mysql 4.0.18), so I’m pretty sure it is an RT problem.
Our current work-around is to do another action between the take and the
resolve, such as viewing the basic page.

  • Ann

ann@drop.2organize.com wrote:

Doug Warner wrote:

Several of our users have expressed a problem where, on resolve + reply, the
ticket will be given to ‘Nobody’ after they save.
I would blame ‘fat fingers’ here, but it’s been happening too often, and the
user the ticket is given to is always ‘Nobody’, not any other user in the
queue.
I’m not really sure where to start debugging this (to find out if it’s RT or
user error). Does anybody have any ideas about what might trigger this?

We had a similar problem; I made a bug report of it in May.

See http://rt3.fsck.com/Ticket/Display.html?id=5627&user=guest&pass=guest
for my writeup of the problem. It doesn’t look like anything has been
done with it yet.

I was able to observe this happening on a fresh RT installation (RT 3.0.9,
Perl 5.8.3, mysql 4.0.18), so I’m pretty sure it is an RT problem.
Our current work-around is to do another action between the take and the
resolve, such as viewing the basic page.

Can’t reproduce your test case on

  1. RT 3.0.9+DBIx::SB 0.99+Perl 5.8.3(FC RPM)+mysql 4.0.14
  2. RT 3.0.HEAD+DBIx::SB 0.99+Perl 5.8.MAINT22834( own build)+mysql 4.0.20

Can you provide mysql query log for 2, 3 steps in your test case?
Best regards. Ruslan.

Ruslan wrote:

Can’t reproduce your test case on

  1. RT 3.0.9+DBIx::SB 0.99+Perl 5.8.3(FC RPM)+mysql 4.0.14
  2. RT 3.0.HEAD+DBIx::SB 0.99+Perl 5.8.MAINT22834( own build)+mysql 4.0.20

Can you provide mysql query log for 2, 3 steps in your test case?
Best regards. Ruslan.

Unfortunately I can no longer recreate the problem, perhaps because
the installation has been customised since then. We have the mysql
logging off by default, so I can’t recover any logs from the day when
I tested it. Perhaps Doug can be of more help here?

Here’s some more system-specific specs:
apache_1.3.29
mod_perl-1.29
mod_ssl-2.8.16-1.3.29

My guess would be some kind of caching problem…that would also explain the
intermittent behavior observed by Doug. But this is pure speculation;
I know nothing of RT guts.

Sorry I can’t be of more help.

  • Ann