Hello!
I just migrated from 3.0.12 to rt3.6.0. The imported data looks
okay, but
I get no result when I search for source ticket ids which are merged.
I can search for the destination ticket id, and I see the
merge transaction with the source id. But when I look for this
id I get no result. I finaly tried in the search box
fulltext:source_id and this works but is very slow!
regards!
Hello!
I want to refine my bug report. The problem occurs in the search bar in
the upper right.
If I modify the ticket id in the url or send an email to the source
id it works.
But if I search for the source id in web frontend, I get no result.On Thu, 2006-07-06 at 18:01 +0200, Sven Sternberger wrote:
I get no result when I search for source ticket ids which are merged.
I can search for the destination ticket id, and I see the
merge transaction with the source id. But when I look for this
id I get no result. I finaly tried in the search box
fulltext:source_id and this works but is very slow!
regards
sven
Hello!
the merge function in rt3.6 seems to be broken, after merge
I can’t find the ticket-id of the merged ticket,
I can’t find the subject,
I can’t find the content
with the search function. The merged ticket is still there but
I don’t have a chance to find it.
regards!
sven
btw:
An acknowledge of these bug report would be very nice
Hello!
the merge function in rt3.6 seems to be broken, after merge
I can’t find the ticket-id of the merged ticket,
Of either ticket or the ticket you merged into another one?
Merged tickets should entirely cease to have their own identities.
the merge function in rt3.6 seems to be broken, after merge
I can’t find the ticket-id of the merged ticket,Of either ticket or the ticket you merged into another one?
only the ticket which is merged (source)
Merged tickets should entirely cease to have their own identities.
but if I send a reply to a customer and afterwards I merge this ticket.
What happens when the customer calls me and give me his ticket id? I
have no chance to find his ticket.
I can’t find the subject,
I can’t find the content
I think this is valuable information which should be searchable.
sven
This is when an OnMerge scrip could be useful. Merge the ticket, notify
the source ticket’s owner of their new ticket number, problem solved.
Sven Sternberger wrote:> On Tue, 2006-07-18 at 10:56 -0400, Jesse Vincent wrote:
the merge function in rt3.6 seems to be broken, after merge
I can’t find the ticket-id of the merged ticket,Of either ticket or the ticket you merged into another one?
only the ticket which is merged (source)
Merged tickets should entirely cease to have their own identities.
but if I send a reply to a customer and afterwards I merge this ticket.
What happens when the customer calls me and give me his ticket id? I
have no chance to find his ticket.I can’t find the subject,
I can’t find the contentI think this is valuable information which should be searchable.
sven
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.comWe’re hiring! Come hack Perl for Best Practical: Careers — Best Practical Solutions
Drew Barnes
Applications Analyst
Raymond Walters College
University of Cincinnati
Merged tickets should entirely cease to have their own identities.
but if I send a reply to a customer and afterwards I merge this ticket.
What happens when the customer calls me and give me his ticket id? I
have no chance to find his ticket.
It should be the case that searching for the old ticket number will get
you the new ticket.
Jesse Vincent wrote:
It should be the case that searching for the old ticket number will get
you the new ticket.
Hi Jesse.
I started a thread about this very thing. When you say “searching for
the old ticket number” do you mean in the search box at the top? If so,
then no, the ticket does not come up. The example I used was this:
Say I have an existing ticket, #100. Some time later someone else opens
a new ticket (#200) that we determine to be the same thing as #100, so
we merge 200 back into 100.
In 3.4.5 we could key 200 or 100 into the search box and get the
information. In 3.6.0, we can only key 100 to get to the ticket. Is
that working as designed?
Thanks!
Barry
It should be the case that searching for the old ticket number will get
you the new ticket.
This is what I expected.
I have an 3.6 installation from tarball. The installation is upgraded
from 3.0.12. The search problem appears in tickets which are created
before and after migration.
The machine has an RHEL4 compatible installation.
If I just modify the url
(https://xxx.desy.de/Ticket/Display.html?id=42), and enter the id
directly in the url it works.
In the log files (rt and mysql) I see no warnings!
regards!
It should be the case that searching for the old ticket number will get
you the new ticket.This is what I expected.
I have an 3.6 installation from tarball. The installation is upgraded
from 3.0.12. The search problem appears in tickets which are created
before and after migration.
Ok, then yes, that sounds like a bug.
To all,
I concur, but not only that, a scrip should be created to notify the
original Requestor on a merge as well as the owner or whomever is
administrating the Queue could add the requestor name from the old
ticket (#100) to the ticket merged into (#200) by updating “people” of
ticket #200. That way the requestor of ticket #100 will always get the
communication you have set up a requestor to get. Now, if RT is not
showing you #200 when you search for #100, that is a bug, but that does
not remove the need for good admin scrips and communication on merges.
Kenn
LBNL
Drew Barnes wrote:
To all,
I concur, but not only that, a scrip should be created to notify the
original Requestor on a merge as well as the owner or whomever is
administrating the Queue could add the requestor name from the old
ticket (#100) to the ticket merged into (#200) by updating “people” of
ticket #200. That way the requestor of ticket #100 will always get the
communication you have set up a requestor to get. Now, if RT is not
showing you #200 when you search for #100, that is a bug, but that does
not remove the need for good admin scrips and communication on merges.
It’s not just the requestor that needs to be able to track the
eventual disposition - it is anyone that has ever had the
original number which the person doing the merge may not know.
I would hope that email responses with the old ticket ID would
land in the right place too.
Les Mikesell
les@futuresource.com