Problem with searching for requestor email address in RT 3.0.9?

I recently upgraded from RT 3.0.5 to 3.0.9. While I was at it, I added
the suggested indices and converted from myISAM to InnoDB tables, though
I doubt that those things caused the problem I’m seeing now.

Searching for requestors’ email addresses seems not to work at all. I
enter an address, hit search, RT thinks for a while, and then shows a
list of tickets, but the same list as before. And the search term
hasn’t been added to the list of search terms.

Do I need to do something like force perl to more thoroughly reload
things, or? I’ve restarted apache since the upgrade, of course, and
3.0.9 besides that seems to be running just fine.

-Dan

Daniel E. Eisenbud
eisenbud@cbio.mskcc.org
Computational Biology Center
Memorial Sloan-Kettering Cancer Center

I recently upgraded from RT 3.0.5 to 3.0.9. While I was at it, I added
the suggested indices and converted from myISAM to InnoDB tables, though
I doubt that those things caused the problem I’m seeing now.

Searching for requestors’ email addresses seems not to work at all. I
enter an address, hit search, RT thinks for a while, and then shows a
list of tickets, but the same list as before. And the search term
hasn’t been added to the list of search terms.

Do I need to do something like force perl to more thoroughly reload
things, or? I’ve restarted apache since the upgrade, of course, and
3.0.9 besides that seems to be running just fine.

Just to clarify, I just stopped and then started apache, and the problem
persists.

-Daniel

Daniel E. Eisenbud
eisenbud@cbio.mskcc.org
Computational Biology Center
Memorial Sloan-Kettering Cancer Center

I recently upgraded from RT 3.0.5 to 3.0.9. While I was at it, I added
the suggested indices and converted from myISAM to InnoDB tables, though
I doubt that those things caused the problem I’m seeing now.

Searching for requestors’ email addresses seems not to work at all. I
enter an address, hit search, RT thinks for a while, and then shows a
list of tickets, but the same list as before. And the search term
hasn’t been added to the list of search terms.

Do I need to do something like force perl to more thoroughly reload
things, or? I’ve restarted apache since the upgrade, of course, and
3.0.9 besides that seems to be running just fine.

Just to clarify, I just stopped and then started apache, and the problem
persists.

We’re still seeing this. Apparently nobody else is seeing it, or I’m
sure there would be lots of bug reports. Does anyone have any hints
about how to start debugging?

Thanks,
Daniel

Daniel E. Eisenbud
eisenbud@cbio.mskcc.org
Computational Biology Center
Memorial Sloan-Kettering Cancer Center

Here are the URLs RT produces for a search of all tickets in one of our
queues versus a search for tickets with a requestor like “foo” in the
same queue. Looking at the URLs, it looks like it includes the correct
query in the generated URL. However, the search isn’t narrowed, and the
new search term isn’t listed at the bottom of the page.

http://www.cbio.mskcc.org/rt/Search/Listing.html?Bookmark=FrT%253B%25402%257C%25250%257C%25242%257C26&CompileRestriction=1&OwnerOp=%3D&ValueOfOwner=&RequestorOp=LIKE&ValueOfRequestor=&SubjectOp=LIKE&ValueOfSubject=&QueueOp=%3D&ValueOfQueue=16&PriorityOp=<&ValueOfPriority=&DateType=Created&DateOp=<&ValueOfDate=&AttachmentField=Content&AttachmentFieldOp=LIKE&ValueOfAttachmentField=&StatusOp=%3D&ValueOfStatus=&RowsPerPage=50&TicketsSortBy=id&TicketsSortOrder=ASC&RefreshSearchInterval=-1&Action=Search

http://www.cbio.mskcc.org/rt/Search/Listing.html?Bookmark=FrT%253B%25402%257C%25252%257C%25242%257C26%25258%257C%252411%257CDESCRIPTION%25245%257CFIELD%25248%257COPERATOR%25245%257CVALUE%252422%257CQueue%2520%253D%2520faculty-search%25245%257CQueue%25241%257C%253D%252414%257Cfaculty-search%25242%257C27&CompileRestriction=1&OwnerOp=%3D&ValueOfOwner=&RequestorOp=LIKE&ValueOfRequestor=foo&SubjectOp=LIKE&ValueOfSubject=&QueueOp=%3D&ValueOfQueue=&PriorityOp=<&ValueOfPriority=&DateType=Created&DateOp=<&ValueOfDate=&AttachmentField=Content&AttachmentFieldOp=LIKE&ValueOfAttachmentField=&StatusOp=%3D&ValueOfStatus=&CustomFieldOp36=LIKE&CustomField36=&CustomFieldOp37=LIKE&CustomField37=&CustomFieldOp38=LIKE&CustomField38=&RowsPerPage=50&TicketsSortBy=id&TicketsSortOrder=ASC&RefreshSearchInterval=-1&Action=Search

