December 2004 - dev - OTRS mailing lists

Missing Date header in AgentForward
by Alessandro Ranellucci 11 Jan '05

11 Jan '05

When I forward an article I get an empty "Date:" header in composed text. Digging a little in OTRS code I found that AgentForward.dtl includes the following fields: $Text{"Date"}: $Data{"Date"} $Text{"From"}: $Data{"From"} $Text{"To"}: $Data{"To"} $Text{"Cc"}: $Data{"Cc"} $Text{"Reply-To"}: $Data{"ReplyTo"} $Text{"Subject"}: $Data{"Subject"} $Data{"Body"} but $Data{"Date"} isn't defined in neither AgentForward.pm or Kernel/System/Ticket/Article.pm. Also I think that it would be nice to show those Cc and Reply-To only if they are not empty. Finally I would remove the double \n between "Forwarded message from" and the "Date: " header. Waiting for your feedback, OTRS team! :-) - Alessandro

1 1

RE: [dev] What's on the development path?
by Frye, Bernie 22 Dec '04

22 Dec '04

Thanks for the input Damir. I'm downloading your module today to try that out. As far as the last item on the Queview for Agents, I know that this is available in ticket search, but traditionally, engineers are lazy. I implemented a button on the search bar that allows the agent to click and see their tickets only. When you can make it easier for users, their more inclined to use it. Bernie Frye Director, Technical Sales Engineering CURRENT Technologies, LLC 12800 Middlebrook Road, Suite 201 Germantown, Md. 20874 301-515-7617 ext. 214 240-793-9137 cell ***CONFIDENTIALITY NOTICE*** The information in this email may be confidential and/or privileged. This email is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this message from your system. -----Original Message----- From: dev-bounces(a)otrs.org [mailto:dev-bounces@otrs.org] On Behalf Of Damir Dzeko Sent: Tuesday, December 21, 2004 1:19 PM To: Development community of OTRS Subject: Re: [dev] What's on the development path? Hi Bernie, Frye, Bernie wrote: > > I'm about to run off and start developing some new modules which will > perform the following functions: > > > 1. Time to respond to the ticket > 2. Time the ticket was in the open state > 3. Time to close the ticket Have you seen my Report module? I've posted it here recently. > 4. Once the ticket is closed, stop the aging process on the ticket Age is simply time passed from creation of the ticket to the present moment. It cannot be stopped. :) But I must admit that it does not make much sense to see that some old ticket is 274 days of age. What you're really asking is to know how long ticket has been opened. Take a look at my Report module :) > 5. Send notifications to the agents when the ticket is in the new > state for 24 hours > 6. Send notifications to the agents when the ticket is in the open > state for 24 hours and no status has been sent to the customer > 7. Send notification to the agent when a ticket reaches XX days old > regardless of the number of status updates that have been sent to > the customer Perhaps GenericAgent could do that? (Haven't tried yet). > 8. Add a field linking ticket to our bug tracking system > 9. Add Stats reporting features for items 1,2 and 3 above. Please take look at my Report module. That's exactly what it's for. It calculates time the ticket spent in unanswered state (response time), the sum of time customer waited for an answer (total processing time), and total time ticket was opened. It reports that in two different values: real wall-clock minutes and business minutes (counting work-hours only). It provides CSV export so you can draw graphs and analyze it in some spread-sheet software. > 10. Enhance the current Stats reporting to display Pie Graphs, Bar > Graphs (in 3D) and be able to export them to Windows machines > properly (this seems to be a problem at the moment with version > 1.3.2) > 11. Add capability for an Agent to get a "QueueView" of their tickets > only Tried ticket search? Although, maybe it would be good to have some filtering mode in QueueView that would enable Agent to have more customized view on ticket queues. Regards, Damir _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

1 0

What's on the development path?
by Frye, Bernie 21 Dec '04

21 Dec '04

