We are using the email collector module to collect emails from IMAP server and create ticket. All is working well with the exception of marking and email from the IMAP server as read. What is happening is the Email Collector is seeing all messages as new emails on IMAP server and creating a new ticket.
It is very strange behavior and does not let you delete tickets within Dolibarr as Dolibarr continues to create the ticket as the email is not marked as “Read” on the IMAP server.
I think I might be missing a setting somewhere, any insight would be greatly appreciated.
I have checked and it is not the provider. It appears I may be missing a setting when the email is pulled. The response is not being sent back to the IMAP server correctly from Dolibarr to mark the message as read.
I have also tested with a few other ticket systems and no issue there.
I just had a brief look at the source code of the email collector module (emailcollector.class.php). From what I found, the email message is read with the php command “imap_fetchstructure”. The IMAP standard allows the fetching of mails with either implicitly setting the \Seen flag for a message, or without. It seems to be the case, that the php function should set the \Seen flag, unless the parameter FT_PEEK is used, which is not the case here (I am not fully sure about this behaviour, most php documentation of this command is a bit vague in this respect).
However, there is the general problem that many IMAP servers do not always follow the standard, even (or rather especially) those of the big names (e.g. Google, Apple, Microsoft). The open source versions like dovecot are sometimes better in this regard. Maybe you can let us know the type of IMAP server that is involved in your case?
Remains the question, why the functionality differs with other ticket software. I might be the case that they ere explicitly setting the \Seen flag for each retrieved email. This could be an option for the implementation in Dolibarr as well as it would increase the chance that the IMAP server registers the correct status.
Hope that I am not misguiding you with my brief and cursory source code review. - And I am also aware that this does not help to solve your problem right now…
Thank you for this and the time spent in deeper look. We use a software called Surgemail it is very good software and has been online since 1997.
I would be willing to pay a developer to implement the explicit command, but we are very new to dolibarr and not very familiar with the community around this great platform.
Is this something you would be willing to freelance for? If so we do not have an issue paying for this and making it part of the overall release to help the community. It would help us internally tremendously as we are moving to standardize our company operations around Dolibarr.
Thanks for your kind feedback! While I am currently indeed evaluating to offer commercial services around ERP systems through my company, I think we can resolve this issue in a less official way.
I checked the feature on my server (based on Dolibarr 14.0.1) by using a dedicated mailbox for receiving tickets (tickets@…). Collecting was done with the pre-installed collector “Collect_Ticket_Requets”, which I started manually from the settings page of the email collector (Button “Collect now”). What I found was:
when a new, unread email gets processed into a new ticket, it gets marked as read in the Inbox and the collector displays the processing of the mail (so in general the implicit update of the state to read/seen seems to work)
when I ran the collector a second time while the email was marked as read, the message about processing the mail appeared again as before - it just did not create a second ticket for the same mail
then I set the state of the mail back to unread - same message and no duplicate ticket got created
All this makes me believe that the missing state change of processed mails to unread is not really the core of your trouble.
Did you already try to let Dolibarr automatically move the processed mails to a different folder in your mailbox? In the collector settings, you can define the source mailbox, which by default is INBOX, and a target mailbox where processed mails get moved to.
In order to use this, the target folder must already exist. Therefore, first you need to set up a new folder “processed” next to your inbox-folder (not within) with your regular e-mail client and then use this folder as the target folder in the collector settings (folder name might be case sensitive!).
I tested this as well and all processed emails got removed from the inbox and placed in this folder. If this does not disturb other internal procedures around your mailboxes, this seems like the best option.
