the unique identifier is the subject of the email. but without any otrs number as these emails are all outside of otrs until i drag them in together. it needs to say "ohh here are 5 emails with the same subject, i will merge them into one ticket, 5 articles" but currently it says "ohh here are 5 emails without any otrs number, i will create a new ticket for each" which then means everyone gets 5 "new ticket" notifications for what is essentially only 1 issue and an Agent has to then merge the 5 together. On Mon, Oct 8, 2012 at 4:14 PM, David Boyes wrote:

Well, it DOES check the subject line – for the OTRS ticket # that would associate those emails. Does the subject line contain that? ****

** **

Otherwise is there some unique identifier that OTRS could use to tell they were associated? You could try to scan for it in the postmaster input, but there has to be some unique identifier that ties the issues together that OTRS can be programmed to find. ****

** **

*From:* otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] *On Behalf Of *Neil Simpson *Sent:* Monday, October 08, 2012 10:01 AM *To:* User questions and discussions about OTRS. *Subject:* [otrs] otrs auto merge feature****

** **

Hi,

We are using a "drop" system for mails that we want in otrs, if there's an email chain of 5 emails however and then you drop them all into otrs, you get 5 new tickets, not one ticket with 5 articles which is what i'd like as they all have same subject and relate to same issue. i know otrs like's to match by OTRS number but is there no way for it to check subject line aswell?

thanks

Neil****

--------------------------------------------------------------------- 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

the unique identifier is the subject of the email. There are a lot of ugly failure and/or race condition scenarios here. What would happen if another agent dropped in an email from another customer that happened to have the same subject line while you were dropping a batch in? Would you want that email incorporated into the same ticket as well? Somehow, I don't think that's what you want to happen, but that would be the result. You're going to have to create something else in each email that indicates that the multiple messages are somehow associated, either a custom header or manipulating the subject line in some special way outside OTRS. What implements your "drop box"? Is there a way that a script could be run when an item is dropped into the folder? If so, you could generate a unique id that would be applied to all messages dropped until it received a message with a special subject line that indicated a batch was complete and then obtained a OTRS ticket # and appended the messages to that ticket. Also, what should happen if another agent decides to do the same thing at the same time? Does every agent get a separate drop folder? Short of that, I don't think there's a viable way to do what you want to do out of the box. Incoming messages are individual transactions, and OTRS can't read your mind. Somehow you have to link them together in a consistent way, and that would involve a lot of custom code outside OTRS, maybe like this idea: If you have MS OneNote, look at how MS did the Send to OneNote button in Outlook. You'd have to write something like that, but you'd still have to have a unique identifier better than just the subject line.

Not quite true David, like I commented, try enabling SearchInReferences.

