Odd behaviour

RTIR
1

I have two instances of RT (3.0.12) and RTIR (1.0.5). One was cloned
from the other and then the base Debian system was upgraded while
keeping the versions of RT and RTIR the same. I’ve applied a couple of
patches to deal with the change in operating system version and
particularly a change to the Mason PERl module.

Both instances are pointing to the same MySQL database. The only
difference is the $WebBaseURL variable is different between the two, as
far as I can tell.

The problem is the two instances show a different number of unlinked
reports on the main RTIR page. The newer one seems to be showing all the
rejected and linked open reports (over 5000 of them!).

Could this be due to the different URL’s used, or is there something else?

Any ideas would be much appreciated.

Regards,
Tony.
Tony Arnold, Tel: +44 (0) 161 275 6093
Head of IT Security, Fax: +44 (0) 870 136 1004
University of Manchester, Mob: +44 (0) 773 330 0039
Manchester M13 9PL. Email: tony.arnold@manchester.ac.uk

2

I have two instances of RT (3.0.12) and RTIR (1.0.5). One was cloned
from the other and then the base Debian system was upgraded while
keeping the versions of RT and RTIR the same. I’ve applied a couple of
patches to deal with the change in operating system version and
particularly a change to the Mason PERl module.

Both instances are pointing to the same MySQL database. The only
difference is the $WebBaseURL variable is different between the two,
as
far as I can tell.

The problem is the two instances show a different number of unlinked
reports on the main RTIR page. The newer one seems to be showing all
the
rejected and linked open reports (over 5000 of them!).

Could this be due to the different URL’s used, or is there something
else?

At a rough guess, I’m betting on ‘Different versions of
DBIx::SearchBuilder’

PGP.sig (186 Bytes)

3

Jesse,

I don’t know if the following is what you designed it to do or not, but it
seems strange to me. We are planning to use a single input queue for users
to submit to, and then various other queues to file them into based on the
support person’s understanding of the ticket:

  1. A user creates a new ticket into the “general” incoming queue.
  2. The support person looks at the ticket and determines what queue it should
    go into.
  3. The support person clicks on “The Basics” section.
  4. They then change the “queue” pop-up to the desired queue we want it
    categorized under.
  5. The “Status” is left on “new” because no-one has opened it yet, we are
    only categorizing them to the appropriate queue where certain support
    people are responsible for.
  6. Then click “Save Changes”.
  7. The “Results” then say:

Queue: Queue changed from general to quickic
Status: Status changed from open to new by rshaw

Which is what I’d expect. It should remain “new”.

However, when you then go an look at the ticket details now, it says it’s
"open" and owned by “Nobody”. If you look at the history, you’ll see:

Fri May 25 11:10:48 2001 Queue changed from general to quickic

Fri May 25 11:10:49 2001 Status changed from new to open by rshaw

Fri May 25 11:10:50 2001 Status changed from open to new by rshaw

Fri May 25 11:10:50 2001 Status changed from new to open by rshaw

Shouldn’t it have stopped at the “changed from open to new” transaction? Why
is there another “new to open” at the end now?

Any thoughts?

Thanks!
-Robert

4

Known bug. #504. will be fixed when I get home from travelling this weekendOn Fri, May 25, 2001 at 11:13:07AM -0700, Robert Shaw wrote:

Jesse,

I don’t know if the following is what you designed it to do or not, but it
seems strange to me. We are planning to use a single input queue for users
to submit to, and then various other queues to file them into based on the
support person’s understanding of the ticket:

  1. A user creates a new ticket into the “general” incoming queue.
  2. The support person looks at the ticket and determines what queue it should
    go into.
  3. The support person clicks on “The Basics” section.
  4. They then change the “queue” pop-up to the desired queue we want it
    categorized under.
  5. The “Status” is left on “new” because no-one has opened it yet, we are
    only categorizing them to the appropriate queue where certain support
    people are responsible for.
  6. Then click “Save Changes”.
  7. The “Results” then say:

Queue: Queue changed from general to quickic
Status: Status changed from open to new by rshaw

Which is what I’d expect. It should remain “new”.

However, when you then go an look at the ticket details now, it says it’s
“open” and owned by “Nobody”. If you look at the history, you’ll see:

Fri May 25 11:10:48 2001 Queue changed from general to quickic

Fri May 25 11:10:49 2001 Status changed from new to open by rshaw

Fri May 25 11:10:50 2001 Status changed from open to new by rshaw

Fri May 25 11:10:50 2001 Status changed from new to open by rshaw

Shouldn’t it have stopped at the “changed from open to new” transaction? Why
is there another “new to open” at the end now?

Any thoughts?

Thanks!
-Robert

jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

<Dr_Memory> the point is that words were exchanged. neurolinguistic
programming will do the rest. they should be showing up at my house
any day now.

5

Hi,
This is an intentional bug…

