I have recently upgraded from rt2 to rt3. There was a post in May titled
"rt2 to rt3 db conversion problems". They explained how content from one
ticket was showing up in other tickets. This is happening to me. On a
ticket display it will show the proper content for say transaction 40532,
but then the Reply link for that transaction will link to 40369. My tickets
are getting scrambled. I did not see an answer to this post in May. Has
anyone figured this out?
Thanks,
Trish
Trish,
I have recently upgraded from rt2 to rt3. There was a post in May titled
“rt2 to rt3 db conversion problems”. They explained how content from one
ticket was showing up in other tickets. This is happening to me. On a
ticket display it will show the proper content for say transaction 40532,
but then the Reply link for that transaction will link to 40369. My tickets
are getting scrambled. I did not see an answer to this post in May. Has
anyone figured this out?
Can you tell us if things appear correct in the dumpfile that's
generated during the migration process? If so, then it's in the
import tool. otherwise, we can turn our eyes to the export tool.
Thanks,
Trish
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Things appear to be correct in the import file. Also, it may have nothing
to do with the import/export. So far this has happened twice and only when
adding new correspondence to a ticket. A watcher adds new correspondence to
an existing ticket. He then receives a correspondence notification, but the
text is not what he had typed. The system sends him a copy of
correspondence that had been made some time ago on a different ticket, even
by another user. The web ticket display shows the correct text for the
transaction, but when we try to reply from the web using that transaction we
once again get correspondence from the other ticket. This is really weird
and I am very concerned about the consequences of this kind of behavior. Is
it possible that the system is trying to reuse Transaction Ids? On this
last occurrence, the system should have been using new Transaction Ids from
the 4500s. When the switch occurred the old correspondence got an Id in the
4500s and the new correspondence got an Id in the 4300s. Also, both times
this has happened there were attachments to the correspondence. I don’t
know if that would make a difference.
-TrishFrom: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: Monday, July 21, 2003 7:30 PM
To: Trish Ford
Cc: rt-users@lists.fsck.com
Trish,
I have recently upgraded from rt2 to rt3. There was a post in May titled
“rt2 to rt3 db conversion problems”. They explained how content from one
ticket was showing up in other tickets. This is happening to me. On a
ticket display it will show the proper content for say transaction 40532,
but then the Reply link for that transaction will link to 40369. My
tickets
are getting scrambled. I did not see an answer to this post in May. Has
anyone figured this out?
Can you tell us if things appear correct in the dumpfile that's
generated during the migration process? If so, then it's in the
import tool. otherwise, we can turn our eyes to the export tool.
Thanks,
Trish
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Things appear to be correct in the import file. Also, it may have nothing
to do with the import/export. So far this has happened twice and only when
adding new correspondence to a ticket. A watcher adds new correspondence to
an existing ticket. He then receives a correspondence notification, but the
text is not what he had typed. The system sends him a copy of
correspondence that had been made some time ago on a different ticket, even
by another user. The web ticket display shows the correct text for the
transaction, but when we try to reply from the web using that transaction we
once again get correspondence from the other ticket. This is really weird
and I am very concerned about the consequences of this kind of behavior. Is
it possible that the system is trying to reuse Transaction Ids? On this
last occurrence, the system should have been using new Transaction Ids from
the 4500s. When the switch occurred the old correspondence got an Id in the
4500s and the new correspondence got an Id in the 4300s. Also, both times
this has happened there were attachments to the correspondence. I don’t
know if that would make a difference.
Ok. Phil points out that this is likely the importer bug reported in
ticket #2709: http://rt3.fsck.com/Ticket/Display.html?id=2709
Login as guest/guest. There’s a tool there to fix it as best as possible
in existing databases. I’m testing out a new release of the migration
toolset that should also fix it. If you’re up for trying a new import,
bounce me mail off list, and I’ll send you the current version of the
tool
-Trish
-----Original Message-----
From: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: Monday, July 21, 2003 7:30 PM
To: Trish Ford
Cc: rt-users@lists.fsck.comTrish,
I have recently upgraded from rt2 to rt3. There was a post in May titled
“rt2 to rt3 db conversion problems”. They explained how content from one
ticket was showing up in other tickets. This is happening to me. On a
ticket display it will show the proper content for say transaction 40532,
but then the Reply link for that transaction will link to 40369. My
tickets
are getting scrambled. I did not see an answer to this post in May. Has
anyone figured this out?Can you tell us if things appear correct in the dumpfile that’s
generated during the migration process? If so, then it’s in the
import tool. otherwise, we can turn our eyes to the export tool.Thanks,
Trish
–
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-usersHave you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.