June 2007 - otrs - OTRS mailing lists

I dont get notifications when a Customer sends email into otrs,
by Friedrich Nietzsche 20 Jun '07

20 Jun '07

I dont get notifications when a Customer sends email into otrs it does work when a Customer sends a ticket from the webinterface, then I get a notification. I have "Send me a notification if there is a new ticket in "My Queues". " enabled and I've set my queses to include every que. _________________________________________________________________ Se artisterna uppträda för en grön planet http://liveearth.se.msn.com/

1 0

Problem with timesettings in statistic module
by Andreas Stiegler 20 Jun '07

20 Jun '07

Hi. I have a problem with the statistic module in OTRS 2.1.2: If I enter a Time for my statistic (unfixed time for "ticket created"), the system ignores the timechange. The statistic is always generated for the maximum timeperiode configured in the presettings of the statistic. If I use the calendar to change the date, the new date is not transfered to the config. In other areas of the OTRS this function is working fine. So at the moment I have to change the timeperiode for the statistics by edditing the statistic presettings (maximum allowed timeperiode). Where may the reason for this problem be found? Thank you for your answers, A.Stiegler -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

1 0

Problem with a Script to update a CustomerUser.
by kekieres 20 Jun '07

20 Jun '07

Hi, I want to update the OTRS CustomerUser with the users of a portal and don't want to "link" directly OTRS to the portal database to look for customerusers. I'm writting a PERL script to do it, using the functions in: ~otrs/Kernel/System/CustomerUser.pm There it is said that: -------------------extract------------------- =item CustomerUserUpdate() to update customer users $CustomerUserObject->CustomerUserUpdate( Source => 'CustomerUser', # CustomerUser source config UserLogin => 'mhuber', UserFirstname => 'Huber', UserLastname => 'Manfred', UserPassword => 'some-pass', # not required UserEmail => 'email(a)example.com', ValidID => 1, UserID => 123, ); =cut ---------------end of extract--------------- I'm having problems. My testing is the following, I do create a dummy CustomerUser withe the function with function CustomerUserAdd() (with the same parameter from the example in the coments of the CustomerUser.pm file) and then I'm trying to update with the above function is not working. I'm geting en error saying: --------------------- log ---------------- ERROR: ?LogPrefix?-99 Perl: 5.8.5 OS: linux Time: Wed Jun 20 13:32:28 2007 Message: Need UserCustomerID! Traceback (25134): Module: Kernel::System::CustomerUser::DB::CustomerUserUpdate (v1.42.2.1) Line: 405 Module: Kernel::System::CustomerUser::CustomerUserUpdate (v1.28) Line: 329 Module: prueba.pl (v1.0) Line: 69 ------------------- end log ---------------- Can someone put a bit of light? One of my doubts is also what the developper is refering with "Source => 'CustomerUser'". do I have to change that? Or is there a bug? Thanks, Rafa PS:

1 0

Trying to find out the time taken to close a ticket
by Gabriele D'Andrea 20 Jun '07

20 Jun '07

I'm trying to make a custom report that can tell me, for every ticket, the amount of time taken to close the ticket. Since I can't find a module to do that, i'm trying to query mysql to extract data I need. But I'm not sure it's possible to retrieve the exact date when a ticket was closed using only mysql. Tickets are stored in the TICKET table, linked to the TICKET_HISTORY table, that stores all the events regarding the tickets (e.g. ticket close, follow-up, note etc.) Then the TICKET_HISTORY table is linked to the TICKET_HISTORY_TYPE table, that stores all the possible events. Since it's possible to edit the ticket after it's been closed, there are many occurences of CLOSED states in the ticket_history for the same ticket. I should check for the action that made the ticket close, but it's not possible to determine which of the many ticket_history_type determined the closing. I could select the first occurrence of CLOSED in TICKET_HISTORY, but what if the ticket was closed, then reopend, then closed again? I my reasoning right or am I missing something? -- Gabriele D'Andrea

7 14

Re: [otrs] Statistic extensions (considering TimeWorkingHours)
by Gabriele D'Andrea 20 Jun '07

20 Jun '07

Hi Alex, I'm sorry to bother you once again. I'm trying to figure out what exactly your stats mean: I guess they report every state change to a given state: i.e.: I'm interested in knowing the time needed to close a ticket, so I created a new State_Changes_Specific report, which shows all "closed succesfully" tickets. That's the report generated in a test environment State_Changes_Specific 2007-05 closed successful stampato da Admin OTRS (root@localhost) 18/06/2007 06:53:11 next state Ticket# Customer# 24hdiff Servicediff pending reminder 2007051710000035 FATER 0.01 0.02 open 2007051710000035 FATER 0.02 0.03 open 2007051510000128 ecohmedia 0.03 0.03 open 2007051610000055 0.10 0,10 open 2007051610000055 17.33 6.93 What I realised, is that each row represents a ticket closing, right? What I can't understand very well, is: - next state: what does it exactly mean? maybe the previous state before the closing? - 24hdiff & Servicediff: what time interval does it refer to? and in what time unit?days? Thank you for your patience :P Gabriele ----- Original Message ----- From: "Alexander Scholler" <alexander.scholler(a)augsburg.de> To: "User questions and discussions about OTRS.org" <otrs(a)otrs.org> Sent: Monday, June 18, 2007 8:20 AM Subject: Re: [otrs] Statistic extensions (considering TimeWorkingHours) Hi Gabriele, 24hdiff is the time-gap calculated with 24h a day. Servicediff is the time-gap calculated only within the Service-hours. Bye, Alex Gabriele D'Andrea schrieb: > Hi Alex, > I've made the changes you suggested and now it works. > However, I've not understood what the stats exctly mean: > what are 24hdiff and Servicediff? > > Gabriele > > > ----- Original Message ----- From: "Gabriele D'Andrea" > <gabriele.dandrea(a)ecohmedia.com> > To: "User questions and discussions about OTRS.org" <otrs(a)otrs.org> > Sent: Saturday, June 16, 2007 2:46 PM > Subject: Re: [otrs] Statistic extensions (considering TimeWorkingHours) > > >> Hi Alex, >> Thank you for your help, I'll give ti a try as soon as i come back to >> work >> >> Gabriele >> >> ----- Original Message ----- From: "Alexander Scholler" >> <alexander.scholler(a)augsburg.de> >> To: "User questions and discussions about OTRS.org" <otrs(a)otrs.org> >> Sent: Thursday, June 14, 2007 7:51 AM >> Subject: Re: [otrs] Statistic extensions (considering TimeWorkingHours) >> >> >> Hi Gariele, >> >> Gabriele D'Andrea schrieb: >>> Hi, I tried the modules you have developed: >>> >>> I updated the file ~/Kernel/Config/Files/Ticket.xml, inseting the >>> code for Ticket::StatsOwn4 and Ticket::StatsOwn5 at the end of file , >>> just over </otrs_config> >>> >>> Then I put the files State_Changes.pm and State_Changes_Specific.pm >>> in the directory ~/Kernel/System/Stats/ >>> But I can't see any changes! >>> Have I done something wrong? >>> Can you please explain better what your modules should do? >>> Thank you >>> Gabriele >> >> The steps you did are necessary for OTRS v2.0.x >> >> In OTRS v2.1, there are some (good) changes in applying >> statistic-extensions. >> >> The *.pm-extension-files (e.g. State_Changes.pm) must be stored in >> ~otrs/Kernel/Systems/Stats/Static/. >> (remember to change the package-name within the file!). >> >> Then, create a new statistic within the GUI. >> Instead of using the dynamic object "ticket", you now can choose the >> extension-file. >> You new statistic is available directly after processing the 1st of the >> indicated 4 steps (you need all the 4 steps only for the dynamic object). >> >> If you have problems, please desribe them very specific. >> >> Bye, Alex >> >>> >>> >>> Alexander Scholler wrote: >>> Wed, 17 May 2006 01:17:21 -0700 >>> Hi all, >>> >>> >>> often discussed on the lists (english as well as german): the >>> availability of statistic extensions on OTRS. >>> I now wrote some extensions posted in this mail. >>> >>> This is the approach I followed: >>> >>> >>> 1) Basically I had to understand the DB-schema >>> ftp://ftp.otrs.org/pub/otrs/misc/otrs-2.0-database.png >>> >>> 2) Then I did some pure SQL statistic analysis within OpenOffice Base >>> with JDBC-bridge to the MySQL-DB (note: this Base-DB can be used >>> excellently under Windows and Linux! - try this with M$-Office). >>> >>> 2a) The problem is that TimeDifferences (eg. how long did it takes to >>> act on a new ticket) are always calculated hard, meaning >>> "DateWhenActing minus DateWhenNew" is not really a good measurement >>> because the support time of the service desk team is not considered. >>> The gap in seconds within the support time (defined in >>> TimeWorkingHours and others on OTRS) can be calculated within OTRS >>> through Kernel::System::Time->WorkingHours, see >>> http://dev.otrs.org/2.0/Kernel/System/Time.html#item_workingtime >>> (sorry for that syntax, I'm not a perl expert). >>> >>> So I had to bring my Base-SQL-statements into the OTRS statistic >>> framework to use the time-function provided by OTRS. >>> >>> 2b) I took ~/Kernel/Systems/Stats/* as templates and created my own >>> extensions. >>> Some of them are attached to this mail. >>> >>> You have to copy the *.pm-Files to the proper location and extend >>> your ~/Kernel/Config/Files/Ticket.xml (to let OTRS know that there >>> are extensions). >>> Would you please give me feedback >>> * if the SQL-statements are correct >>> * if the work I've done follows the right way >>> >>> >>> I think many of you have waited for the statistics I provide. If you >>> extend my statistics, please also publish your work done. Consider >>> that changes you make to statistics don't affect if UseResultCache = >>> 1. WriteCache on State_Changes_Specific.pm could be applied due to >>> the logic, but cache-distinction upon different selected states is >>> not supplied by OTRS (it only considers Month and Year). >>> Sorry about the german/english-mix used within the files. >>> >>> Now, some questions coming up during my work: >>> >>> I) In Status_Changes.pm the code does >>> * make the sql-query >>> * calculate time within support time >>> * does some data-grouping through perl >>> >>> The problem is that I had to expensively (for me!) code the >>> data-grouping in perl. MySQL could do this job much better and more >>> efficient. But how can the WorkingHours-function of OTRS be brought >>> to MySQL? Ia) by writing an MySQL stored-procedure/function, first >>> available on v5.0. The problem with this approach is that the >>> service-time must be maintained in OTRS and in the MySQL-function => >>> this could be done in further OTRS version through OTRS itself with >>> it's DB-access. Ib) by giving the modified time data from OTRS back >>> to MySQL. Out of OTRS a temporary table could be created which would >>> be filled with the modified time data through OTRS. Data-analyses >>> (e.g. grouping) could be done on this table. >>> What do you think about these approaches? >>> >>> II) I wanted to do some modification over all statistics. >>> >>> So I edited ~/Kernel/Modul/SystemStats.pm. But I couldn't notice any >>> output-changes upon code changes (beside wrong syntax: this was >>> reported by an error). Where or how must the statistic output module >>> be edited? >>> Bye, Alex >>> >>> State_Changes.pm >>> Description: Perl program >>> State_Changes_Specific.pm >>> Description: Perl program >>> <ConfigItem Name="SystemStatsMap###Ticket::StatsOwn4" Required="0" >>> Valid="1"> >>> <Description Lang="en">duration of states</Description> >>> <Description Lang="de">Dauer der Stati</Description> >>> <Group>Ticket</Group> >>> <SubGroup>Core::Stats</SubGroup> >>> <Setting> >>> <Hash> >>> <Item Key="Name">Status-Verweildauer</Item> >>> <Item >>> Key="Module">Kernel::System::Stats::State_Changes</Item> >>> <Item Key="Desc">Gibt an, wie lange die einzelnen Stati >>> bestehen bleiben. Es werden alle Stati betrachtet, die innerhalb des >>> gewuenschten Zeitraumes beendet wurden.</Item> >>> <Item Key="UseResultCache">1</Item> >>> <Item Key="Output"> >>> <Array> >>> <Item>Print</Item> >>> <Item>CSV</Item> >>> </Array> >>> </Item> >>> <Item Key="OutputDefault">Print</Item> >>> </Hash> >>> </Setting> >>> </ConfigItem> >>> <ConfigItem Name="SystemStatsMap###Ticket::StatsOwn5" Required="0" >>> Valid="1"> >>> <Description Lang="en">duration of specific state</Description> >>> <Description Lang="de">Dauer eines speziellen >>> Status</Description> >>> <Group>Ticket</Group> >>> <SubGroup>Core::Stats</SubGroup> >>> <Setting> >>> <Hash> >>> <Item Key="Name">Status-Verweildauer (spezifische >>> Einzelbetrachtung)</Item> >>> <Item >>> Key="Module">Kernel::System::Stats::State_Changes_Specific</Item> >>> <Item Key="Desc">Zeigt alle Verweildauern des >>> ausgewÃ¤hlten >>> Status a. (Status muss im ausgewaehlten Monat abgeschlossen worden >>> sein.</Item> >>> <Item Key="UseResultCache">0</Item> >>> <Item Key="Output"> >>> <Array> >>> <Item>Print</Item> >>> <Item>CSV</Item> >>> </Array> >>> </Item> >>> <Item Key="OutputDefault">Print</Item> >>> </Hash> >>> </Setting> >>> </ConfigItem> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> OTRS mailing list: otrs - Webpage: http://otrs.org/ >>> Archive: http://lists.otrs.org/pipermail/otrs >>> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >>> Support or consulting for your OTRS system? >>> => http://www.otrs.com/ >> >> _______________________________________________ >> OTRS mailing list: otrs - Webpage: http://otrs.org/ >> Archive: http://lists.otrs.org/pipermail/otrs >> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >> Support or consulting for your OTRS system? >> =http://www.otrs.com/ >> equest(a)otrs.org?subject=subscribe> >> List-Archive: <http://lists.otrs.org/pipermail/otrs> >> List-Post: <mailto:otrs@otrs.org> >> List-Help: <mailto:otrs-request@otrs.org?subject=lp> >> List-Subscribe: <http://lists.otrs.org/cgi-bin/listinfo/otrs>, >> <mailto:otrs-request@otrs.org?subject=bscribe> >> Sender: otrs-bounces(a)otrs.org >> Errors-To: otrs-bounces(a)otrs.org >> X-Spam-Rating: mxavas3.alicom.com 1.6.2 0/1000/N >> >> Hi Gariele, >> >> Gabriele D'Andrea schrieb: >>> Hi, I tried the modules you have developed: >>> >>> I updated the file ~/Kernel/Config/Files/Ticket.xml, inseting the >>> code for Ticket::StatsOwn4 and Ticket::StatsOwn5 at the end of file , >>> just over </otrs_config> >>> >>> Then I put the files State_Changes.pm and State_Changes_Specific.pm >>> in the directory ~/Kernel/System/Stats/ >>> But I can't see any changes! >>> Have I done something wrong? >>> Can you please explain better what your modules should do? >>> Thank you >>> Gabriele >> >> The steps you did are necessary for OTRS v2.0.x >> >> In OTRS v2.1, there are some (good) changes in applying >> statistic-extensions. >> >> The *.pm-extension-files (e.g. State_Changes.pm) must be stored in >> ~otrs/Kernel/Systems/Stats/Static/. >> (remember to change the package-name within the file!). >> >> Then, create a new statistic within the GUI. >> Instead of using the dynamic object "ticket", you now can choose the >> extension-file. >> You new statistic is available directly after processing the 1st of the >> indicated 4 steps (you need all the 4 steps only for the dynamic object). >> >> If you have problems, please desribe them very specific. >> >> Bye, Alex >> >>> >>> >>> Alexander Scholler wrote: >>> Wed, 17 May 2006 01:17:21 -0700 >>> Hi all, >>> >>> >>> often discussed on the lists (english as well as german): the >>> availability of statistic extensions on OTRS. >>> I now wrote some extensions posted in this mail. >>> >>> This is the approach I followed: >>> >>> >>> 1) Basically I had to understand the DB-schema >>> ftp://ftp.otrs.org/pub/otrs/misc/otrs-2.0-database.png >>> >>> 2) Then I did some pure SQL statistic analysis within OpenOffice Base >>> with JDBC-bridge to the MySQL-DB (note: this Base-DB can be used >>> excellently under Windows and Linux! - try this with M$-Office). >>> >>> 2a) The problem is that TimeDifferences (eg. how long did it takes to >>> act on a new ticket) are always calculated hard, meaning >>> "DateWhenActing minus DateWhenNew" is not really a good measurement >>> because the support time of the service desk team is not considered. >>> The gap in seconds within the support time (defined in >>> TimeWorkingHours and others on OTRS) can be calculated within OTRS >>> through Kernel::System::Time->WorkingHours, see >>> http://dev.otrs.org/2.0/Kernel/System/Time.html#item_workingtime >>> (sorry for that syntax, I'm not a perl expert). >>> >>> So I had to bring my Base-SQL-statements into the OTRS statistic >>> framework to use the time-function provided by OTRS. >>> >>> 2b) I took ~/Kernel/Systems/Stats/* as templates and created my own >>> extensions. >>> Some of them are attached to this mail. >>> >>> You have to copy the *.pm-Files to the proper location and extend >>> your ~/Kernel/Config/Files/Ticket.xml (to let OTRS know that there >>> are extensions). >>> Would you please give me feedback >>> * if the SQL-statements are correct >>> * if the work I've done follows the right way >>> >>> >>> I think many of you have waited for the statistics I provide. If you >>> extend my statistics, please also publish your work done. Consider >>> that changes you make to statistics don't affect if UseResultCache = >>> 1. WriteCache on State_Changes_Specific.pm could be applied due to >>> the logic, but cache-distinction upon different selected states is >>> not supplied by OTRS (it only considers Month and Year). >>> Sorry about the german/english-mix used within the files. >>> >>> Now, some questions coming up during my work: >>> >>> I) In Status_Changes.pm the code does >>> * make the sql-query >>> * calculate time within support time >>> * does some data-grouping through perl >>> >>> The problem is that I had to expensively (for me!) code the >>> data-grouping in perl. MySQL could do this job much better and more >>> efficient. But how can the WorkingHours-function of OTRS be brought >>> to MySQL? Ia) by writing an MySQL stored-procedure/function, first >>> available on v5.0. The problem with this approach is that the >>> service-time must be maintained in OTRS and in the MySQL-function => >>> this could be done in further OTRS version through OTRS itself with >>> it's DB-access. Ib) by giving the modified time data from OTRS back >>> to MySQL. Out of OTRS a temporary table could be created which would >>> be filled with the modified time data through OTRS. Data-analyses >>> (e.g. grouping) could be done on this table. >>> What do you think about these approaches? >>> >>> II) I wanted to do some modification over all statistics. >>> >>> So I edited ~/Kernel/Modul/SystemStats.pm. But I couldn't notice any >>> output-changes upon code changes (beside wrong syntax: this was >>> reported by an error). Where or how must the statistic output module >>> be edited? >>> Bye, Alex >>> >>> State_Changes.pm >>> Description: Perl program >>> State_Changes_Specific.pm >>> Description: Perl program >>> <ConfigItem Name="SystemStatsMap###Ticket::StatsOwn4" Required="0" >>> Valid="1"> >>> <Description Lang="en">duration of states</Description> >>> <Description Lang="de">Dauer der Stati</Description> >>> <Group>Ticket</Group> >>> <SubGroup>Core::Stats</SubGroup> >>> <Setting> >>> <Ha >> >> _______________________________________________ >> OTRS mailing list: otrs - Webpage: http://otrs.org/ >> Archive: http://lists.otrs.org/pipermail/otrs >> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >> Support or consulting for your OTRS system? >> => http://www.otrs.com/ >>> >>> <Item Key="Name">Status-Verweildauer</Item> >>> <Item >>> Key="Module">Kernel::System::Stats::State_Changes</Item> >>> <Item Key="Desc">Gibt an, wie lange die einzelnen Stati >>> bestehen bleiben. Es werden alle Stati betrachtet, die innerhalb des >>> gewuenschten Zeitraumes beendet wurden.</Item> >>> <Item Key="UseResultCache">1</Item> >>> <Item Key="Output"> >>> <Array> >>> <Item>Print</Item> >>> <Item>CSV</Item> >>> </Array> >>> </Item> >>> <Item Key="OutputDefault">Print</Item> >>> </Hash> >>> </Setting> >>> </ConfigItem> >>> <ConfigItem Name="SystemStatsMap###Ticket::StatsOwn5" Required="0" >>> Valid="1"> >>> <Description Lang="en">duration of specific state</Description> >>> <Description Lang="de">Dauer eines speziellen >>> Status</Description> >>> <Group>Ticket</Group> >>> <SubGroup>Core::Stats</SubGroup> >>> <Setting> >>> <Hash> >>> <Item Key="Name">Status-Verweildauer (spezifische >>> Einzelbetrachtung)</Item> >>> <Item >>> Key="Module">Kernel::System::Stats::State_Changes_Specific</Item> >>> <Item Key="Desc">Zeigt alle Verweildauern des >>> ausgewÃ¤hlten >>> Status a. (Status muss im ausgewaehlten Monat abgeschlossen worden >>> sein.</Item> >>> <Item Key="UseResultCache">0</Item> >>> <Item Key="Output"> >>> <Array> >>> <Item>Print</Item> >>> <Item>CSV</Item> >>> </Array> >>> </Item> >>> <Item Key="OutputDefault">Print</Item> >>> </Hash> >>> </Setting> >>> </ConfigItem> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> OTRS mailing list: otrs - Webpage: http://otrs.org/ >>> Archive: http://lists.otrs.org/pipermail/otrs >>> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >>> Support or consulting for your OTRS system? >>> => http://www.otrs.com/ >> >> _______________________________________________ >> OTRS mailing list: otrs - Webpage: http://otrs.org/ >> Archive: http://lists.otrs.org/pipermail/otrs >> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >> Support or consulting for your OTRS system? >> =http://www.otrs.com/ >> equest(a)otrs.org?subject=subscribe> >> List-Archive: <http://lists.otrs.org/pipermail/otrs> >> List-Post: <mailto:otrs@otrs.org> >> List-Help: <mailto:otrs-request@otrs.org?subject=lp> >> List-Subscribe: <http://lists.otrs.org/cgi-bin/listinfo/otrs>, >> <mailto:otrs-request@otrs.org?subject=bscribe> >> Sender: otrs-bounces(a)otrs.org >> Errors-To: otrs-bounces(a)otrs.org >> X-Spam-Rating: mxavas3.alicom.com 1.6.2 0/1000/N >> >> Hi Gariele, >> >> Gabriele D'Andrea schrieb: >>> Hi, I tried the modules you have developed: >>> >>> I updated the file ~/Kernel/Config/Files/Ticket.xml, inseting the >>> code for Ticket::StatsOwn4 and Ticket::StatsOwn5 at the end of file , >>> just over </otrs_config> >>> >>> Then I put the files State_Changes.pm and State_Changes_Specific.pm >>> in the directory ~/Kernel/System/Stats/ >>> But I can't see any changes! >>> Have I done something wrong? >>> Can you please explain better what your modules should do? >>> Thank you >>> Gabriele >> >> The steps you did are necessary for OTRS v2.0.x >> >> In OTRS v2.1, there are some (good) changes in applying >> statistic-extensions. >> >> The *.pm-extension-files (e.g. State_Changes.pm) must be stored in >> ~otrs/Kernel/Systems/Stats/Static/. >> (remember to change the package-name within the file!). >> >> Then, create a new statistic within the GUI. >> Instead of using the dynamic object "ticket", you now can choose the >> extension-file. >> You new statistic is available directly after processing the 1st of the >> indicated 4 steps (you need all the 4 steps only for the dynamic object). >> >> If you have problems, please desribe them very specific. >> >> Bye, Alex >> >>> >>> >>> Alexander Scholler wrote: >>> Wed, 17 May 2006 01:17:21 -0700 >>> Hi all, >>> >>> >>> often discussed on the lists (english as well as german): the >>> availability of statistic extensions on OTRS. >>> I now wrote some extensions posted in this mail. >>> >>> This is the approach I followed: >>> >>> >>> 1) Basically I had to understand the DB-schema >>> ftp://ftp.otrs.org/pub/otrs/misc/otrs-2.0-database.png >>> >>> 2) Then I did some pure SQL statistic analysis within OpenOffice Base >>> with JDBC-bridge to the MySQL-DB (note: this Base-DB can be used >>> excellently under Windows and Linux! - try this with M$-Office). >>> >>> 2a) The problem is that TimeDifferences (eg. how long did it takes to >>> act on a new ticket) are always calculated hard, meaning >>> "DateWhenActing minus DateWhenNew" is not really a good measurement >>> because the support time of the service desk team is not considered. >>> The gap in seconds within the support time (defined in >>> TimeWorkingHours and others on OTRS) can be calculated within OTRS >>> through Kernel::System::Time->WorkingHours, see >>> http://dev.otrs.org/2.0/Kernel/System/Time.html#item_workingtime >>> (sorry for that syntax, I'm not a perl expert). >>> >>> So I had to bring my Base-SQL-statements into the OTRS statistic >>> framework to use the time-function provided by OTRS. >>> >>> 2b) I took ~/Kernel/Systems/Stats/* as templates and created my own >>> extensions. >>> Some of them are attached to this mail. >>> >>> You have to copy the *.pm-Files to the proper location and extend >>> your ~/Kernel/Config/Files/Ticket.xml (to let OTRS know that there >>> are extensions). >>> Would you please give me feedback >>> * if the SQL-statements are correct >>> * if the work I've done follows the right way >>> >>> >>> I think many of you have waited for the statistics I provide. If you >>> extend my statistics, please also publish your work done. Consider >>> that changes you make to statistics don't affect if UseResultCache = >>> 1. WriteCache on State_Changes_Specific.pm could be applied due to >>> the logic, but cache-distinction upon different selected states is >>> not supplied by OTRS (it only considers Month and Year). >>> Sorry about the german/english-mix used within the files. >>> >>> Now, some questions coming up during my work: >>> >>> I) In Status_Changes.pm the code does >>> * make the sql-query >>> * calculate time within support time >>> * does some data-grouping through perl >>> >>> The problem is that I had to expensively (for me!) code the >>> data-grouping in perl. MySQL could do this job much better and more >>> efficient. But how can the WorkingHours-function of OTRS be brought >>> to MySQL? Ia) by writing an MySQL stored-procedure/function, first >>> available on v5.0. The problem with this approach is that the >>> service-time must be maintained in OTRS and in the MySQL-function => >>> this could be done in further OTRS version through OTRS itself with >>> it's DB-access. Ib) by giving the modified time data from OTRS back >>> to MySQL. Out of OTRS a temporary table could be created which would >>> be filled with the modified time data through OTRS. Data-analyses >>> (e.g. grouping) could be done on this table. >>> What do you think about these approaches? >>> >>> II) I wanted to do some modification over all statistics. >>> >>> So I edited ~/Kernel/Modul/SystemStats.pm. But I couldn't notice any >>> output-changes upon code changes (beside wrong syntax: this was >>> reported by an error). Where or how must the statistic output module >>> be edited? >>> Bye, Alex >>> >>> State_Changes.pm >>> Description: Perl program >>> State_Changes_Specific.pm >>> Description: Perl program >>> <ConfigItem Name="SystemStatsMap###Ticket::StatsOwn4" Required="0" >>> Valid="1"> >>> <Description Lang="en">duration of states</Description> >>> <Description Lang="de">Dauer der Stati</Description> >>> <Group>Ticket</Group> >>> <SubGroup>Core::Stats</SubGroup> >>> <Setting> >>> <Ha >> _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support or consulting for your OTRS system? =http://www.otrs.com/ /Array> >>> </Item> >>> <Item Key="OutputDefault">Print</Item> >>> </Hash> >>> </Setting> >>> </ConfigItem> >>> <ConfigItem Name="SystemStatsMap###Ticket::StatsOwn5" Required="0" >>> Valid="1"> >>> <Description Lang="en">duration of specific state</Description> >>> <Description Lang="de">Dauer eines speziellen >>> Status</Description> >>> <Group>Ticket</Group> >>> <SubGroup>Core::Stats</SubGroup> >>> <Setting> >>> <Hash> >>> <Item Key="Name">Status-Verweildauer (spezifische >>> Einzelbetrachtung)</Item> >>> <Item >>> Key="Module">Kernel::System::Stats::State_Changes_Specific</Item> >>> <Item Key="Desc">Zeigt alle Verweildauern des >>> ausgewÃ¤hlten >>> Status a. (Status muss im ausgewaehlten Monat abgeschlossen worden >>> sein.</Item> >>> <Item Key="UseResultCache">0</Item> >>> <Item Key="Output"> >>> <Array> >>> <Item>Print</Item> >>> <Item>CSV</Item> >>> </Array> >>> </Item> >>> <Item Key="OutputDefault">Print</Item> >>> </Hash> >>> </Setting> >>> </ConfigItem> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> OTRS mailing list: otrs - Webpage: http://otrs.org/ >>> Archive: http://lists.otrs.org/pipermail/otrs >>> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >>> Support or consulting for your OTRS system? >>> => http://www.otrs.com/ >> >> _______________________________________________ >> OTRS mailing list: otrs - Webpage: http://otrs.org/ >> Archive: http://lists.otrs.org/pipermail/otrs >> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >> Support or consulting for your OTRS system? >> =http://www.otrs.com/ >> equest(a)otrs.org?subject=subscribe> >> List-Archive: <http://lists.otrs.org/pipermail/otrs> >> List-Post: <mailto:otrs@otrs.org> >> List-Help: <mailto:otrs-request@otrs.org?subject=lp> >> List-Subscribe: <http://lists.otrs.org/cgi-bin/listinfo/otrs>, >> <mailto:otrs-request@otrs.org?subject=bscribe> >> Sender: otrs-bounces(a)otrs.org >> Errors-To: otrs-bounces(a)otrs.org >> X-Spam-Rating: mxavas3.alicom.com 1.6.2 0/1000/N >> >> Hi Gariele, >> >> Gabriele D'Andrea schrieb: >>> Hi, I tried the modules you have developed: >>> >>> I updated the file ~/Kernel/Config/Files/Ticket.xml, inseting the >>> code for Ticket::StatsOwn4 and Ticket::StatsOwn5 at the end of file , >>> just over </otrs_config> >>> >>> Then I put the files State_Changes.pm and State_Changes_Specific.pm >>> in the directory ~/Kernel/System/Stats/ >>> But I can't see any changes! >>> Have I done something wrong? >>> Can you please explain better what your modules should do? >>> Thank you >>> Gabriele >> >> The steps you did are necessary for OTRS v2.0.x >> >> In OTRS v2.1, there are some (good) changes in applying >> statistic-extensions. >> >> The *.pm-extension-files (e.g. State_Changes.pm) must be stored in >> ~otrs/Kernel/Systems/Stats/Static/. >> (remember to change the package-name within the file!). >> >> Then, create a new statistic within the GUI. >> Instead of using the dynamic object "ticket", you now can choose the >> extension-file. >> You new statistic is available directly after processing the 1st of the >> indicated 4 steps (you need all the 4 steps only for the dynamic object). >> >> If you have problems, please desribe them very specific. >> >> Bye, Alex >> >>> >>> >>> Alexander Scholler wrote: >>> Wed, 17 May 2006 01:17:21 -0700 >>> Hi all, >>> >>> >>> often discussed on the lists (english as well as german): the >>> availability of statistic extensions on OTRS. >>> I now wrote some extensions posted in this mail. >>> >>> This is the approach I followed: >>> >>> >>> 1) Basically I had to understand the DB-schema >>> ftp://ftp.otrs.org/pub/otrs/misc/otrs-2.0-database.png >>> >>> 2) Then I did some pure SQL statistic analysis within OpenOffice Base >>> with JDBC-bridge to the MySQL-DB (note: this Base-DB can be used >>> excellently under Windows and Linux! - try this with M$-Office). >>> >>> 2a) The problem is that TimeDifferences (eg. how long did it takes to >>> act on a new ticket) are always calculated hard, meaning >>> "DateWhenActing minus DateWhenNew" is not really a good measurement >>> because the support time of the service desk team is not considered. >>> The gap in seconds within the support time (defined in >>> TimeWorkingHours and others on OTRS) can be calculated within OTRS >>> through Kernel::System::Time->WorkingHours, see >>> http://dev.otrs.org/2.0/Kernel/System/Time.html#item_workingtime >>> (sorry for that syntax, I'm not a perl expert). >>> >>> So I had to bring my Base-SQL-statements into the OTRS statistic >>> framework to use the time-function provided by OTRS. >>> >>> 2b) I took ~/Kernel/Systems/Stats/* as templates and created my own >>> extensions. >>> Some of them are attached to this mail. >>> >>> You have to copy the *.pm-Files to the proper location and extend >>> your ~/Kernel/Config/Files/Ticket.xml (to let OTRS

2 2

httpd.conf file
by support 19 Jun '07

19 Jun '07

How can I unpack the original httpd.conf file from the otrs install program? I'm on a windows platform and installed the otrs software using the .exe file. Thanks, Greg

1 0

Customer Auto Login, how to avoid the registration/login process?
by pierre biais 19 Jun '07

19 Jun '07

Hi the pros, I am currently modifying the InterfaceCustomer.pm (more precisely the CustomerAuth module) to let customers login automatically from our portal. Actually I want to use the same login/password as used on our portal to auto signup/login on the OTRS customer interface. Does anybody know a simple method to perform this task without modifying too much files? Hope somebody could answer my problem ;-) Thanks beforehands for your help. Maybe see you soon Pierre _________________________________________________________________ Gagnez des écrans plats avec Live.com http://www.image-addict.fr/

