Extensions for iTop . New classes (SIM cards, Monitors, IP Devices), more powerful Mail to Ticket automation, basic info on pro extensions such as geometry and ticket merge, some concepts (Check Out system), several small tweaks.
In recent versions of iTop's official Ticket from email extension it's possible to add other contacts in the email to tickets automatically.
Recently, despite several warnings about this, people continue to send mails to our helpdesk while having other recipients as well (against our guidelines).
While looking at the code of the ticket-from-email extension, there were some things I haven't figured out yet.
most code is in PHP classes; but when/why do functions get their methods in the Data Model?
how is 'combodo-email-synchro' vs 'itop-standard-email-synchro' (which requires the first) intended? What's the idea in splitting this up in two extensions?
I was originally planning to contribute some small modifications to the current ticket-from-email extension; but it seems my changes might be going a bit further than I anticipated. So I'm contemplating whether to start from scratch, or just replace one of the two with a version of my own, or perhaps still just stay as close to the original as possible.
The basic idea I have now is to separate actual errors (decoding, failure to create new contacts for unknown callers this was wanted behavior) and policy violations (attachment too big, multiple recipients, no subject, replying to closed ticket...).
For actual errors, a specific person/team/mail address should be able to receive information about the error and the original mail could be attached. Original email could be marked as error or deleted.
For policy violations, it should be the sender who gets told to comply with guidelines. We've been using a precanned reply so far, but I'd like the user to be informed right away, probably using a (case specific) notification instead. (rather than precanned reply, but notification might also just be stored as a property of this mail inbox rather than using the generic 'notifications'/ActionEmail. Original email could be marked as error or deleted.
So I can see some different wanted behaviors for unknown callers. (mark mail as error, just delete mail; forward to someone specific and/or send notification to the unknown caller).
Some might need to be looked into if it's an actual error or a user violation (I noticed something about a Request number which could not be found).7
Another thing to consider: the policies might be shared amongst mailboxes. Little hazzle for users with only one mailbox; yet very handy for cases where multiple mailboxes (or mailbox folders) are scanned.
In recent versions of iTop's official Ticket from email extension it's possible to add other contacts in the email to tickets automatically.
Recently, despite several warnings about this, people continue to send mails to our helpdesk while having other recipients as well (against our guidelines).
While looking at the code of the ticket-from-email extension, there were some things I haven't figured out yet.
I was originally planning to contribute some small modifications to the current ticket-from-email extension; but it seems my changes might be going a bit further than I anticipated. So I'm contemplating whether to start from scratch, or just replace one of the two with a version of my own, or perhaps still just stay as close to the original as possible.
The basic idea I have now is to separate actual errors (decoding, failure to create new contacts for unknown callers this was wanted behavior) and policy violations (attachment too big, multiple recipients, no subject, replying to closed ticket...).
For actual errors, a specific person/team/mail address should be able to receive information about the error and the original mail could be attached. Original email could be marked as error or deleted.
For policy violations, it should be the sender who gets told to comply with guidelines. We've been using a precanned reply so far, but I'd like the user to be informed right away, probably using a (case specific) notification instead. (rather than precanned reply, but notification might also just be stored as a property of this mail inbox rather than using the generic 'notifications'/ActionEmail. Original email could be marked as error or deleted.
So I can see some different wanted behaviors for unknown callers. (mark mail as error, just delete mail; forward to someone specific and/or send notification to the unknown caller).
Some might need to be looked into if it's an actual error or a user violation (I noticed something about a Request number which could not be found).7
Another thing to consider: the policies might be shared amongst mailboxes. Little hazzle for users with only one mailbox; yet very handy for cases where multiple mailboxes (or mailbox folders) are scanned.