- otrs - OTRS mailing lists

Problem after update to KIX4OTRS 6.1.6 ITSM/OTRS 3.3.14
by Василий Труфанов 10 Jun '15

10 Jun '15

Hello! Problem in CMDB, when i try to adding *installation date *parameter. [image: Встроенное изображение 1]

1 0

Approval in process ticket
by Vishesh kumar 08 Jun '15

08 Jun '15

Hi Members, I am trying to get approval via mail in a process ticket. I put ticketarticlecreate in transition action and specified mail id as parameter along with other parameters. Ticket article get created and visible in process ticket but mail for approval not getting delivered to customer/managers. Please let me know if I am missing anything here. Thanks Vishhesh kumar

1 0

Bulk exporting tickets/articles to email
by Blue Web 06 Jun '15

06 Jun '15

Hello, I need to export multiple tickets selected via generic agent process to plain .eml format. I know the generic agent allows to run ticket commands/custom modules, however it's unclear to me how to proceed. Would someone please be so kind to provide an example ? What I need is to export all tickets/articles in a queue so that I am able to import them back to a mailbox. Thanks, gs

2 3

Include Customer User field in Process Activity Dialog
by Saunders, Eric 04 Jun '15

04 Jun '15

Hello, I would like to include a Customer User field that performs a live search of existing customers in a Process Activity Dialog. The functionality would be identical to that of the Create New Phone Ticket screen or the process demonstrated at 11:12 of this webinar: https://www.youtube.com/watch?v=piY4nZsmrOg OTRS 3.3.12

4 4

Statistics
by Simon Allison 02 Jun '15

02 Jun '15

Hi All, Has anyone be able to setup Statistics to show 1. How many closed tickets in the past week? 2. And how many by each agent? I have tried modifying the monthly ticket stat ticketlist, but outputs nothing. Simon P. Allison IT Infrastructure Support Engineer T: 023 9279 7957 E: spallison(a)southdowns.ac.uk<mailto:spallison@southdowns.ac.uk> South Downs College, College Road, Waterlooville, Hampshire, PO7 8AA P Save our trees! Please don't print out this e-mail unless absolutely necessary. ________________________________ [http://www.southdowns.ac.uk/assets/efooter.png]<http://www.southdowns.ac.uk/apprenticeships> ********************************************************************** This message may contain privileged and confidential information. It is intended solely for the person to whom it is addressed. If you are not the intended recipient, please notify the sender and delete the message immediately. The text in this e-mail and any attachments should not be altered or tampered with in any way. Any views expressed in this message are those of the individual sender and do not necessarily reflect the views of South Downs College. **********************************************************************

2 2

Re: [otrs] Reporting for accounting and setup best practices
by Holger Erb 01 Jun '15

01 Jun '15