I have. It still misses fairly frequently (at least for us), which is why I didn't mention it. But, that may be a function of our customer base often having very old MUA/MTAs that don't reliably implement a lot of the newer mail headers in consistently useful ways. We have to have a 100% solution. SearchInReferences relies a lot on things out of your control (eg the algorithm that generates message ids at the sending MTA). It's a partial solution, but not a complete one. It also doesn't really address the race conditions of multiple agents dropping into the same folder from different customers. Maybe a better approach would be to write something that you use to post process a private folder for each agent on an IMAP server (eg, dump a copy of all the related messages into a subfolder, then run a separate app that opened a OTRS ticket, iterated through the folder items posting them to that ticket # and deleting them from the folder). All further correspondence is then done via OTRS (key point -- otherwise your statistics are going to get progressively more useless over time because OTRS can't measure response times, etc for stuff submitted this way). That should be fairly easy to write with the Perl IMAP library and the Perl SOAP library, and would be fairly easily to make work against any IMAP server implementation. Could be fairly easily batched if you used subfolders for each group of messages (schedule it in cron or something).

@Steven, thanks for the tip. set it to "yes" this morning and it's working beautifully. @David, i don't have any concerns about the "other" agents doing crazy things as it's only for my sysadmin team, we are using it slightly unconventionally, our support wont be using it like i mentioned previously, only us. thank you both. Neil On Mon, Oct 8, 2012 at 7:53 PM, Gerald Young wrote:

Attach to master ticket and send the master ticket.

On Mon, Oct 8, 2012 at 12:04 PM, David Boyes wrote:

...

...

Not quite true David, like I commented, try enabling SearchInReferences.

I have. It still misses fairly frequently (at least for us), which is why I didn't mention it. But, that may be a function of our customer base often having very old MUA/MTAs that don't reliably implement a lot of the newer mail headers in consistently useful ways. We have to have a 100% solution.

SearchInReferences relies a lot on things out of your control (eg the algorithm that generates message ids at the sending MTA). It's a partial solution, but not a complete one. It also doesn't really address the race conditions of multiple agents dropping into the same folder from different customers.

Maybe a better approach would be to write something that you use to post process a private folder for each agent on an IMAP server (eg, dump a copy of all the related messages into a subfolder, then run a separate app that opened a OTRS ticket, iterated through the folder items posting them to that ticket # and deleting them from the folder). All further correspondence is then done via OTRS (key point -- otherwise your statistics are going to get progressively more useless over time because OTRS can't measure response times, etc for stuff submitted this way).

That should be fairly easy to write with the Perl IMAP library and the Perl SOAP library, and would be fairly easily to make work against any IMAP server implementation. Could be fairly easily batched if you used subfolders for each group of messages (schedule it in cron or something).

--------------------------------------------------------------------- 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

--------------------------------------------------------------------- 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

Group membership will prevent engineer from seeing queues to which engineer does not belong. In addition, you can assign group(s) to modules in Sysconfig/Ticket/AgentModuleRegistration to prevent/assign access to that entry (Status View) by group membership. "My Queue" is intended for queues you control/can write to. On Tue, Oct 9, 2012 at 5:39 AM, Adi Ariyanto wrote:

Dear All****

** **

Is it possible to be setup that status view only can be seen by certain user(ex:IT Manager,Section Head) but engineer only can see they queue****

** **

And how to make my queue is visble with out rw permission ? my account which is rw permission able to see my queue but one of my team is unable to see myqueue****

** **

Thank You****

** **

** **

Best Regards****

Adi Ariyanto****

Computer Support & Maintenance**** ------------------------------

This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Bina Nusantara. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error.****

------------------------------ This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Bina Nusantara. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error.

--------------------------------------------------------------------- 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

Any queues that you have read permissions to will be visible under "My Queues" but the last time I used that view I think it will only actually show the queue names once there are tickets in the queue. FWIW I only every use the status view. Steve On 10 October 2012 09:33, Adi Ariyanto wrote:

"My Queue" is intended for queues you control/can write to.” à is there any way my queue is visible without RW permission ?

Best Regards

Adi Ariyanto

Computer Support & Maintenance

From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Gerald Young Sent: Tuesday, October 09, 2012 8:51 PM To: User questions and discussions about OTRS. Subject: Re: [otrs] Status view & My Queue

Group membership will prevent engineer from seeing queues to which engineer does not belong.

In addition, you can assign group(s) to modules in Sysconfig/Ticket/AgentModuleRegistration to prevent/assign access to that entry (Status View) by group membership.

"My Queue" is intended for queues you control/can write to.

On Tue, Oct 9, 2012 at 5:39 AM, Adi Ariyanto wrote:

Dear All

Is it possible to be setup that status view only can be seen by certain user(ex:IT Manager,Section Head) but engineer only can see they queue

And how to make my queue is visble with out rw permission ? my account which is rw permission able to see my queue but one of my team is unable to see myqueue

Thank You

Best Regards

Adi Ariyanto

Computer Support & Maintenance

________________________________

This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Bina Nusantara. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error.

________________________________

This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Bina Nusantara. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error.

--------------------------------------------------------------------- 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

________________________________

This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Bina Nusantara. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error.

________________________________ This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Bina Nusantara. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error.

--------------------------------------------------------------------- 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