I'd like to promote my (free) fork of Mail to Ticket Automation.
v1 has been used for a couple of years now, all the main features work, but it's not the best code.
Currently in the process of being revamped (v2) and expected to go into production in our environment early January.
What
It is a fork of Combodo's Mail to Ticket Automation.
It offers some more flexibility and policies. With a policy, you can specify what happens to messages which do not comply with a policy.
For instance, you can choose to simply "mark as undesired" or "delete" a message with a certain title pattern. Or you can also send an automatic bounce message back to the user, explaining why the message is not processed. Sometimes a fallback is possible (for instance, specify a default subject when none is given).
Current default policies
email size (too big)
forbidden attachments (MIME type)
no subject
replies to resolved tickets
replies to closed tickets
messages referencing an unknown ticket (possibly deleted ticket or mistake)
unknown caller
other people in CC: field
undesired patterns in title (blocks further processing)
removing undesired patterns in subject (allows further processing)
...
Some other options
The idea is to add a few more options too, such as other ways to match the caller (based on my ContactMethod class).
Also some other minor changes/fixes, some of them were backported to the Combodo version as well. It also includes a fix for an issue we had with an O365 environment.
jefjefjefjefjefjefjefjefjefjefjefjefjefjefjefjef JhJhefferyJhJhefferyeryJhJhefrJhJhefferJefferyefferyHi Jeffrey
ThanksThanksThanksThanksThanksThanksThanksThanks
ThThanksThThanksanksThThanksThThanksanksanksThThThanks for utility.
Can you please let me know if there is any option to parse mail body of incoming email and map it with ticket field while creating a new ticketsticketsticketsticketsticketsticketsticketstickets
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
jefjefjefjefjefjefjefjefjefjefjefjefjefjefjefjef JhJhefferyJhJhefferyeryJhJhefrJhJhefferJefferyefferyHi Jeffrey
ThanksThanksThanksThanksThanksThanksThanksThanks
ThThanksThThanksanksThThanksThThanksanksanksThThThanks for utility.
Can you please let me know if there is any option to parse mail body of incoming email and map it with ticket field while creating a new ticketsticketsticketsticketsticketsticketsticketstickets
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For now it only uses "description" (for new tickets) and a configured AttributeCaseLog.
However, in the new version I'm working on and testing an option to allow default values for tickets and callers to refer to EmailMessage properties, including subject, body text, date, message ID, caller's name, caller's email, ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: we put this into production, as the main features are working and it's easier to actually have it process e-mails to see if any bugs occur.
Except for a minor one which has already been fixed, it seems to be working as expected. 😁
I'll soon start working on implementing an alternative "Find Caller" method using my ContactMethod class which is also available for free.
@jayantdusane This should now be possible. Most email properties are exposed as placeholders/variables. Or some custom but limited development (creating a "policy" to do this) might be enough too, depending on what exactly you were looking for.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An update is available to support the changed behavior in iTop 2.7, where "id" and "ref" are no longer exactly the same. It also contains other minor fixes and improvements.
It's been updated (and being tested now) once again.
It can process some malformed From: headers, resulting in less "decoding" errors.
Furthermore, it now allows reversed processing of email messages.
Apparently, when connecting through IMAP, Google (GMail) returns a list where email messages are sorted by arrival time from oldest to newest. Microsoft (Exchange, Outlook) does it the other way around; returning the newest messages first. This may cause some chronological issues in iTop (for instance: a ticket being created that a problem has already been solved; only to have the more recent ticket mentioning the initial problem).
It also supports IMAP options per mailbox, to accommodate some modern needs regarding IMAP settings/authentication for shared mailboxes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jeffrey, thank you for your fantastic work.
I tried the extension, however despite inserting the value Create or Update Tickets in the Behavior field, the tickets (incident) only continue to be created and never updated in case of a response. What could be the problem? Use as an Aruba Mail mailbox
For the record: there have been a bunch of updates lately. Some things were improved, some things were first fixed in this extension and later also reported to and implemented by Combodo in their own original version, sometimes in a slightly different way. Combodo also did a huge effort lately to improve their work, big kudos.
The main goal is to keep offering a more feature-rich extension in the future; while staying closely aligned with the original work by Combodo.
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to promote my (free) fork of Mail to Ticket Automation.
v1 has been used for a couple of years now, all the main features work, but it's not the best code.
Currently in the process of being revamped (v2) and expected to go into production in our environment early January.
What
It is a fork of Combodo's Mail to Ticket Automation.
It offers some more flexibility and policies. With a policy, you can specify what happens to messages which do not comply with a policy.
For instance, you can choose to simply "mark as undesired" or "delete" a message with a certain title pattern. Or you can also send an automatic bounce message back to the user, explaining why the message is not processed. Sometimes a fallback is possible (for instance, specify a default subject when none is given).
Current default policies
Some other options
The idea is to add a few more options too, such as other ways to match the caller (based on my ContactMethod class).
Also some other minor changes/fixes, some of them were backported to the Combodo version as well. It also includes a fix for an issue we had with an O365 environment.
Last edit: Jeffrey Bostoen 2020-10-29
jefjefjefjefjefjefjefjefjefjefjefjefjefjefjefjef JhJhefferyJhJhefferyeryJhJhefrJhJhefferJefferyefferyHi Jeffrey
ThanksThanksThanksThanksThanksThanksThanksThanks
ThThanksThThanksanksThThanksThThanksanksanksThThThanks for utility.
Can you please let me know if there is any option to parse mail body of incoming email and map it with ticket field while creating a new ticketsticketsticketsticketsticketsticketsticketstickets
jefjefjefjefjefjefjefjefjefjefjefjefjefjefjefjef JhJhefferyJhJhefferyeryJhJhefrJhJhefferJefferyefferyHi Jeffrey
ThanksThanksThanksThanksThanksThanksThanksThanks
ThThanksThThanksanksThThanksThThanksanksanksThThThanks for utility.
Can you please let me know if there is any option to parse mail body of incoming email and map it with ticket field while creating a new ticketsticketsticketsticketsticketsticketsticketstickets
For now it only uses "description" (for new tickets) and a configured AttributeCaseLog.
However, in the new version I'm working on and testing an option to allow default values for tickets and callers to refer to EmailMessage properties, including subject, body text, date, message ID, caller's name, caller's email, ...
Hi,
Maybe you could be interested in https://sourceforge.net/p/itop/discussion/third-party-extensions/thread/192e23a23c/
:)
Update: we put this into production, as the main features are working and it's easier to actually have it process e-mails to see if any bugs occur.
Except for a minor one which has already been fixed, it seems to be working as expected. 😁
I'll soon start working on implementing an alternative "Find Caller" method using my ContactMethod class which is also available for free.
@jayantdusane This should now be possible. Most email properties are exposed as placeholders/variables. Or some custom but limited development (creating a "policy" to do this) might be enough too, depending on what exactly you were looking for.
An update is available to support the changed behavior in iTop 2.7, where "id" and "ref" are no longer exactly the same. It also contains other minor fixes and improvements.
https://github.com/jbostoen/itop-jb-mail-to-ticket-automation-v2
Last edit: Jeffrey Bostoen 2020-10-29
It's been updated (and being tested now) once again.
It can process some malformed From: headers, resulting in less "decoding" errors.
Furthermore, it now allows reversed processing of email messages.
Apparently, when connecting through IMAP, Google (GMail) returns a list where email messages are sorted by arrival time from oldest to newest. Microsoft (Exchange, Outlook) does it the other way around; returning the newest messages first. This may cause some chronological issues in iTop (for instance: a ticket being created that a problem has already been solved; only to have the more recent ticket mentioning the initial problem).
It also supports IMAP options per mailbox, to accommodate some modern needs regarding IMAP settings/authentication for shared mailboxes.
New release also orders email messages chronologically for both Google and Microsoft accounts; probably others too.
Also includes other minor improvements/fixes.
The protocol supported by this extension is pop3\imap. Does it support Exchange protocol now?
No, but as far as I'm aware IMAP is still supported on Exchange.
Still heavily based on the amazing work by the Combodo team, I've also updated my Mail to Ticket Automation extension to support OAuth 2.0.
Definitely mind the release notes!
https://github.com/jbostoen/itop-jb-mail-to-ticket-automation-v2/releases
Mind that both Combodo's original work as my implementation are still very new. I'm already publishing this so people can test.
Hi Jeffrey, thank you for your fantastic work.
I tried the extension, however despite inserting the value Create or Update Tickets in the Behavior field, the tickets (incident) only continue to be created and never updated in case of a response. What could be the problem? Use as an Aruba Mail mailbox
For this, it works the same as the original Combodo version.
For the record: there have been a bunch of updates lately. Some things were improved, some things were first fixed in this extension and later also reported to and implemented by Combodo in their own original version, sometimes in a slightly different way. Combodo also did a huge effort lately to improve their work, big kudos.
The main goal is to keep offering a more feature-rich extension in the future; while staying closely aligned with the original work by Combodo.
Also Jeffrey did pushed some of his modifications in Combodo repo, many thanks Jeffrey !
Updated once again. Keeps evolving over time, with minor features and fixes.