July 2006 - dev - OTRS mailing lists

Feature request: response template -> next ticket state
by Sascha.Rommelfangen＠ses-astra.com 17 Jan '11

17 Jan '11

Hi, I have a suggestion for OTRS, probably someone wants to implement this: When creating a response template (Admin Area -> Responses; AdminResponse.pm), it would be nice to have the possibility to define the next ticket state. For example: I have a 'CloseWithStateExplanation' template, and often people forget to change the next ticket state. The result is a nice explanation about the state ('closed'), but the state is of course still 'open'. Best regards, Sascha Rommelfangen

3 3

Problem with HTML pages.
by odracir_seravat＠simplesnet.pt 27 Jul '06

27 Jul '06

Hello. I'm trying to show de e-mails received into OTRS directly in HTML style. I'm using iframes to do this. I have one iframe defined and need to put in it an HTML page with the body of the message received (contained in $Data{"Body"}). The problem i'm experience is where does OTRS loads any HTML page?Do i have to make any change in Apache configuration? Wich file is the Apache configuration file? When i do this: <iframe src=test.html></iframe> it appears in the iframe the following message: "The requested URL /otrs/test.html was not foun on this server." Regards Ricardo Tavares (Computer Engenieer) ------------------------------------------------------------------------ Simplesnet GTI, a net até 6 vezes mais rápida, ao mesmo preço de sempre! http://www.simplesnet.pt

1 0

Navigation bar: new items
by Alex Mihicinac 26 Jul '06

26 Jul '06

Hi all, I've managed to add custom icons to naviBar. What i need to do, that <a> tag would appear correct? In my case, I always get some URL prefix from OTRS because I'd like to point URL outside the OTRS system. TIA, Alex

2 1

AgentTicketQueue customization
by Simon A. F. Lund 26 Jul '06

26 Jul '06

I am trying to do a customized version of AgentTicketQueue, the agent users must be able to choose ticketstates, by clicking on simple links such as: State: New - Open - Closed - All I have successfully changed template and catching parameters, i have also modified assignment of "@ViewableStateIDs" accordingly so it contains correct values for the chosen state. My problem however is the call to "TicketAcceleratorIndex" from BuildQueueView. When i output the values of "@ViewableStateIDs" in the log (from within "TicketAcceleratorIndex") the values are of the types "Viewable" not the same values as the ones i have assigned in AgentTicketQueue. The tickets shown are in the correct states that the agentuser has chosen but my queuenav is messed up since TicketsAvail is incorrect, so browsing though the tickets is not possible... something is wrong with the assignment of scope of the assignment of "@ViewableStateIDs" but i cant find any documentation "TicketAcceleratorIndex", i've tried looking at the source in RuntimeDB.pm but i cant seem to find out why the values are wrong. Can anybody please tell me what is going wrong here? Im running otrs 2.0.1 -Simon

1 0

mail based agents
by Damir Dzeko 15 Jul '06

15 Jul '06

Hi OTRS Developers! After two years I'm back on the dev-list, surfing the archives, looking to find has something been done regarding issue covered on these URLs: http://wiki.koumbit.net/OpenTicketRequestSystem/MailBased http://www.mail-archive.com/dev@otrs.org/msg00511.html -- support for agents to do their thing using only their MUA of choice. The first page was set up by Antoine Beaupré and the other is answer to the two year old question about mail-based agent support, answered by Joerg Friedrich: insecure, auth problems, ... Since the agent-users (seasoned u**x admins) strongly required that, I've already implemented that functionality in v1.3 that is being used by an academic institution I'm working for. (Unfortunately, not in a very secure and rather in a Q&D ad-hoc way. But -- WFM! :)) Now we're planning an upgrade from v1.3 to whatever will be the newest release in a month or so, and before I get down to coding I wanted to check has something been done in the mean time and are there any plans for that. I'd be glad to do it properly this time: full support for answering tickets as an agent through mail client, also add support for ticket state management commands usually available only through web interface, and maybe even add security layer: PGP/SMIME signature validation or one-time-password checking. What to do, where to start? Kind regards, D.

1 0

Planned extension to SendmailBcc
by Wolf Wiegand 13 Jul '06

13 Jul '06