-DanielOn Mon, Mar 08, 2004 at 02:21:39PM -0500, Daniel E. Eisenbud eisenbud@cbio.mskcc.org wrote:

On Tue, Mar 02, 2004 at 11:52:53AM -0500, Daniel E. Eisenbud eisenbud@cbio.mskcc.org wrote:

On Tue, Mar 02, 2004 at 11:38:54AM -0500, Daniel E. Eisenbud eisenbud@cbio.mskcc.org wrote:

I recently upgraded from RT 3.0.5 to 3.0.9. While I was at it, I added
the suggested indices and converted from myISAM to InnoDB tables, though
I doubt that those things caused the problem I’m seeing now.

Searching for requestors’ email addresses seems not to work at all. I
enter an address, hit search, RT thinks for a while, and then shows a
list of tickets, but the same list as before. And the search term
hasn’t been added to the list of search terms.

Do I need to do something like force perl to more thoroughly reload
things, or? I’ve restarted apache since the upgrade, of course, and
3.0.9 besides that seems to be running just fine.

Just to clarify, I just stopped and then started apache, and the problem
persists.

We’re still seeing this. Apparently nobody else is seeing it, or I’m
sure there would be lots of bug reports. Does anyone have any hints
about how to start debugging?

Thanks,
Daniel


Daniel E. Eisenbud
eisenbud@cbio.mskcc.org
Computational Biology Center
Memorial Sloan-Kettering Cancer Center


rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Daniel E. Eisenbud
eisenbud@cbio.mskcc.org
Computational Biology Center
Memorial Sloan-Kettering Cancer Center

Also, I turned on “debug” level logging, and there’s nothing interesting
related to this, just normal messages saying
[Mon Mar 8 19:32:38 2004] [debug]: limiting to 50 rows (/usr/local/rt3/lib/RT/Interface/Web.pm:639)

-DanielOn Mon, Mar 08, 2004 at 02:34:53PM -0500, Daniel E. Eisenbud eisenbud@cbio.mskcc.org wrote:

Here are the URLs RT produces for a search of all tickets in one of our
queues versus a search for tickets with a requestor like “foo” in the
same queue. Looking at the URLs, it looks like it includes the correct
query in the generated URL. However, the search isn’t narrowed, and the
new search term isn’t listed at the bottom of the page.

http://www.cbio.mskcc.org/rt/Search/Listing.html?Bookmark=FrT%253B%25402%257C%25250%257C%25242%257C26&CompileRestriction=1&OwnerOp=%3D&ValueOfOwner=&RequestorOp=LIKE&ValueOfRequestor=&SubjectOp=LIKE&ValueOfSubject=&QueueOp=%3D&ValueOfQueue=16&PriorityOp=<&ValueOfPriority=&DateType=Created&DateOp=<&ValueOfDate=&AttachmentField=Content&AttachmentFieldOp=LIKE&ValueOfAttachmentField=&StatusOp=%3D&ValueOfStatus=&RowsPerPage=50&TicketsSortBy=id&TicketsSortOrder=ASC&RefreshSearchInterval=-1&Action=Search

http://www.cbio.mskcc.org/rt/Search/Listing.html?Bookmark=FrT%253B%25402%257C%25252%257C%25242%257C26%25258%257C%252411%257CDESCRIPTION%25245%257CFIELD%25248%257COPERATOR%25245%257CVALUE%252422%257CQueue%2520%253D%2520faculty-search%25245%257CQueue%25241%257C%253D%252414%257Cfaculty-search%25242%257C27&CompileRestriction=1&OwnerOp=%3D&ValueOfOwner=&RequestorOp=LIKE&ValueOfRequestor=foo&SubjectOp=LIKE&ValueOfSubject=&QueueOp=%3D&ValueOfQueue=&PriorityOp=<&ValueOfPriority=&DateType=Created&DateOp=<&ValueOfDate=&AttachmentField=Content&AttachmentFieldOp=LIKE&ValueOfAttachmentField=&StatusOp=%3D&ValueOfStatus=&CustomFieldOp36=LIKE&CustomField36=&CustomFieldOp37=LIKE&CustomField37=&CustomFieldOp38=LIKE&CustomField38=&RowsPerPage=50&TicketsSortBy=id&TicketsSortOrder=ASC&RefreshSearchInterval=-1&Action=Search