When you view a ticket, by defalut, the system updates the status to open if the current status is new, new essentially meaning ‘unread’. This came about as some people pointed out it was silly having to update status everytime you took a ticket. You just happen to use RT differently to most.

What’s happening is that when you click ‘Save changes’, it sets the status to new, but then loads the ticket view, which sets the status to ‘open’ again.

Looking through the code that does this, I found a comment from Jesse:
#TODO do we really want to force this as policy? it should be a scrip

i.e. this isn’t an ideal fix, at some point in the future it’ll be site configurable.

In the meantime, to disable this ‘feature’, comment out the lines 1225-1227 in rt2/lib/RT/Ticket.pm

-Feargal.

_/_/_/ _/_/_/  _/_/_/  Feargal Reilly,

_/ _/ / / Systems Administrator,
/ / //// The Communications Interactive Agency.
/// /// _/ _/ Phone: +353-86-8732249.

 Jesse,
 
 I don't know if the following is what you designed it to do or not, but it
 seems strange to me. We are planning to use a single input queue for users
 to submit to, and then various other queues to file them into based on the
 support person's understanding of the ticket:
 
 1. A user creates a new ticket into the "general" incoming queue.
 2. The support person looks at the ticket and determines what queue it sho
 uld
    go into.
 3. The support person clicks on "The Basics" section.
 4. They then change the "queue" pop-up to the desired queue we want it
    categorized under.
 5. The "Status" is left on "new" because no-one has opened it yet, we are
    only categorizing them to the appropriate queue where certain support
    people are responsible for.
 6. Then click "Save Changes".
 7. The "Results" then say:
 
 Queue: Queue changed from general to quickic 
 Status: Status changed from open to new by rshaw 
 
 Which is what I'd expect. It should remain "new".
 
 However, when you then go an look at the ticket details now, it says it's
 "open" and owned by "Nobody". If you look at the history, you'll see:
 
 Fri May 25 11:10:48 2001 Queue changed from general to quickic 
 
 Fri May 25 11:10:49 2001 Status changed from new to open by rshaw
 
 Fri May 25 11:10:50 2001 Status changed from open to new by rshaw
 
 Fri May 25 11:10:50 2001 Status changed from new to open by rshaw
                                                                           
                              
 Shouldn't it have stopped at the "changed from open to new" transaction? W
 hy
 is there another "new to open" at the end now?
 
 Any thoughts?
 
 Thanks!
 -Robert
 
 Rt-devel mailing list
 Rt-devel@lists.fsck.com
 http://lists.fsck.com/mailman/listinfo/rt-devel
6

Feargal Reilly feargal@online.thecia.ie writes:

Hi,
This is an intentional bug…

When you view a ticket, by defalut, the system updates the status to
open if the current status is new, new essentially meaning
‘unread’. This came about as some people pointed out it was silly
having to update status everytime you took a ticket. You just happen
to use RT differently to most.

I would rather have it changing to open only then the ticket is
taken. Not then it’s viewed.

/ Jonas Liljegren

The Wraf project Welcome to the hub of online gaming
Sponsored by http://www.rit.se/

7

Feargal Reilly feargal@online.thecia.ie writes:

Hi,
This is an intentional bug…

When you view a ticket, by defalut, the system updates the status to
open if the current status is new, new essentially meaning
‘unread’. This came about as some people pointed out it was silly
having to update status everytime you took a ticket. You just happen
to use RT differently to most.

I would rather have it changing to open only then the ticket is
taken. Not then it’s viewed.

Yes, I agree, this is what I would prefer it do also. I don’t see any reason
to make a ticket open if it has never been “taken”. If it hasn’t been taken,
then no-one owns it and therefore, should be considered “new”, not “open”.
To me, “open” means that someone now owns the ticket and is working on a
solution.

-Robert

8

Known bug. Ticket #504. will be dealt with once i’m home from travelling.On Fri, May 25, 2001 at 12:42:16PM -0700, Robert Shaw wrote:

On Fri, May 25, 2001 at 09:04:41PM +0200, Jonas Liljegren wrote:

Feargal Reilly feargal@online.thecia.ie writes:

Hi,
This is an intentional bug…

When you view a ticket, by defalut, the system updates the status to
open if the current status is new, new essentially meaning
‘unread’. This came about as some people pointed out it was silly
having to update status everytime you took a ticket. You just happen
to use RT differently to most.

I would rather have it changing to open only then the ticket is
taken. Not then it’s viewed.

Yes, I agree, this is what I would prefer it do also. I don’t see any reason
to make a ticket open if it has never been “taken”. If it hasn’t been taken,
then no-one owns it and therefore, should be considered “new”, not “open”.
To me, “open” means that someone now owns the ticket and is working on a
solution.

-Robert

Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

…realized that the entire structure of the net could be changed to be made
more efficient, elegant, and spontaneously make more money for everyone
involved. It’s a marvelously simple diagram, but this form doesn’t have a way
for me to draw it. It’ll wait. -Adam Hirsch