I have been using OTRS for about 3 months now and so far it's been a great program. Since I deal with a team that deploys equipment to different areas, I wrote and modified modules that allows the customer side to enter the location of the events and the Agent side to administer the events in the same manner as Queues. This has worked out very well. The locations are available as a pull down just like the queues. From the main menu, I added a location field which is sortable and the location is available in the right hand column in red with priority, state, etc. The customer can also search by the location field which has provided a new handy field for our customers. I'm about to run off and start developing some new modules which will perform the following functions: 1. Time to respond to the ticket 2. Time the ticket was in the open state 3. Time to close the ticket 4. Once the ticket is closed, stop the aging process on the ticket 5. Send notifications to the agents when the ticket is in the new state for 24 hours 6. Send notifications to the agents when the ticket is in the open state for 24 hours and no status has been sent to the customer 7. Send notification to the agent when a ticket reaches XX days old regardless of the number of status updates that have been sent to the customer 8. Add a field linking ticket to our bug tracking system 9. Add Stats reporting features for items 1,2 and 3 above. 10. Enhance the current Stats reporting to display Pie Graphs, Bar Graphs (in 3D) and be able to export them to Windows machines properly (this seems to be a problem at the moment with version 1.3.2) 11. Add capability for an Agent to get a "QueueView" of their tickets only 12. Add the capability for the customer side to generate their own STATS reports Fix a bug in the "Note" notification on the Agent side (which I may or may not have caused) - this only sends an external email when the state, priority or ownership of the ticket is changed. If it is just a general information change and neither the state, ownership or priority changes, the customer is not notified via email of the update to the ticket information. I am just getting ready to track this down. Is there any way to find out if any of these items are on the development roadmap and if so, find out when the next release is due out and if any of this is on any of the future releases? Also, in reading through the discussion threads it looks like there is some work going on with version 2.0 at this time with various folks testing (beta testing perhaps?) this release. Is it possible to get in on this as a beta tester? Any info you can provide on the above information would be greatly appreciated. I'm not really a developer, but I can usually get the coding done. Thanks Bernie Frye Director, Technical Sales Engineering CURRENT Technologies, LLC 12800 Middlebrook Road, Suite 201 Germantown, Md. 20874 301-515-7617 ext. 214 240-793-9137 cell ***CONFIDENTIALITY NOTICE*** The information in this email may be confidential and/or privileged. This email is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this message from your system.

2 1

Illogical placement of queue change option
by Frye, Bernie 21 Dec '04

21 Dec '04

I don't know if you ever resolved this issue, but I have the same issue with our customers adding long messages in the body of the ticket. I solved this problem by adding a scroll bar function in the ticket zoom function which leaves everything up at the top of the screen now. In the file AgentBodyZoom.dtl (at about line 68/69) I modified the line to look like the following: $Data{"BodyNote"} <div class="message"> <textarea rows="25" cols="90" "Env{"BrowserWrap"}">$Data{"Body"}</textarea> <---this is the modified line Of course, modify the rows and cols to fit your needs, but I found that this helps out my particular needs a lot. I also modified the customer side interface as well by modifying the file CustomerTicketZoom.dtl (around line 93) to the following: $Data{"Article::TextNote"} <pre> <textarea rows="25" cols="100" wrap="Env{"BrowserWrap"}">$Data{"Article::Text"}</textarea> <-- modified line This gives me the same scroll bar function on the customer side and neatens things up when looking at tickets. The customers appreciated this feature as well for information that was passed back in lengthy replies from the engineering staff. Hope this helps Bernie Frye Director, Technical Sales Engineering CURRENT Technologies, LLC 12800 Middlebrook Road, Suite 201 Germantown, Md. 20874 301-515-7617 ext. 214 240-793-9137 cell ***CONFIDENTIALITY NOTICE*** The information in this email may be confidential and/or privileged. This email is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this message from your system.

1 0

Agent Note bug
by Frye, Bernie 19 Dec '04

19 Dec '04

When sending an external note from the Agent side, only the agent receives the information. The only time the customer is sent the information on the update is if the ticket state is changed. I've tried to find out how to change this so that the customer is receives updates when an external note is sent and both the agent and customer receives an email upon sending a note, but so far, no luck. The information is available on the customer side, but no notification is received. Any pointers?

1 0

RE: [dev] A date is a date ... or?
by Frye, Bernie 17 Dec '04

17 Dec '04

