Hello all,

Planning to put OTRS for trouble ticketing system. Installation complete and running. Need one help though.
When customers log in into the login panel, and want to create a new ticket, I want Postmaster to be the default queue in "TO:" field. I do not want customers to select it. Is there a way to do it? Either by editing Config.pm file or from Admin > SysConfig ?

Has anyone faced similar issue? Any ideas if that can be done?

Answering because this thread has gone so long without an answer ...

@linuxlover.chaitanya: The highest volume of OTRS questions and answers I found was on the OTRS mailing list. It might be worth joining and posting your question there. You can join here.

The OTRS mailing lists can be searched via this link.

Thanks Catkin for taking some time off to search and post the links. I think too that might be the only option now. Either LQ does not have enough members who use OTRS or they have not had the issue as mine.

Thanks for thanks Chaitanya

I didn't have to search for the links, they were in an OTRS evaluation project log. The pilot users wanted quite a lot of customisation (not including Postmaster as the default "TO:" field) and I ended up doing a lot of research/hacking. OTRS' biggest weakness is being a complex and not very intuitive product with no user manual. Ultimately we decided against OTRS in favour of googlemail custom tags and a proactive secretary.

BTW what does your WWR mean?

Yeah I agree that OTRS is not very well documented. And very complex too. But then it offers wide array of features that an IT support department would need like SLA's. This is one of the most important features when you are dealing with client systems and dead blocking issues. I am testing it and like it even though it is complex. I would like to go through it for some more time before I can put it in production though. And if there is no such customization where I can make some field default, then would need to either educate people on using it or replace the system entirely. Don't know as yet how this is going to take shape. And if there are some other ticketing systems that you think are stable enough for production use with SLA support please let me know. I have RT and OTRS under testing. osTicket is another that I like but does not support SLA and the report generation is also weak.

BTW, WWR in the sig means With Warm Regards

IDK of any suitable FOSS solutions other than RT and OTRS.

In retrospect our evaluation would have been a fairer test if I had been a user of the system. If I was doing it again I would use OTRS to manage queries and requests from the pilot system users.

WWR

Charles

I agree. We admins tend to test the applications with our view but sometimes forget the user point of view. While testing OTRS, I am going to keep this in mind and roll out a testing environment for users to give feedback to us. Now, OTRS is already installed and well integrated with Active Directory. But this creates one issue. All the customers have ID which is their email id. With this, I can not create Customer companies. And this also makes difficult for users to view others' tickets.
Another thing that I am looking into is, how to use only one queue and still keep the tickets raised for different departments apart. Why I am looking into this is, I dont want everyone to receive emails when ticket is generated. Only those concerned with the ticket should receive the mails. And I am not going to use emails for generating tickets. I want users to login to customer panel and create tickets. If they see log of queues, they might get disinterested and not open ticket for it being too complex or lengthy a process. This is also one issue that I need to handle.

I hope the things to well with our planned testing process.

BTW, thanks for your concerns and interest in the thread Charles.

The pilot users often had questions about how to use the system (not intuitively obvious!) and I, not being a user of the system could not answer or could not answer quickly enough to keep them happy. That's why I wrote "If I was doing it again I would use OTRS to manage queries and requests from the pilot system users". We were using email and a Google shared doc

AFAIK the OTRS designers intend user organisations to set up "groups" and have a dispatcher, assign incoming mails to the queue for the appropriate group. That may solve your "keep the tickets raised for different departments apart" requirement. IIRC OTRS has facilities to allow all tickets to be browsed, regardless of which queue they are in, so the desire for a single queue is not necessary.

OTRS is email-centric and does not readily support tickets which are initiated by phone call, personal visit or meeting actions -- they all get lumped together.

For me the google shared doc does not solve the issue and it has to be a ticketing system to keep everyone happy. I am fine with a system that will open tickets using emails. Not a big issue for us. The users are actually going to be happy with this. It makes easier for them to open tickets by just shooting a mail. But there are issues with this system particularly for us.
While opening a ticket using emails, some of the users tend to keep managers and other team members in loop using BCC or CC. And others not aware of this, reply to the mail and usually do a "Reply-all". This reply-all generates new tickets which should not happen. It should append the ticket but OTRS will not magically know that someone has done reply-all and opens a new ticket which is a false ticket.
This is the reason we are looking at web interface for ticket generation as well.

For other issue regarding different queues, I can have different emails for different departments and assign respective individual email addresses for each. Will have to educate users to send email to specific email for specific issues.

If nothing works, I am going to put a sweet and simple osTicket in place which can accept tickets in emails and web interface. It does not just integrate with AD that easily.

I wasn't suggesting the google shared doc as a solution -- I was telling of my mistake.

Don't email going out from OTRS have subject prefixed by an OTRS reference number? As long as people don't remove that when replying, OTRS uses it to add the new email to the ticket.

Yes but the outgoing emails from OTRS are sent only to the original poster and not everyone in the loop. So the OP knows that the ticket has been generated. But not everyone else. If the OP replies back to the email received from OTRS, everything works fine as expected, but when the others who are in the loop do a "Reply-all", the mail is also sent to OTRS which then generates a new ticket. And I am not blaming OTRS for that. We configure it to generate a ticket when it receives a mail. But people are either not aware of it or are just lazy to see whom they are sending a mail to.

Problem understood now.

Maybe if all the incoming mail without OTRS reference number prefixes in the subject went into the Raw queue and you had a dispatcher to assign them as appropriate, the dispatcher could assign all the problem mails to the Junk queue ... ?

Hmmm.... seems to be the only solution to me. Let me check if that works fine. Will probably do a bit different though. All the qualified tickets will go to Raw or postmaster queue and the unqualified tickets to Junk. I hope to make it work and finalize it as soon as possible.

... but then you would have to browse the Junk queue for emails for questions/reports etc. that initiate new tickets, no?

And you probably want a Junk queue to automatically send actual junk mail to ... ?

There does not seem to be one-size-fits-all solution to this. May be I will allow only web interface to be the point of contact for users to OTRS. This way I will at least be able to manage the queues better. And I would not have to worry about the false tickets getting generated by emails that are "reply-all". I am not sure if this is a good solution or not but it will get accepted into the policies for sure. Emails always have been headache for us when they start generating false tickets. But I am happy that the number has not gone too far too high as yet. But as the issues start increasing and as the number of users starts to go up, this will take a lot of time cleaning up instead of actual productive work. I am not entirely sure how this is going to work as yet.

And as you suggested, I tried to put RT to testing as well. But I was disappointed with it. Though it was not as complicated as OTRS, it still did not fit the bill somehow. And after so many days, I have actually started to like and favor OTRS for some reason unknown to me.

Keep posting your interesting thoughts. They are starting to get me ahead in some direction.