Never mind the SQL logging question, I got it. Something really weird: in
the ticket insertion, I see no owner value at all. Here it is:
INSERT INTO Tickets
(Resolved, Priority, Starts, Creator, InitialPriority, SLA, Created,
LastUpdatedBy, Type, Queue, LastUpdated, Started, Due, Subject,
FinalPriority, Status)
VALUES ('1970-01-01 00:00:00', '1', '1970-01-01 00:00:00', '28', '1', NULL,
'2017-01-05 22:51:29', '28', 'ticket', '5', '2017-01-05 22:51:29',
'1970-01-01 00:00:00', '2017-01-07 22:51:29', 'Test', '50', 'new')
Of course, I see nothing for the custom field I set either. Still, why
would owner not be set in the initial ticket insertion? Later, I see this
insertion, for some reason:
INSERT INTO Groups
(Instance, LastUpdated, Name, Created, LastUpdatedBy, Domain, Description,
id, Creator)
VALUES ('1164', '2017-01-05 22:51:29', 'Owner', '2017-01-05 22:51:29',
'28', 'RT::Ticket-Role', NULL, '4856', '28')
I have no idea what that's about. I have to run, so there may be more in
the log file I'll get to tomorrow. But what's going on here, and could this
explain why owners don't show in search results but they do in ticket
displays? Thanks.
On Thu, Jan 5, 2017 at 1:40 PM, Alex Hall <ah...@autodist.com> wrote:
>
>
> On Mon, Nov 28, 2016 at 11:41 AM, Kenneth Marshall <k...@rice.edu> wrote:
>
>> On Mon, Nov 28, 2016 at 11:32:36AM -0500, Alex Hall wrote:
>> > Thanks, I didn't know that would happen. I did that to suppress the
>> email notification; we want users notified if their tickets change owners,
>> but only if that change is NOT from "nobody" to themselves.
>> >
>> > I just updated the script to record the transaction. It worked, because
>> I got the email I wanted suppressed, and the owner still changed. Oddly,
>> "nobody" is still the owner when I search for my ticket, though. Should I
>> flush a cache or something? Mason cache wouldn't have anything to do with
>> this, would it?
>>
>> Hi Alex,
>>
>> Well, that is not what I would have expected to happen. I do not know
>> enough
>> about the DB queries that are being run to generate the search results.
>> Probably,
>> my next step would be to look at the actual query and see where the
>> incorrect
>> results are being produced. I am not much help because we use PostgreSQL
>> as
>> the DB and not MySQL. Sorry, I cannot be of more assistance.
>>
>
> How do I view the actual query being used? Is there a way to get RT to
> store it, or some other trick? Thanks.
>
>>
>> Regards,
>> Ken
>>
>
>
>
> --
> Alex Hall
> Automatic Distributors, IT department
> ah...@autodist.com
>
--
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
