RT 2.0.14-pre1

RT Developers
1

Over the next month, you should see several pre-releases leading up to
RT 2.0.14 at the end of july…

I wouldn’t yet recommend this pre-release for production, but I would appreciate
success/failure supports.

-j

2002-06-26 15:22 jesse

* lib/RT/Interface/Web.pm:

support for mason 1.1

2002-06-26 15:19 jesse

* Makefile, bin/mason_handler.fcgi, bin/webmux.pl,
webrt/Admin/Queues/GroupRights.html,
webrt/Admin/Queues/UserRights.html, webrt/Elements/ListActions,
webrt/Ticket/Elements/ShowBasics, webrt/Ticket/Elements/ToolBar:

Adding support for mason 1.10

2002-06-26 15:15 jesse

* lib/RT/Action/Notify.pm:

Fixed notify cc behavior

2002-06-26 15:13 jesse

* lib/RT/Action/SendEmail.pm:

Fixed pseudo-list syntax in To: lines

2002-06-26 15:09 jesse

* webrt/Search/Bulk.html:

Added support for bulk comment/reply

2002-05-03 02:07 jesse

* lib/RT/Ticket.pm:

RT-Ticket: 1369
RT-Status: resolved

When a ticket has another merged into it, it now has its "LastUpdated" date
updated

2002-05-03 01:58 jesse

* lib/RT/Ticket.pm:

RT-Ticket: 1412
RT-status: resolved

Fixed a docs bug in Ticket->Import which didn't make it clear that Import
took an "Id" parameter and "Create" didn't.

2002-05-03 01:54 jesse

* webrt/autohandler:

rt-ticket: 1410
rt-status: resolved

Applied a patch from rich lafferty which prevented NoAuth from not
requiring authentication on some fastcgi setups.

A similar bug bit SelfService.

This commit fixes that one too.

2002-05-03 01:51 jesse

* Makefile:

RT-Ticket: 1272
rt-status: resolved

Applied a patch from Ilya Martynov which allows make insert to work
in a scenario where DESTDIR is being set to something funny This may be necessary when installing into AFS

2002-05-03 01:36 jesse

* lib/RT/Action/SendEmail.pm:

RT-Ticket: 1367
RT-Status: resolved

Added a check which only sets precedence to bulk if it's not already set,
say by a template.

2002-05-03 01:30 jesse

* lib/RT/Interface/Email.pm:

RT-Ticket: 1370
RT-Status: resolvedFrom: Jason Edgecombe <jedgecombe@carolina.rr.com>
To: rt-devel@lists.fsck.com
Subject: [rt-devel] An oversite in Interface/Email.pm

Hi,

   I found an problem in Interface/Email.pm when I was modifying
   enhanced mailgate. I have attached a diff of the modifications.

   In the function MailError, it assumes MIMIEOBJ is defined. I added a
   simple "if" test to only run $MIMEOBJ->sync_headers if $MIMEOBJ is defined.

2002-05-03 01:24 jesse

* lib/RT/Action/SendEmail.pm:

RT-Ticket: 1348
RT-Status: resolved

Fixed a bug in mail sending that improperly quoted the usernames of users
who had " in their names

2002-04-29 00:39 jesse

* lib/RT.pm:

Fixed a tiny typo

2002-04-28 23:46 jesse

* lib/RT.pm:

Fixed up the rt log messages.

2002-04-21 02:14 jesse

* lib/RT/Interface/Web.pm:

Fixed a couple bugs in setting owners that were only revealed by the poor data
validation on rt.cpan.org

2002-04-21 02:06 jesse

* lib/RT/Ticket.pm:

Fixed a couple bugs in setting owners that were only revealed by the poor data
validation on rt.cpan.org

2002-04-19 00:32 jesse

* Makefile:

Adding a new Makefile target to ease packaging.

2002-04-18 12:47 jesse

* lib/RT/GroupMember.pm:

