Our expirience with RT 2.0.8

We have been using RT 2.0.8 for a couple of weeks now (before RT1) and are
quite pleased with it. Some changes take getting used to but overaal a
great improvement.

We did a number of modifications, mostly so that the configuration
interface would not be visible and accessible to most our and our
customers would not see any information (not even uids) of other
customers. (dit this by if not in group OurCompany the don’t display this
field).

We have come across several changes and bugs in RT2 though. I have not had
time yet to try 2.0.9 so some might be fixed already.

First problem is with wrapping of tekst in messages. Wrapping seems to be
done at several point in RT. The input areas have some form of wrapping,
the libraries seem to do some wrapping here and there and the web
interface (perl/mason code) does some wrapping. Not all wrapping is done
at the same number of columns what makes comments enterd though the web
interface sometimes look funny. Maybe make the number of columns to wrap
at a global config setting? The wrapping of template output was mentioned
earlyer on the list.

When a user creates a new ticket through the web interface, but makes the
requestor field blank, RT somehow tries to send to
“Cc of west.nl Ticket #945’”:;
(toronto.west.nl is the host running RT)

When an attachment is requested, but the user is not authenticated, the
source of the login screen is returned. This is probably due to the fact
that content-type is set to text/plain for attachments. Was unable to test
thoroughly because couldn’t get wget to send the right cookie.

In the search page there is no “last page” link.

The <<First, <Previous, Next> and Last>> links in the ticket view only
seem to link to tickets in the currently displayed page of the search
results, not in all of the search results.

I have exptended the “Create Ticket in Queue…” button to display the
queue used in the first request in the search results (see attachment) per
default. I’ve tried but couldn’t get the queue of the currenltly viewed
ticket (ticket display pages) to display as default.

– arthur de jong - arthur@west.nl - west consulting b.v. –

CreateTicket (782 Bytes)

oops, wrong attachment, that was a working version, this one should be
cleaner.

– arthur de jong - arthur@west.nl - west consulting b.v. –

CreateTicket (587 Bytes)

Hi!

I’ve got a rather silly problem and was hoping somebody had
a workaround…

in Ticket.pm when trying to move a case without a owner to a new queue (from
the default)
it’ll blow up with a Mason Error as follows:

line 355: Can’t call method “fetchrow” on an undefined value

context: …
351: my $query = shift;
352: my @bind_values = @_;
353: my $sth = $self->SimpleQuery($query, @bind_values);
354:
355: return ($sth->fetchrow);

I assume it’s trying to find the Owner of the ticket?

Is this working as “Designed” or is it a bug.

This does “work around” the issue,

Doing a $self->Take() would force the person moving the case
around to become the owner , is that what really should happen though?

The other option is to force ownership into something like a Helpdesk
userid.

At least this way It does not fail for the user.

unless ($self->OwnerObj->Id) {
# Very Very kludgy…
# $self->Take();
$self->SetOwner(‘5’);
}

Edstrom Johan johan.edstrom@sca.com writes:

I’ve got a rather silly problem and was hoping somebody had
a workaround…

in Ticket.pm when trying to move a case without a owner to a new queue (from
the default)
it’ll blow up with a Mason Error as follows:

line 355: Can’t call method “fetchrow” on an undefined value

context: …
351: my $query = shift;
352: my @bind_values = @_;
353: my $sth = $self->SimpleQuery($query, @bind_values);
354:
355: return ($sth->fetchrow);

I assume it’s trying to find the Owner of the ticket?

Is this working as “Designed” or is it a bug.

I entered this as bug #1016, with the attached patch, which Jesse
seems to have found acceptable in intent if not in execution. It does
solve the problem.

Mike.

setowner.patch (516 Bytes)

The patch will work just fine, though you basically are “safer” using

Nobody->Id, rather than Nobody->Name.On Sun, Nov 25, 2001 at 11:00:04PM -0500, Michael Alan Dorman wrote:

Edstrom Johan johan.edstrom@sca.com writes:

I’ve got a rather silly problem and was hoping somebody had
a workaround…

in Ticket.pm when trying to move a case without a owner to a new queue (from
the default)
it’ll blow up with a Mason Error as follows:

line 355: Can’t call method “fetchrow” on an undefined value

context: …
351: my $query = shift;
352: my @bind_values = @_;
353: my $sth = $self->SimpleQuery($query, @bind_values);
354:
355: return ($sth->fetchrow);

I assume it’s trying to find the Owner of the ticket?

Is this working as “Designed” or is it a bug.

I entered this as bug #1016, with the attached patch, which Jesse
seems to have found acceptable in intent if not in execution. It does
solve the problem.

Mike.

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.