- otrs - OTRS mailing lists

suppress automatic notification of agent about mail from that same agent
by Susan Dittmar 24 Feb '17

24 Feb '17

Hi, some of my collegues (OTRS agents) prefer to work on tickets using their prefered mail client instead of the OTRS framework. When doing so, they send a carbon copy to the otrs mail address. Thus their reply is added to the ticket history. OTRS sees this mail (the CC) as an external mail (which it is). Consequently it notifies any involved agent about this incoming external mail. For truely external mails, this notification is exactly what the collegues want. Is it possible to ask OTRS to suppress the notification in case the sender of the external mail and the recipient of the notification are identical? Thanks for any hints, Julius

1 0

CC recipients in AgentTicketCompose
by Personal Técnico 23 Feb '17

23 Feb '17

Hello, When I receive a ticket from a customer and he/she has created the ticket with a CC recipient (using mail), then, if I answer that ticket with an external mail, CC recipient is not included in AgentTicketCompose (only customer that created ticket appears as recipient "For:". I have modified "Ticket::Frontend::ComposeExcludeCcRecipients" from "yes" to "no" and from "no" to "yes", but in both cases, CC recipient is not included. How I configure OTRS for that purppose? Thanks a lot!!

1 0

HTML content formatting destroyed in replies
by Hinrich Aue 23 Feb '17

23 Feb '17

Hello, we have HTML mail from our customer. There is a table in their emails, that is quite important. when we answer their mails the table is somehow converted into some text representation. I wonder why the HTML content is not kept the way it was? Is there a setting for it? Hinrich Aue Sr. Software Engineer Kofax Development GmbH Wentzinger Strasse 19 79106 Freiburg Germany Tel: +49 761 452 69 57234 Fax: +49 761 452 69 58734 Hinrich.Aue(a)kofax.com blog<http://www.kofax.com/blog/> | twitter<https://twitter.com/Kofax> | linkedin<https://www.linkedin.com/company/kofax> | facebook<https://www.facebook.com/kofax.inc> | talent network<http://www.jobs.net/jobs/Kofax-Inc/join> ________________________________ This communication is only for the use of the intended recipient. It may contain confidential or proprietary information. If you are not the intended recipient or have received this communication in error, please notify the sender via phone and destroy this communication immediately. Kofax Development GmbH Sitz der Gesellschaft: Freiburg i. Brg. Registergericht: Amtsgericht Freiburg i.Br. Registernummer: HRB 7007 Gesch?ftsf?hrer: Bradford Weller, Christian Hefner, Daniel Geiger

1 0

CustomerID not being set anymore
by Kai Nissen 21 Feb '17

21 Feb '17

Hi there, I recently updated from 5.0.9 to 5.0.16, after which I noticed an unwanted change in behaviour: The system used to set the CustomerID to the e-mail address a message was received from. After the update, the field CustomerID remains empty. I looked around in the system settings but could not find anything that might be related to it. I also did not find any mentions of it being changed in the release notes. Of course, I copied the configuration file to the new installation folder (as described in the update manual). Does anyone know how to restore the previous behaviour? Cheers, Kai

1 0

[HOWTO] Timeout too long when a server fail on multiple authentication ldap servers
by ercanaro 21 Feb '17

21 Feb '17

Hi, my server is a Centos 6 with OTRS 3.3.10 My configuration provides this configuration type of situation: $Self->{'AuthModule1'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host1'} = 'ldaps://172.200.100.121'; $Self->{'AuthModule::LDAP::BaseDN1'} = 'dc=ict,dc=test,dc=com'; .... $Self->{'AuthModule2'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host1'} = 'ldaps://172.200.100.120'; $Self->{'AuthModule::LDAP::BaseDN1'} = 'dc=ict,dc=test,dc=com';: ... $Self->{'AuthModule::LDAP::Params'} = { port => 636, *timeout => 120, *(if i modify this value nothing change) async => 0, version => 3, }; ... If the first server fail, the authentication switches to the second ldap server but the time is 60-70 in seconds or more! is possibile to change this timeout? thanks in advance.

1 0

OTRS Scheduler Daemon Cron: MailAccountFetch
by Placide Lysias NJAMI 18 Feb '17

18 Feb '17

OTRS 5.0.16 has been installed. The file Kernel/System/MailAccount/POP3S.pm is patched as per below link. Check the patch below https://github.com/OTRS/otrs/commit/8cb87ff9ef9789606a38e3d70599e38a1f8e9246 But still, we received every 10 min below message : [Sat Feb 18 14:20:02 2017] otrs.Daemon.pl: using SSL support of Net::POP3 3.05 instead of SSLGlue at /opt/otrs/Kernel/cpan-lib/Net/SSLGlue/POP3.pm line 12. Best Regards / Cordialement ----- Placide Lysias NJAMI | IT MANAGER GOLDEN EXOTICS LTD – GHANA P.O. Box K.I.A. 16105 - ACCRA Email: p.njami(a)gelgh.com<mailto:p.njami@gelgh.com> -----Message d'origine----- De : Helpdesk GEL [mailto:helpdesk@gelgh.com] Envoyé : samedi 18 février 2017 14h 20 À : admin(a)gelgh.com Objet : OTRS Scheduler Daemon Cron: MailAccountFetch [Sat Feb 18 14:20:02 2017] otrs.Daemon.pl: using SSL support of Net::POP3 3.05 instead of SSLGlue at /opt/otrs/Kernel/cpan-lib/Net/SSLGlue/POP3.pm line 12.

1 0

closed tickets with same external ticket number are not reopened
by Hinrich Aue 17 Feb '17

17 Feb '17

This was my mistake, I did configure my follow up filter wrong and forgot the state "closed" Now it is working like a charm. Hinrich Aue Sr. Software Engineer Kofax Development GmbH Wentzinger Strasse 19 79106 Freiburg Germany Tel: +49 761 452 69 57234 Fax: +49 761 452 69 58734 Hinrich.Aue(a)kofax.com blog<http://www.kofax.com/blog/> | twitter<https://twitter.com/Kofax> | linkedin<https://www.linkedin.com/company/kofax> | facebook<https://www.facebook.com/kofax.inc> | talent network<http://www.jobs.net/jobs/Kofax-Inc/join> ________________________________ This communication is only for the use of the intended recipient. It may contain confidential or proprietary information. If you are not the intended recipient or have received this communication in error, please notify the sender via phone and destroy this communication immediately. Kofax Development GmbH Sitz der Gesellschaft: Freiburg i. Brg. Registergericht: Amtsgericht Freiburg i.Br. Registernummer: HRB 7007 Gesch?ftsf?hrer: Bradford Weller, Christian Hefner, Daniel Geiger

1 0

Kerberos works for Apache directory, but not for OTRS
by "Stefan Günther" 17 Feb '17

17 Feb '17

1 0

closed tickets with same external ticket number are not reopened
by Hinrich Aue 16 Feb '17

16 Feb '17

hello, we just realized that closed tickets with the same external ticket number are not re-opened when they have been closed already. even though I set PostmasterFollowUpStateClosed to open The queues allow to open on flow ups is this default behaviour? do I have to work on the follow up recognition? we do not have the OTRS ticket numbers in the subject! Is this even possible wihout? thanks, Hinrich Hinrich Aue Sr. Software Engineer Kofax Development GmbH Wentzinger Strasse 19 79106 Freiburg Germany Tel: +49 761 452 69 57234 Fax: +49 761 452 69 58734 Hinrich.Aue(a)kofax.com blog<http://www.kofax.com/blog/> | twitter<https://twitter.com/Kofax> | linkedin<https://www.linkedin.com/company/kofax> | facebook<https://www.facebook.com/kofax.inc> | talent network<http://www.jobs.net/jobs/Kofax-Inc/join> ________________________________ This communication is only for the use of the intended recipient. It may contain confidential or proprietary information. If you are not the intended recipient or have received this communication in error, please notify the sender via phone and destroy this communication immediately. Kofax Development GmbH Sitz der Gesellschaft: Freiburg i. Brg. Registergericht: Amtsgericht Freiburg i.Br. Registernummer: HRB 7007 Gesch?ftsf?hrer: Bradford Weller, Christian Hefner, Daniel Geiger

2 1

OTRS 5 - View and compose permissions but not to close tickets
by Manuel Martínez Valls 16 Feb '17

16 Feb '17

Hi, We would like to implement a scheme with agents having all the permissions on some queues (i.e. 'rw' permission on Main queues) but not on secondary queues on which they should be only allowed to read, reply and change owner, but not to close the tickets. We want also to allow the 'move_to' permission onto any queue. For example, consider the next scenario: a 3-queue scheme with 3 agents. Agent1: is allowed to do everything on the main queue Q1. He can colaborate on the Q2 (secondary), and have no access to Q3 Agent2: is allowed to do everything on Q1 and Q2, and is colaborator on Q3 Agent3: Main queues Q2 and Q3, and secondary queue Q1. To achieve this, I've done the following: * Add 'close' and 'compose' permissions (before 'rw) on Ticket->Core::Ticket System::Permission * Change Frontend::Agent::Ticket::ViewQueue Ticket::QueueViewAllPossibleTickets to 'Yes', to allow agents to see the tickets in the 'ro' Queues. Then I've created many roles: Main1role: with all the permissions on Q1 Sec1role: with the permissions: ro, move_into, note, owner and compose ... (same with the other queues). And finally set Agent-Role relations: * User1: Main1role, Sec2role * User2: Main1role, Main2role, Sec3role * User3: Sec1role, Main2role, Main3role Now, * Agents are allowed to do everything in their main queues (as expected) and to see the tickets in the secondary queues they need to go to the 'Queue View' (they do not see them in the dashboard). That's right. *Agents are able to read a ticket, and reply and, from the begining, they do not have the 'Close' option in the ticket menu on secondary queues. As expected. That's right also. * But, when they reply a ticket of a secondary queue, they are able to choose as 'Next ticket state' the closed state, and close the ticket. This is strange, because the agent has not the 'close' permission on this queue. Moreover, after replying a ticket, the user becomes owner and then he is able to see the 'Close' option in the ticket menu, and also to close the ticket, and he should not, as in the previous case. Can you help me to make this scheme work? Regards, Manuel Martínez --

3 3