Postmaster Filter

[dolfiz]

any other ways to run rules on tickets when created from web interface

No. You set what you want via sysconfig and acl.

Mmh, you said "No" but a Generic Agent triggered by TicketCreate event isn't a way to run rules on a ticket? Maybe not the preferred solution but it should work, no?

By the way, postmaster filter apply only during email fetch, do you confirm it? If an agent manually creates a phone/email ticket no postmaster filters will be checked, right?

Is there a way to catch the mailbox email is coming from? Our OTRS fetches from 3 different mailboxes. I would like to set a dynamic field with the name of the mailbox is coming from and I used a Postmaster filter that check the "To:" field of the email. Unfortunately on that mailbox there are emails with different values on the "to:" header (I don't know why or how) so I'm not sure to set that field with the proper value in this way.

[crythias]

a Generic Agent triggered by TicketCreate event isn't a way to run rules on a ticket?

sure.

postmaster filter apply only during email fetch, do you confirm it?

yes

If an agent manually creates a phone/email ticket no postmaster filters will be checked, right?

correct

Is there a way to catch the mailbox email is coming from?

yes... the sender mailbox email (From?) or (To?)

I would like to set a dynamic field with the name of the mailbox is coming from

Why? Dispatch by To.

[dolfiz]

Is there a way to catch the mailbox email is coming from?

yes... the sender mailbox email (From?) or (To?)

I would like to set a dynamic field with the name of the mailbox is coming from

Why? Dispatch by To.

Sorry, I did not explain it well.

Suppose we have to mailbox that OTRS use for fetching AAA@mydomain.com and BBB@mydomain.com. In the first mailbox almost all emails have obviously AAA@mydomain.com as "TO:", but there are also some email that has BBB@mydomain.com. Why? I don't know, maybe someone accessed the mailbox and moved from one to the other but I really don't care. I want to set a dynamic field with one of the two mailbox names, based on which mailbox the email is coming from during fetch operation. So, every email that has been fetched from AAA@mydomain.com has to be set as AAA@mydomain.com, despite the "To:" header of the mail talk about a different address.

A way to perform this is to fetch email from different mailboxes on different queues and to use a generic agent to set that dynamic field based on the queue. Now all our mailboxes go on the same queue and I would like to know if there is a different way to perform such action without adding queues.

[crythias]

Postmaster filter Match To : AAA@...
Set Email Headers X-OTRS-DynamicField-MyField : AAA

Lather, rinse, repeat.

[dolfiz]

Postmaster filter Match To : AAA@...
Set Email Headers X-OTRS-DynamicField-MyField : AAA

That is what I've done but it can't work. If in the AAA@ mailbox there is a mail that as BBB@ as address in the "To:" field, then my postmaster filter set my dyn field with BBB@ and is exactly what I want to avoid.

I guess that I have to dispatch to different queues and use a generic agent to set the dyn field.

[crythias]

If in the AAA@ mailbox there is a mail that as BBB@ as address in the "To:" field, then my postmaster filter set my dyn field with BBB@ and is exactly what I want to avoid.

*headdesk*.

The QUEUE set to the box IS the Dynamic field you seek.

[dolfiz]

*headdesk*.

The QUEUE set to the box IS the Dynamic field you seek.

Ahahah Yes yes, it represents that information, but not on a field within the ticket. So I need to create a generic agent that makes the information stored on the field, so the ticket, also if it changes queue, will continue to store that info.

Thanks crythias, hope you did not hurt your forehead

[crythias]

have fun... How does this solve the ticket request?

[dolfiz]

How does this solve the ticket request?

What do you mean? Which ticket request? Doh... I'm feeling dumb... is it a joke?

[crythias]

How does knowing what email address the ticket was sent to help you solve the purpose of having a ticketing system? That is - effectively directing customer requests to agents who are able to complete the ticket request and, you know, complete the ticket request?

[dolfiz]

How does knowing what email address the ticket was sent to help you solve the purpose of having a ticketing system? That is - effectively directing customer requests to agents who are able to complete the ticket request and, you know, complete the ticket request?

In our implementation the ticket changes queue due to many reason (i.e. multiple support levels), but we need to know which mailbox the ticket is coming from, regardless of the current queue it is stored within. Two different ticket coming from different mailboxes can be on the same queue. The purpose of storing such information can be statistical analisys, for example.

[crythias]

I gathered it was statistical analysis. It's just ... the data points that are requested ... never mind. I see these requests over and over and am like... why does anyone care? Isn't the point to answer the ticket? Does it really matter how it arrives? Is it going to make any difference to the quality of response? Would you be using this information to atrophy a response method? If so, why not just prohibit that response method now? Why track it? Why accept it? If you're going to continue to accept it, why measure it?

Yes, I know... someone above your pay grade asked for it.

Generic Agent.

[dolfiz]

Yes, I know... someone above your pay grade asked for it.

I agree with you. So many times "they" are concerned about stupid things and do not care about the quality of the support service itself.

Anyway, in this case it makes sense because the support service is paid in a different way, I guess, based on the mailbox the ticket is coming from (diffente mailboxes = different services = different request typology/complexity = different payment).