RT-Ticket: 1385
RT-Broken-In: 2.0.0
RT-Broken-In: 2.0.1
RT-Broken-In: 2.0.2
RT-Broken-In: 2.0.3
RT-Broken-In: 2.0.4
RT-Broken-In: 2.0.5
RT-Broken-In: 2.0.6
RT-Broken-In: 2.0.7
RT-Broken-In: 2.0.8
RT-Broken-In: 2.0.9
RT-Broken-In: 2.0.10
RT-Broken-In: 2.0.11
RT-Broken-In: 2.0.12
RT-Broken-In: 2.0.13
RT-Status: resolved

GroupMemmber was looking for the "ModifyGroups" right, when it should have
been looking for the "AdminGroups" right

2002-04-05 10:24 jesse

* webrt/Ticket/Update.html:

RT-Ticket: 1330
RT-Status: Resolved

Fixed an html escaping bug in Ticket/Update.html

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

2

Jesse Vincent jesse@bestpractical.com writes:

Over the next month, you should see several pre-releases leading up to
RT 2.0.14 at the end of july…

There appears to be a bug in receiving mail messages with long subject
headers containing folding whitespace (an error occurs, and the
message is not recorded).

Is this a know issue? Maybe I can track it down before the 2.0.14
release. How much time do I get? :wink:

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

3

Bruce Campbell bc@ripe.net writes:

There appears to be a bug in receiving mail messages with long subject
headers containing folding whitespace (an error occurs, and the
message is not recorded).

Would that be more accurately, when the subject line is longer than the
SQL field, RT borks ?

I think the limit is 255 characters, and we don’t hit this one.

Header folding was fixed before though.

Really? I’ll have to check the CVS, thanks.

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

4

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE writes:

Would that be more accurately, when the subject line is longer than the
SQL field, RT borks ?

I think the limit is 255 characters, and we don’t hit this one.

Actually, the limit is 100 characters, for transactions.data. Older
PostgreSQL versions silently truncated overlong values for VARCHAR
columns, but newer ones (since 7.2 or so) don’t.

Looks like I have to restructure the whole database. :-/

Jesse, maybe it’s a good idea to use TEXT fields instead of VARCHAR
fields when creating new PostgreSQL databases? According to the
documentation, there is no performance difference.

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

5

Actually, the limit is 100 characters, for transactions.data. Older
PostgreSQL versions silently truncated overlong values for VARCHAR
columns, but newer ones (since 7.2 or so) don’t.

Urk. they changed that behavior?

Looks like I have to restructure the whole database. :-/

Jesse, maybe it’s a good idea to use TEXT fields instead of VARCHAR
fields when creating new PostgreSQL databases? According to the
documentation, there is no performance difference.

Hm. are there no other tradeoffs, or are texts now just superlong varchars?

–
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

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

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

6

Jesse Vincent jesse@bestpractical.com writes:

Actually, the limit is 100 characters, for transactions.data. Older
PostgreSQL versions silently truncated overlong values for VARCHAR
columns, but newer ones (since 7.2 or so) don’t.

Urk. they changed that behavior?

Yes, I think so:

Jesse, maybe it’s a good idea to use TEXT fields instead of VARCHAR
fields when creating new PostgreSQL databases? According to the
documentation, there is no performance difference.

Hm. are there no other tradeoffs, or are texts now just superlong
varchars?

I’m not aware of any tradeoffs, and the documentation suggests there
aren’t any.

But I’m going to ask on the PostgeSQL mailing lists to be sure.

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

7

“JV” == Jesse Vincent jesse@bestpractical.com writes:

Actually, the limit is 100 characters, for transactions.data. Older
PostgreSQL versions silently truncated overlong values for VARCHAR
columns, but newer ones (since 7.2 or so) don’t.

JV> Urk. they changed that behavior?

Yes. This is a change from 7.1 to 7.2. Technically, it is more SQL
standards compliant to reject the query than to silently alter it to
make the result fit into the allotted space.

JV> Hm. are there no other tradeoffs, or are texts now just superlong varchars?

I think text == varchar(2^24-1) or something about like that. My
feeling is that varchar() of a given size is mainly for documenting
your structure and expected use. The data storage is not that
different. Perhaps you save a byte or two by having smaller length
counters for shorter varchars, but I don’t know.