Hi Benedict, we have a global IT helpdesk structure, here an overview 1st line support: 1 queue per country for the local/national 1st line Helpdesk: DE (Germany), FR (France), IT (Italy), ES (Spain), etc.... 1 separate e-mail address per country/queue. We handle here all local/national support-requests. We differentiate the requests between Incident Requests (problems on existing infrastructure/application) and Service Requests (service request for changes, setups, new users, etc...) via the Ticket-TYPE. We assign the according SERVICE and SLA level to the different requests/tickets during the analyze phase of the ticket. All services are available for all queues/countries. SLAs are per country configured to reflect the right time zone and working hours. All those 1st line queues are configured with the according calendar to match the right time zone and working hours. 2nd line helpdesk and further support queues: This is our escalation queue if 1st line cannot help further and need support from a specialist in the different technical areas. Here we solve all infrastructure/application related escalations based. >From here we can escalate further to other support teams like Software Development etc. We have in all countries / in all queues / at any time of a ticket-life-cycle all TYPES/SERVICES/SLAs available to update if needed. MIT FREUNDLICHEN GRUESSEN / WITH KIND REGARDS HOLGER ERB ------------------------- From: Linux4Bene <linux4bene(a)telenet.be> Subject: Re: [otrs] Reporting for accounting and setup best practices for multiple customers To: otrs(a)otrs.org Message-ID: <mkh0ph$bej$1(a)ger.gmane.org> Content-Type: text/plain; charset=UTF-8 Hi Holger, thanks for the info. The setup you describe is very close to the setup I would want to implement here. For the moment, I only have the following queues: Junk, Misc, Postmaster and Department 1. To get to your setup, I would need to add services (I have most already), and add SLA's (don't have those yet). Do you use different queue's for each department/customer or do you use a queue per type of SLA? As for part 2 of my message regarding the reporting, I constructed 2 SQL statements to run on my Postgresql db. It might be helpful to others so I'll post it here: /* List tickets and sum of time spent on the ticket in date period sorted by title, and create_time */ select t.tn Ticketnumber, u.first_name as Firstname, u.last_name as Lastname, t.title Title, sum(ta.time_unit) Time_unit, q.name Queue, t.customer_user_id Customer_user, t.customer_id Customer, t.create_time Ticket_created, min(a.create_time) First_action, max(a.create_time) Last_action from ticket t left join time_accounting ta on ta.ticket_id=t.id left join queue q on t.queue_id = q.id left join article a on a.id=ta.article_id left join users u on u.id = a.create_by where ta.time_unit is not null and ta.create_time between '2015-05-01' and '2014-05-31' group by t.tn, t.title, u.first_name, u.last_name, queue, customer_user, customer, t.create_time order by t.title /* List total time per Agent in a give period*/ select u.first_name as Firstname, u.last_name as Lastname, sum(ta.time_unit) from time_accounting ta left join users u on u.id = ta.create_by where u.id = ta.create_by and ta.create_time between '2015-05-01' and '2015-05-31' group by u.id Regards, Benedict

1 0

Change ticket state to open if another ticket is merged to it
by Rick Heisterhagen 01 Jun '15

01 Jun '15

Hi, I am looking for a way to let the state automatically change to open of the ticket that you merge another ticket into. The reason is that often customers do not care about the ticket number in the subject and open a new ticket and when merged to the "main" ticket it disappears because the "main" ticket is still in pending or close state. Is there a way to achieve this? Thanks!

1 0

PendingDiffTime per queue
by Rick Heisterhagen 01 Jun '15

01 Jun '15

Hey there, Does anyone know how to set the global value PendingDiffTime queue based in OTRS 3.3? I had the idea to maybe add a new MenuModule in the TicketZoomView present that to specific groups and add the custom DiffTime behind "<Item Key="Link">" but I don't know what. Any help is appreciated. Thanks!

1 0

Will there be a Windows Installer for OTRS 3.3.14?
by Rick Heisterhagen 01 Jun '15

01 Jun '15

Hi, I would like to install the latest minor patch but there is still a Windows Installer missing. http://ftp.otrs.org/pub/otrs/ Anyone an idea when it's released? Thanks!

1 0

Re: [otrs] Reporting for accounting and setup best practices for multiple customers
by Holger Erb 01 Jun '15

01 Jun '15