-Daniel

Daniel E. Eisenbud
eisenbud@cbio.mskcc.org
Computational Biology Center
Memorial Sloan-Kettering Cancer Center

Huh, that seems to fix it. I don’t understand RT well enough to have
any idea why, and why nobody else saw this (assuming they didn’t, that
is.) Also, there are other places in html/Search with |u, dunno if any
of them should be |un. I only changed the one in PickRestriction.

Great. that fix will be in 3.0.10. And actually, we did see it, just
manifesting slightly differently. I think that the differing behavior
has to do with different code in various versions of CGI.pm.

A user of mine reported the same bug to me today. I verified it. As Daniel
here reported in his several posts to the list earlier this month, turning on
debugging shows nothing at all regarding the issue. If you go to start a new
search, and try any search on requestor email address (contains, is, is not,
etc) nothing shows up. The search URL is built properly (you see the
RequestorOp=LIKE&ValueOfRequestor=foo in the location bar URL at least) but no
tickets.

Found this when searching the list archives to see if anyone else reported it.
Nobody seemed to respond to Daniel. I’m Cc’ing the bug report queue.

Unlike Daniel, I haven’t done any changes to my SQL so he’s correct that this
wasnt the cause of his problem. All searches for other fields seem to work,
just not searches on requestor email addresses.

http://lists.fsck.com/pipermail/rt-users/2004-March/021226.html

Daniel E. Eisenbud eisenbud at cbio.mskcc.org
Tue Mar 2 11:38:54 EST 2004

I recently upgraded from RT 3.0.5 to 3.0.9. While I was at it, I added
the suggested indices and converted from myISAM to InnoDB tables, though
I doubt that those things caused the problem I’m seeing now.

Searching for requestors’ email addresses seems not to work at all. I
enter an address, hit search, RT thinks for a while, and then shows a
list of tickets, but the same list as before. And the search term
hasn’t been added to the list of search terms.

Do I need to do something like force perl to more thoroughly reload
things, or? I’ve restarted apache since the upgrade, of course, and
3.0.9 besides that seems to be running just fine.

-Dan

Please DO NOT send mail to rt-users and rt-bugs at the same time. It
causes ticket-storms in RT when users reply to the mailinglist and
submit a new bug at the same time.

IIRC, a fix that made it into 3.0.10 resolved dan’s issues.On Mar 31, 2004, at 12:12 PM, Craig Schenk wrote:

A user of mine reported the same bug to me today. I verified it. As
Daniel
here reported in his several posts to the list earlier this month,
turning on
debugging shows nothing at all regarding the issue. If you go to start
a new
search, and try any search on requestor email address (contains, is,
is not,
etc) nothing shows up. The search URL is built properly (you see the
RequestorOp=LIKE&ValueOfRequestor=foo in the location bar URL at
least) but no
tickets.

Found this when searching the list archives to see if anyone else
reported it.
Nobody seemed to respond to Daniel. I’m Cc’ing the bug report queue.

Unlike Daniel, I haven’t done any changes to my SQL so he’s correct
that this
wasnt the cause of his problem. All searches for other fields seem to
work,
just not searches on requestor email addresses.

http://lists.fsck.com/pipermail/rt-users/2004-March/021226.html

Daniel E. Eisenbud eisenbud at cbio.mskcc.org
Tue Mar 2 11:38:54 EST 2004

I recently upgraded from RT 3.0.5 to 3.0.9. While I was at it, I added
the suggested indices and converted from myISAM to InnoDB tables,
though
I doubt that those things caused the problem I’m seeing now.

Searching for requestors’ email addresses seems not to work at all. I
enter an address, hit search, RT thinks for a while, and then shows a
list of tickets, but the same list as before. And the search term
hasn’t been added to the list of search terms.

Do I need to do something like force perl to more thoroughly reload
things, or? I’ve restarted apache since the upgrade, of course, and
3.0.9 besides that seems to be running just fine.

-Dan


rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

PGP.sig (186 Bytes)

Craig,

could this be a problem with the version of DBIx::SearchBuilder you’re
using? Have you got version 0.97 installed?

Upgrading to 0.97 definitely fixed some search on owner problems users
were experiencing here.

Max

A user of mine reported the same bug to me today. I verified it. As
Daniel