8

Vivek Khera khera@kcilink.com writes:

I think text == varchar(2^24-1) or something about like that. My
feeling is that varchar() of a given size is mainly for documenting
your structure and expected use. The data storage is not that
different. Perhaps you save a byte or two by having smaller length
counters for shorter varchars, but I don’t know.

Some people claim that internally, a TEXT column is represented by an
offset into a different table, but this is not the case, at least if
a row stays below the TOAST limit (somewhere around 8 kilobytes).

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

9

It seems to me like the lightest-weight solution here is to create and
document an alternate pg 7.2+ schema for RT 2.0.x and create a similar
schema for the 2.1.x series as the “native” pg schema.

Slightly longer term is to drop a proper exception system into DBIx::SearchBuilder so that it can cope cleanly.

-jOn Mon, Jul 01, 2002 at 08:19:10PM +0200, Florian Weimer wrote:

Vivek Khera khera@kcilink.com writes:

I think text == varchar(2^24-1) or something about like that. My
feeling is that varchar() of a given size is mainly for documenting
your structure and expected use. The data storage is not that
different. Perhaps you save a byte or two by having smaller length
counters for shorter varchars, but I don’t know.

Some people claim that internally, a TEXT column is represented by an
offset into a different table, but this is not the case, at least if
a row stays below the TOAST limit (somewhere around 8 kilobytes).

–
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

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

10

Jesse Vincent jesse@bestpractical.com writes:

It seems to me like the lightest-weight solution here is to create and
document an alternate pg 7.2+ schema for RT 2.0.x and create a similar
schema for the 2.1.x series as the “native” pg schema.

Yes, and while you are at it, you should offer a way to choose the
column type of the ticket ID columns. AFAIK, some people would like
to have int8 ticket IDs. :wink:

Slightly longer term is to drop a proper exception system into
DBIx::SearchBuilder so that it can cope cleanly.

BTW, rt-mailgate should return a special error code to signal the MTA
that the database is temporarily unavailable:

— rt-gate 2002/07/01 15:42:39 1.1
+++ rt-gate 2002/07/01 15:56:02
@@ -39,7 +39,11 @@
LoadConfig();

#Connect to the database and get RT::SystemUser and RT::Nobody loaded
-DBConnect();
+eval { DBConnect(); };
+if ($@) {

  • print “$@\n”;
  • exit 57; # magic exit status for our Exim config
    +}

#Drop setgid permissions
RT::DropSetGIDPermissions();

After such a change, mail doesn’t get lost just because you are
restarting your database. (You have to drop the “print” for some
MTAs, and change the exit status to 67 or something like that.)

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

11

“FW” == Florian Weimer Weimer@CERT.Uni-Stuttgart.DE writes:

FW> #Connect to the database and get RT::SystemUser and RT::Nobody loaded
FW> -DBConnect();
FW> +eval { DBConnect(); };
FW> +if ($@) {
FW> + print “$@\n”;
FW> + exit 57; # magic exit status for our Exim config
FW> +}

The right way is to require sysexits.ph and then return &EX_TEMPFAIL
on the temp failure. On FreeBSD, the tempfail is 75. Personally, I’d
emit the error as a warn rather then print.

Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

12

The right way is to require sysexits.ph and then return &EX_TEMPFAIL
on the temp failure. On FreeBSD, the tempfail is 75. Personally, I’d
emit the error as a warn rather then print.

I’d actually probably do it as $RT::Logger->error(), but I’m weird that way.

–
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

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

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

13

The right way is to require sysexits.ph and then return &EX_TEMPFAIL
on the temp failure. On FreeBSD, the tempfail is 75. Personally, I’d
emit the error as a warn rather then print.

I’d take a patch to do this for 2.0.x if it was inside of a conditional
with a config variable, since adding a dependency on sysexits.ph (which will
require users to much with h2ph) within the 2.0.x series makes me a bit
uncomfortable, since I’ve seen lots of h2ph wackiness in the past.

-j

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