1 0

ACL to validate customer-information
by Alexander Scholler 19 Jun '07

19 Jun '07

Hi, Some of our OTRS-tickets are generated through SOAP without a customer assigned to the ticket (ticket.customerid = NULL). I would like to force my agents to associate a customer to these tickets. Does anybody know how to write an ACL to check if the customer-assignment was not yet done or if a valid customer was found within the customer-DB to the given ticket.customerid. Bye, Alex

1 0

How to change the mail character encoding from iso-8859-1 to Windows-1251?
by nick＠obor.org 18 Jun '07

18 Jun '07

Hi, I've changed the default character encoding to Windows-1251, but when I receive an email from the otrs system it is with the standard iso mail encoding. If someone knows how this can be changed it will be much appreciated. Cheers :)

1 0

Re: [otrs] Statistic extensions (considering TimeWorkingHours)
by Gabriele D'Andrea 18 Jun '07

18 Jun '07

Hi, I tried the modules you have developed: I updated the file ~/Kernel/Config/Files/Ticket.xml, inseting the code for Ticket::StatsOwn4 and Ticket::StatsOwn5 at the end of file , just over </otrs_config> Then I put the files State_Changes.pm and State_Changes_Specific.pm in the directory ~/Kernel/System/Stats/ But I can't see any changes! Have I done something wrong? Can you please explain better what your modules should do? Thank you Gabriele Alexander Scholler wrote: Wed, 17 May 2006 01:17:21 -0700 Hi all, often discussed on the lists (english as well as german): the availability of statistic extensions on OTRS. I now wrote some extensions posted in this mail. This is the approach I followed: 1) Basically I had to understand the DB-schema ftp://ftp.otrs.org/pub/otrs/misc/otrs-2.0-database.png 2) Then I did some pure SQL statistic analysis within OpenOffice Base with JDBC-bridge to the MySQL-DB (note: this Base-DB can be used excellently under Windows and Linux! - try this with M$-Office). 2a) The problem is that TimeDifferences (eg. how long did it takes to act on a new ticket) are always calculated hard, meaning "DateWhenActing minus DateWhenNew" is not really a good measurement because the support time of the service desk team is not considered. The gap in seconds within the support time (defined in TimeWorkingHours and others on OTRS) can be calculated within OTRS through Kernel::System::Time->WorkingHours, see http://dev.otrs.org/2.0/Kernel/System/Time.html#item_workingtime (sorry for that syntax, I'm not a perl expert). So I had to bring my Base-SQL-statements into the OTRS statistic framework to use the time-function provided by OTRS. 2b) I took ~/Kernel/Systems/Stats/* as templates and created my own extensions. Some of them are attached to this mail. You have to copy the *.pm-Files to the proper location and extend your ~/Kernel/Config/Files/Ticket.xml (to let OTRS know that there are extensions). Would you please give me feedback * if the SQL-statements are correct * if the work I've done follows the right way I think many of you have waited for the statistics I provide. If you extend my statistics, please also publish your work done. Consider that changes you make to statistics don't affect if UseResultCache = 1. WriteCache on State_Changes_Specific.pm could be applied due to the logic, but cache-distinction upon different selected states is not supplied by OTRS (it only considers Month and Year). Sorry about the german/english-mix used within the files. Now, some questions coming up during my work: I) In Status_Changes.pm the code does * make the sql-query * calculate time within support time * does some data-grouping through perl The problem is that I had to expensively (for me!) code the data-grouping in perl. MySQL could do this job much better and more efficient. But how can the WorkingHours-function of OTRS be brought to MySQL? Ia) by writing an MySQL stored-procedure/function, first available on v5.0. The problem with this approach is that the service-time must be maintained in OTRS and in the MySQL-function => this could be done in further OTRS version through OTRS itself with it's DB-access. Ib) by giving the modified time data from OTRS back to MySQL. Out of OTRS a temporary table could be created which would be filled with the modified time data through OTRS. Data-analyses (e.g. grouping) could be done on this table. What do you think about these approaches? II) I wanted to do some modification over all statistics. So I edited ~/Kernel/Modul/SystemStats.pm. But I couldn't notice any output-changes upon code changes (beside wrong syntax: this was reported by an error). Where or how must the statistic output module be edited? Bye, Alex State_Changes.pm Description: Perl program State_Changes_Specific.pm Description: Perl program <ConfigItem Name="SystemStatsMap###Ticket::StatsOwn4" Required="0" Valid="1"> <Description Lang="en">duration of states</Description> <Description Lang="de">Dauer der Stati</Description> <Group>Ticket</Group> <SubGroup>Core::Stats</SubGroup> <Setting> <Hash> <Item Key="Name">Status-Verweildauer</Item> <Item Key="Module">Kernel::System::Stats::State_Changes</Item> <Item Key="Desc">Gibt an, wie lange die einzelnen Stati bestehen bleiben. Es werden alle Stati betrachtet, die innerhalb des gewuenschten Zeitraumes beendet wurden.</Item> <Item Key="UseResultCache">1</Item> <Item Key="Output"> <Array> <Item>Print</Item> <Item>CSV</Item> </Array> </Item> <Item Key="OutputDefault">Print</Item> </Hash> </Setting> </ConfigItem> <ConfigItem Name="SystemStatsMap###Ticket::StatsOwn5" Required="0" Valid="1"> <Description Lang="en">duration of specific state</Description> <Description Lang="de">Dauer eines speziellen Status</Description> <Group>Ticket</Group> <SubGroup>Core::Stats</SubGroup> <Setting> <Hash> <Item Key="Name">Status-Verweildauer (spezifische Einzelbetrachtung)</Item> <Item Key="Module">Kernel::System::Stats::State_Changes_Specific</Item> <Item Key="Desc">Zeigt alle Verweildauern des ausgewÃ¤hlten Status a. (Status muss im ausgewaehlten Monat abgeschlossen worden sein.</Item> <Item Key="UseResultCache">0</Item> <Item Key="Output"> <Array> <Item>Print</Item> <Item>CSV</Item> </Array> </Item> <Item Key="OutputDefault">Print</Item> </Hash> </Setting> </ConfigItem>

2 4