Thanks. I appreciate the information. I have just started to delve into the coding of this program and I haven't learned all of the intricacies of it yet. However, I am having fun with it. One of the things that I like about OTRS is that it is relatively easy to manipulate the program to tailor it to your own needs. The simplicity on the way it was put together makes this easy to do even if your not a strong Perl programmer (as I am not). Thanks for the info. -----Original Message----- From: dev-bounces(a)otrs.org [mailto:dev-bounces@otrs.org] On Behalf Of Kristoffer Gleditsch Sent: Friday, December 17, 2004 4:17 AM To: dev(a)otrs.org Subject: [dev] A date is a date ... or? Hi! While stumbling around in the source tree, I noticed that the OTRS schema uses DATE for most date/time-related fields, but there are some (three, it seems) fields called xxx_time_unix of type BIGINT. Storing the epoch directly seems a lot easier when you have to do things like matching all records more than two days old, because one can just subtract 2*60*60*24 and compare it (I'm guessing this is the reason why it's done this way in web_upload_cache). However, it doesn't have to be that difficult with DATE either: use Date::Calc qw(Add_Delta_Days Today); my $timelimit = sprintf("%04d-%02d-%02d 00:00:00", Add_Delta_Days(Today(), -2)); # Or, if more precision is needed: use Date::Calc qw(Add_Delta_DHMS Today_and_Now); $timelimit = sprintf("%04d-%02d-%02d %02d:%02d:%02d", Add_Delta_DHMS(Today_and_Now(), -2, 0, 0, 0)); my $SQL = qq[ DELETE FROM foo_table WHERE create_time < ? ]; (It may be easier to do it even easier using TO_CHAR/TO_DATE.) Storing date/time in several different formats in the same database seems somewhat unfortunate. One reason for this is that the normal DATE fields are a lot easier to manipulate directly by humans. Another is that if someone should, for example, ever want to move to a timezone-aware datatype, it is a lot easier to migrate old data if it is all stored in the same format. Or am I missing a point here? If so, please tell me. :) Regards, -- Kristoffer. _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

1 0

A date is a date ... or?
by Kristoffer Gleditsch 17 Dec '04

17 Dec '04

Hi! While stumbling around in the source tree, I noticed that the OTRS schema uses DATE for most date/time-related fields, but there are some (three, it seems) fields called xxx_time_unix of type BIGINT. Storing the epoch directly seems a lot easier when you have to do things like matching all records more than two days old, because one can just subtract 2*60*60*24 and compare it (I'm guessing this is the reason why it's done this way in web_upload_cache). However, it doesn't have to be that difficult with DATE either: use Date::Calc qw(Add_Delta_Days Today); my $timelimit = sprintf("%04d-%02d-%02d 00:00:00", Add_Delta_Days(Today(), -2)); # Or, if more precision is needed: use Date::Calc qw(Add_Delta_DHMS Today_and_Now); $timelimit = sprintf("%04d-%02d-%02d %02d:%02d:%02d", Add_Delta_DHMS(Today_and_Now(), -2, 0, 0, 0)); my $SQL = qq[ DELETE FROM foo_table WHERE create_time < ? ]; (It may be easier to do it even easier using TO_CHAR/TO_DATE.) Storing date/time in several different formats in the same database seems somewhat unfortunate. One reason for this is that the normal DATE fields are a lot easier to manipulate directly by humans. Another is that if someone should, for example, ever want to move to a timezone-aware datatype, it is a lot easier to migrate old data if it is all stored in the same format. Or am I missing a point here? If so, please tell me. :) Regards, -- Kristoffer.

2 1

Feature Sent
by COUPPEY Sebastien 16 Dec '04

16 Dec '04

Hello, I would like to know if it is possible to add in the response format the feature Sent like > Sent: Thursday 16 December 2004 16:49 When you do a reply. Because I didn t find the $Data(variable) to put in the Config.pm Thank you

1 0

Patch: Enable bind params for Prepare() as well as Do()
by Kristoffer Gleditsch 16 Dec '04

16 Dec '04

Hi! While fixing some other stuff (patches for which I'll submit when I get around to it), I really wanted to use bind parameters for select statements as well as for inserts and deletes. So I just copied to approach used in Do(). I also removed LongTruncOK=0 and set LongReadLen to the same as the MaxFileUpload config setting. With the original settings, everything but the smallest attachments would be truncated on their way out of the database. Regards, -- Kristoffer.

1 0

Patch: Fix typo in Kernel/System/Encode.pm
by Kristoffer Gleditsch 15 Dec '04

15 Dec '04

Hi! Fixes a typo (withyour -> with your): Index: Kernel/System/Encode.pm =================================================================== --- Kernel/System/Encode.pm (revision 97) +++ Kernel/System/Encode.pm (working copy) @@ -75,7 +75,7 @@ } else { if ($Self->{Debug}) { - print STDERR "Charset encode not supported withyour perl version!\n"; + print STDERR "Charset encode not supported with your perl version!\n"; } } return $Self; Regards, -- Kristoffer.

1 0