a caller has an improperly configured mail rule set up, replying to each message he receives. In this case, the message and subject will be identical; most likely not even containing a ticket reference
another ticket system replies to our instance. Our ticket system or the other ticket system might not list the ticket reference in any detectable way (likely subject title). There will be a small variation in this case.
The policy would check:
if there's already a recent ticket with the same title and same description
if there's already a recent ticket with the same title and/or last public log entry
WIth recent, I mean a ticket within the last X hours (configuration setting).
The message would be marked as undesired.
In the current implementation order of policies, this check should wait till the caller is detected.
This protection could either be written in the create/update ticket policy (con: might need a separate setting); or as a separate policy (con: will do some work twice).
However, agents might already have deleted such kind of tickets; making it impossible to just scan the user's open tickets. This leads me to the idea that there should be a table with records similar to the EmailReplica objects; but which is pruned a lot more. Preferably, it contains: person_id (Ticket has person_id and not contact_id), timestamp, subject, body.
Another configuration setting might be necessary to strip out other ticket system references; or some other form of smart detection.
The idea is to have loop protection built-in.
Use cases:
The policy would check:
WIth recent, I mean a ticket within the last X hours (configuration setting). The message would be marked as undesired.
In the current implementation order of policies, this check should wait till the caller is detected.
This protection could either be written in the create/update ticket policy (con: might need a separate setting); or as a separate policy (con: will do some work twice).
However, agents might already have deleted such kind of tickets; making it impossible to just scan the user's open tickets. This leads me to the idea that there should be a table with records similar to the EmailReplica objects; but which is pruned a lot more. Preferably, it contains: person_id (Ticket has person_id and not contact_id), timestamp, subject, body.
Another configuration setting might be necessary to strip out other ticket system references; or some other form of smart detection.