September 2004 - dev - OTRS mailing lists

genericagent.pm problem?
by Peter Gervai 20 Sep '04

20 Sep '04

I think it's a COnfig/GenericAgent.pm (the config) issue, but maybe GA shouldn't just plainly die. Problem is at: if ($Param{Config}->{New}->{Queue}) { if ($Self->{NoticeSTDOUT}) { print " - Move Ticket $Ticket to Queue '$Param{Config}->{New}->{Queue}'\n"; print " == QO:'" . $Self->{QueueObject} . "'\n"; #line by me } $Self->{TicketObject}->MoveTicket( QueueID => $Self->{QueueObject}->QueueLookup(Queue=>$Param{Config}->{New}->{Queue}, Cache => 1), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ here UserID => $Param{UserID}, TicketID => $Param{TicketID}, ); } problem is: $Self->{QueueObject} == undef, and the job dies on that. My other problem is that I cannot figure out now why, or what causes the problem.... peter

2 2

bulk in 2.0
by Peter Gervai 20 Sep '04

20 Sep '04

I installed the cvs HEAD version on my test machine and bulk seems to be gone despite the Default.pm setting switching it on. Shouldn't be? Linking seems to be happening, but is there any details on the planning of its features? (I have ideas, but I wouldn't like to waste anyone's time if not asked.) Peter -- Now using M2, Opera's e-mail client: http://www.opera.com/m2/

3 2

Re: [dev] Re: PostgreSQL Schema Problem
by Robert L Mathews 09 Sep '04

09 Sep '04

At 9/9/04 3:49 AM, Peter Gervai wrote: >...that reminded me to ask about whether it's good to use fixed length >varchar under postgres when the docs advise using text? Yes, that's okay. The types "text" and "varchar" are treated almost identically by PostgreSQL, except that varchar enforces a maximum length (which can actually be good in some cases, to prevent something from accidentally inserting 1 MB of data into an "e-mail address" field, for example). There's no speed or storage space difference. -- Robert L Mathews, Tiger Technologies http://www.tigertech.net/ "Ignorance more frequently begets confidence than does knowledge." -- Darwin

1 0

CVS: 1.3 branch!
by Martin Edenhofer 09 Sep '04

09 Sep '04

Hi, today we created a cvs branch for OTRS 1.3. That means this branch will have all future bug fixes for OTRS 1.3.x (just bug fixes no new features). So the cvs (HEAD) is ready for new features for OTRS 2.0 like: o Workflow feature o Ticket ACL feature o Role feature o Master Ticket feature o Linkin Objects o SMIME support o PGP support To checkout the 1.3 branch use: =============================== "cvs -z3 -d :pserver:<user>@cvs.otrs.org:/home/cvs co -r rel-1_3 otrs" To checkout the cvs HEAD use: ============================= "cvs -z3 -d :pserver:<user>@cvs.otrs.org:/home/cvs co otrs" Thanks, happy coding! .-) Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

1 0

v1.3b4 bugs: charset hardwired and cosmetics in customer.pl
by Peter Gervai 09 Sep '04

09 Sep '04

Hello, What do you prefer: bugs in the bugzilla or bugs here? :) Anyway, now here some. * customer.pl shows red $Quote{"} on the top when there is nothing to say ($Data{"Message"} is empty?) Okay, about charsets. I'm fighting with them since we don't use either 8859-1 (latin1) nor 8859-15 (latinEuro1). I'd like to use utf-8 as web charset (agent, customer) and 8859-2 for output email (due stupid stinky windows clients). Many modules use 8859-15 hardwired (egrep 8859-15 `find ~otrs/ -type f`) which is bad. Some patches against index.pl and cutomer.pl, and I hope I did get it right. I would rather have a DefaultCharset and DefaultEmailCharset, but for now I don't have the time to cross-check all the code. :( --- old/index.pl 2004-09-08 11:22:42.000000000 +0200 +++ index.pl 2004-09-08 11:25:00.000000000 +0200 @@ -428,7 +428,7 @@ if ($EmailObject->Send( To => $UserData{UserEmail}, Subject => $Subject, - Charset => 'iso-8859-15', + Charset => $CommonObject{ConfigObject}->Get('DefaultCharset'), Type => 'text/plain', Body => $Body)) { print $CommonObject{LayoutObject}->Login( --- old/customer.pl 2004-09-08 11:22:42.000000000 +0200 +++ customer.pl 2004-09-08 11:25:57.000000000 +0200 @@ -372,7 +372,7 @@ if ($EmailObject->Send( To => $UserData{UserEmail}, Subject => $Subject, - Charset => 'iso-8859-15', + Charset => $CommonObject{ConfigObject}->Get('DefaultCharset'), Type => 'text/plain', Body => $Body)) { print $CommonObject{LayoutObject}->CustomerLogin( @@ -447,7 +447,7 @@ if (!$EmailObject->Send( To => $GetParams{UserEmail}, Subject => $Subject, - Charset => 'iso-8859-15', + Charset => $CommonObject{ConfigObject}->Get('DefaultCharset'), Type => 'text/plain', Body => $Body)) { print $CommonObject{LayoutObject}->CustomerHeader(Area => 'Core', Title => 'Error'); -- Now using M2, Opera's e-mail client: http://www.opera.com/m2/

1 0

Re: PostgreSQL Schema Problem
by Robert L Mathews 09 Sep '04

09 Sep '04

On Mon, 26 Jul 2004 , Arne Georg Gleditsch wrote: >* Robert L Mathews >> I have also discovered several other trivially fixable issues that >> dramatically slow down OTRS with PostgreSQL (many of the SQL queries are >> made in a way that prevents PostgreSQL from using bigint indexes); I'll >> post more about them separately and try to provide a patch that fixes it >> once I'm confident I've found them all. > >I've posted about this before, but there was no response at the time: >http://article.gmane.org/gmane.comp.otrs.user/2898 . My suggestion is >still to ditch the ridiculous bigint-serials. 32 bits are going to be >enough for everyone. > >(Yes, these are "famous last words", but if anyone, ever, should need >more than 32 bits (which I have a hard time imagining), they'll >certainly be dimensioned to afford special-case hacking of the schema >and source code for their own installation. The sheer volume of data >in the postgres database implied by needing bigint-serials is not >something either hardware or software is going to cope with without >serious herding anyway.) As a late followup to this, I have submitted a patch that solves this problem, in OTRS bugzilla: http://bugs.otrs.org/show_bug.cgi?id=518 It makes a huge difference to OTRS performance on PostgreSQL when you have more than a few thousand tickets. -- Robert L Mathews, Tiger Technologies http://www.tigertech.net/ "Ignorance more frequently begets confidence than does knowledge." -- Darwin

2 1

CustomerPanelOwnSelection
by Peter Gervai 08 Sep '04

08 Sep '04

Why CustomerPanelOwnSelection uses 'id' instead of 'name'? As far as I can see id's are never shown on the interface, so I have to crawl the database for them. Peter

2 1

Problem with initial_insert.sql (patch attached)
by Robert L Mathews 08 Sep '04

08 Sep '04

I'm now trying OTRS 1.3 beta -- it generally looks good. I'm going to send along a few patches for problems I've noticed, mainly with PostgreSQL. The first is that the "initial_insert.sql" script doesn't work on my copy with a clean install; one of the lines violates some of the "NOT NULL" constraints of the ticket_history table. A patch is attached to make it work properly. (I would paste it inline, but it has long lines and it would get wrapped, making it not apply properly. Hopefully the list will allow the small attachment; if not, perhaps I can send it to Robert or Martin directly?) -- Robert L Mathews, Tiger Technologies http://www.tigertech.net/ "Ignorance more frequently begets confidence than does knowledge." -- Darwin

2 1

Convert OTRS database from SQL_ASCII to UNICODE
by Jens Richter 01 Sep '04

01 Sep '04

Hallo, how can I convert the OTRS database from SQL_ASCII to UNICODE. Is it possible to convert the database? Thanks Jens

1 0

session timeout question
by Adrian Chadd 01 Sep '04

01 Sep '04

Hi all, I've hit a bit of a snag with session timeouts in OTRS. Specifically, the hard session timeout value is a bit inflexible - people will leave their browsers on overnight and continue using OTRS when they arrive in the office in the morning. A timeout of 24 hours let this work, but only up until 24 hours. The session would then go dead right on time - in the middle of their work. I've written a patch to store a new key in the session information, UserSessionLastTime. It is updated with time() whenever the session information is read or updated. I then use this to check whether the session is invalid. The session now lasts MaxSessionTime minutes of idle time instead of the session lasting 24 hours after login. I've attached the patch below. I'm not sure whether people will find this behaviour more useful than the current behaviour. Thanks! Adrian -- Adrian Chadd The University of Western Australia <adrian(a)ucs.uwa.edu.au> CRICOS: 00126G Ph: +61 8 6488 2574 Mob: +61 421 597 819

2 1