Hi, you can setup SLA on two different ways: QUEUE-based and SLA-based If you setup it queue-based you will have only one SLA for this queue, which means all your request within this queue are based on the same accounting etc. If you use SLA-based setup then you can define different SLAs for different Services and you will have different accounting possibilities. We have done it SLA-based and we collect all request for a country/department in one queue but we have the possibility to assign 1 out of 5 SLA-levels for a specific request. In practical it means, here three examples: - we assign SLA Prio 5 (highest) for server-related issues (here we have a first response within 30 min, a follow up within 2 h and a total solution of 4 hours). - we assign SLA Prio 3 (middle) for PC or Workgroup printer requests (here we have a first response within 3 hours, a follow up within 5 h and a total solution of 1 working day). - we assign SLA Prio 1 (lowest) for setup of new equipment/accounts/VPN access etc (here we have a first response within 1 working day, follow up within 8 hours, total solution of 1 week). You can use services as well and you can link them with all of your SLAs or with just one SLA, per example it makes no sense to enable SLA Prio 1 for a SERVER-related servcie (as no server in production can wait for a total repair time of 1 week, so we have disabled SLA Prio 1 and 3 for server-related services, only 5 is possible). You can run reports based on those timers (SLA violations etc., KPIs like first response time, Mean-Time-To-Repair, etc....) You can calculate as well for invoicing: (number of tickets per SLA level * by needed Time-Units * costs per Time-Units) - different SLA-levels have different pricing etc. Different customers are as well possible and different customers can be linked to all or totally different services etc. Several ways are possible to implement all of this and a deeper analyze of your individual specifications and requirements is needed and important to get the right things at the end of the day. I would recommend to test it on a test-system first before you configure (misconfigure) your production system. Hope it helps a bit and good luck. With best regards, HOLGER ERB | IT TEAM LEADER CLIENT SERVICES & COMPLIANCE (GTS) | MSX INTERNATIONAL OFFICE: +4922194700141 | MOBILE: +491638471062 | MAILTO: HERB(a)MSXI-EURO.COM -----Ursprüngliche Nachricht----- Von: otrs-bounces(a)otrs.org [mailto:otrs-bounces@otrs.org] Im Auftrag von otrs-request(a)otrs.org Gesendet: Donnerstag, 28. Mai 2015 14:00 An: otrs(a)otrs.org Betreff: otrs Digest, Vol 80, Issue 18 Send otrs mailing list submissions to otrs(a)otrs.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.otrs.org/cgi-bin/listinfo/otrs or, via email, send a message with subject or body 'help' to otrs-request(a)otrs.org You can reach the person managing the list at otrs-owner(a)otrs.org When replying, please edit your Subject line so it is more specific than "Re: Contents of otrs digest..." Today's Topics: 1. Reports for accounting and setup best practices for multiple customers (Linux4Bene) ---------------------------------------------------------------------- Message: 1 Date: Thu, 28 May 2015 10:59:53 +0000 (UTC) From: Linux4Bene <linux4bene(a)telenet.be> Subject: [otrs] Reports for accounting and setup best practices for multiple customers To: otrs(a)otrs.org Message-ID: <mk6sf9$p03$1(a)ger.gmane.org> Content-Type: text/plain; charset=UTF-8 Hi, I use otrs for almost 1.5 years and I like it a lot. I recently upgrade my 3.3.12 installation to 4.0.8. We now only have 1 queue for 1 internal department. This will change as we will now support more departments. This means there will be a need to report on the time spent on tickets per department. It will be used for time accounting and invoicing. A have a couple of questions regarding this: - The way we would implement it, is by using 1 queue per department. It would allows us to put SLA on a queue and so on. Is this good practice? I could go further and couple a specific e-mail address for every department so everything is neatly split per department. - In order to use the input of the tickets as base for accounting, we need some reports. I have looked through the reports but I can't seem to find the correct report. For instance, following situation: we have worked 300 minutes in april for department x, and 100 minutes in may for the same department. Management would like a couple of reports: - The tickets (title), time spent per ticket, and total time per given period for a given department. For april it would report all tickets and total time (300 minutes in our example). If a ticket is open for several months, then only the time spent in the given period should be reported to allow correct invoicing. The next month only 100 minutes should be reported. The time reported shouldn't depend on wether a ticket is open or closed. - Total ticket time per department (queue?) for a given period - Total ticket time per department (queue?), and per operator who worked on the ticket for a given period Any info or help with the reports and organisation of the queues would be helpful. Thanks, Benedict ------------------------------ --------------------------------------------------------------------- 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 End of otrs Digest, Vol 80, Issue 18 ************************************

2 1