Hi, we've configured OTRS using SendmailBcc to send copies of all outgoing mails to an internal mailing list. That way, every member of that list (let's call them GroupA) can read all answers going out to customers, as well as notes which are added to a ticket. So far, so good. Right now, we are planning on having more colleagues use OTRS. These colleagues (GroupB) are not using OTRS right now, because they are from a different organisational unit. Most important, there is no need for GroupB to read everything that concerns GroupA and vice versa. Most of this can be achieved through preferred queues, except for what is sent out to agents via SendmailBcc. Therefore, we are planning to extend OTRS so that SendmailBcc can be configurable for each queue. Before we are doing any work that's already been done before :-) , has this maybe been already implemented by anyone? If not, is there any technical aspect that speaks against this solution? Upon a first glance, I'd try to implement this within System/Email.pm. At that point, is it possible to get the ticket object for which an email is being sent? Regards, Wolf -- Wolf Wiegand wiegand(a)univention.de Fon: +49 421 22232- 0 Entwicklung Linux for Your Business Univention GmbH http://www.univention.de/ Fax: +49 421 22232-99

2 1

Feature-requests for OTRS
by Alexander Scholler 06 Jul '06

06 Jul '06

Hi Dev-Team, JFYI... I collected some, I think useful feature request including motivation for further OTRS versions. Of course the use of these features should not be obligatory, but I think theses features could be a good enrichment of OTRS capabilities. 1a) Ability to edit article type (not necessarily content) after creation. Why? Some informations are not for the eyes of the customers 1b) Mail-replies (follow-ups) not coming from the mail-address of the current customer should be of type internal. Why? Otherwise possibly existing internal informations within the reply could be read by the customer. 2) Additional ticket-property: customer-supervisor beside the customer. Why: Some companies have 1st level support within the customer-teams or the OTRS-team give support for customer-companies. Each person within these companies can contact the OTRS-team, but a special person within the customer-company should be informed about this contact. This is already realized within the customer-webgui with "company-tickets". A corresponding solution within the mail-response-agent-gui would be that if a agent composes a mail-response, all customers which can view this ticket within their "company-tickets" are shown as possible mail-cc-recipient which only have to be checked to receive a copy of the mail. 3) Additional ITIL-specific ticket-properies like ticket-classification (incident, rfc, ...) 4) Phone-Calls: It should be distinguished whether a phone call comes from the customer or is made through the agent Why? For statistic reasons - if we wait for the customer to give use necessary informations it is important whether we had to remind him or he delivered the information within time. (I think the current storage in OTRS is that new phone tickets come from customers and phone calls within a ticket come from the agent.) 5) Automails after ticket-closure, perhaps with satisfaction survey. Why? To inform the customer about the closure of the ticket, so he is informed that the issue is finished. Customer-satisfaction is very important. Perhaps this mail could include a link to a survey-tool like phpSurveyor. Depending on the ticket-class (incident, rfc), the automail could differ. 6) ticket-state after follow-up: Why? There should be differed whether the ticket was of state-type closed or non-closed. I can provide my implementation of this. 7) Automail about ticket-creation not-until ticket-rating. Why? I ticket comes in as mail and a automail can be sent "ticket was received, but not yet seen by an agent". After the ticket was rated (priority reset etc.) by an agent, the service-desk has really realized the need of the customer and now a automail could be sent that "ticket was viewed and working will begin as soon as necessary" Now the customer don't has to call the service-desk "please consider my mail because he knows that the service-desk knows his request. 8) ticket-links (relationships between tickets) are great, but it would often be helpful to comment links made. Why? To see why a ticket-link was made 9) ticket-title for the agent Why? The ticket-subject changes with every received customer-reply. This makes it hard for the agent to refind tickets. So it would be helpful to give each ticket a changeable ticket-title. I think ArticleKey/Value is for this reason, but they cannot be changed within the webgui. 10) Free-text-field for every configuration-param within Sysconfig Why? OTRS is getting more and more complex. To overview all changes made from default settings, it would be helpful to make comment on every changed configuration-param e.g. why it was changed. I need some of these request because I plan to expand the usage of OTRS within our IT-organisation from today 1 team (5 persons) to 5 teams this summer. Some of these features will be realized by myself (I then could provide the code), some of them by the OTRS-GmbH (if I can convince my chief ;-) ). Overall I would be happy if these features reach the official OTRS-branch. Bye, Alex

1 0