2.1.74

RT Developers
1

Fixes an additional bug in custom field searching.
It’s out now.

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.

2

Similar problem in 2.1.74 as in 2.1.73.

System error

error: Invalid <%args> section line at
/usr/local/rt3/share/html/Ticket/Elements/AddWatchers line 96
context: …
92: $UserField => ‘Name’
93: $UserOp => ‘=’
94: $UserString => undef
95: $GroupField => ‘Name’
96: GroupOp => ‘=’
97: GroupString => undef
98: </%ARGS>

Putting a $ in front of GroupOp and GroupString resolved the error.

Derek----- Original Message -----
From: Jesse Vincent
To: rt-devel@fsck.com
Sent: Tuesday, February 18, 2003 12:26 AM
Subject: [rt-devel] 2.1.74

Fixes an additional bug in custom field searching.
It’s out now.

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

3

thx.On Tue, Feb 18, 2003 at 02:48:55PM -0500, Derek Buttineau wrote:

Similar problem in 2.1.74 as in 2.1.73.

System error

error: Invalid <%args> section line at
/usr/local/rt3/share/html/Ticket/Elements/AddWatchers line 96
context: …
92: $UserField => ‘Name’
93: $UserOp => ‘=’
94: $UserString => undef
95: $GroupField => ‘Name’
96: GroupOp => ‘=’
97: GroupString => undef
98: </%ARGS>

Putting a $ in front of GroupOp and GroupString resolved the error.

Derek

----- Original Message -----
From: Jesse Vincent
To: rt-devel@fsck.com
Sent: Tuesday, February 18, 2003 12:26 AM
Subject: [rt-devel] 2.1.74

Fixes an additional bug in custom field searching.
It’s out now.

–
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

4

2.1.75 exists. Unless someone finds an interesting bug in the next 24
hours, 2.1.75 becomes beta 2.

-jOn Tue, Feb 18, 2003 at 02:48:55PM -0500, Derek Buttineau wrote:

Similar problem in 2.1.74 as in 2.1.73.

System error

error: Invalid <%args> section line at
/usr/local/rt3/share/html/Ticket/Elements/AddWatchers line 96
context: …
92: $UserField => ‘Name’
93: $UserOp => ‘=’
94: $UserString => undef
95: $GroupField => ‘Name’
96: GroupOp => ‘=’
97: GroupString => undef
98: </%ARGS>

Putting a $ in front of GroupOp and GroupString resolved the error.

Derek

----- Original Message -----
From: Jesse Vincent
To: rt-devel@fsck.com
Sent: Tuesday, February 18, 2003 12:26 AM
Subject: [rt-devel] 2.1.74

Fixes an additional bug in custom field searching.
It’s out now.

–
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

5

I think that etc/RT_SiteConfig.pm needs to contain the following by default:

Needed to override previously declared variables

$WebURL = $WebBaseURL . $WebPath . “/”;
$WebImagesURL = $WebURL.“NoAuth/images/”;
$LogoURL = $WebImagesURL.“rt.jpg”;
1;

rather than simply:

1;

My customisation of $WebBaseURL didn’t have the desired effect because the
variable $WebURL (and thus $WebImagesURL (and thus $LogoURL)) isn’t
re-declared. While this gaff is obvious now that I have run into it I
didn’t find the documentation clear (or I wasn’t thinking straight) and I
ended up believing that I had a syntax error in etc/RT_SiteConfig.pm that
was causing the problem.

Just at thought.

-Brook

= /// /// /// /// _/ _/ Brook Schofield =
= _/ _/ _/ _/ _/ _/ _/ _/ _/ / B.Schofield@mailbox.gu.edu.au =
= // /// _/ _/ _/ _/ // Ph: +61 7 387 53779 - WCN 0.28 =
= _/ _/ _/ _/ _/ _/ _/ _/ _/ / Directory Services Integration =
= /// / / /// /// _/ _/ Griffith University QLD 4111 =

6

Agreed RT_SiteConfig doesn’t behave the way you would expect. Anytime you
set a SiteConfig variable you must make sure that you also copy over all
the instances where that variable is used from the RT_Config.

A solution would be for RT_Config and RT_SiteConfig to have their own perl
package names, then in RT_Config any where a variable is defined check to
see if the RT_SiteConfig::Variable is set.

Ie:
package RT_Config;
use RT_SiteConfig;
my $Foo = $RT_SiteConfig::Foo || “DefaultFoo”;

Matt