Forum GLPI-Project

bdg66

Member

Registered: 2012-02-21

Posts: 14

mailgate problem in GLPI v 0.83.2

Hi everybody,

2 weeks ago we upgraded from GLPI version 0.72.3 to 0.83.2(Windows 2008 R2 and xampp). Mailimport etc. ran through a scheduled cron task(version 0.72.3). This worked fine.
Since the upgrade we have problems with the mailgate in the 'automatic actions'.
If we run it scheduled it imports the mails as tickets in GLPI but does so every scheduled run it makes. The INBOX on the mailreceivers is not emptied, so it will import the tickets on every run. If I empty the INBOX of the receivers it keeps on generating tickets but this time with an empty description. Solution here is to kill the running task and disable the 'automatic action' for the mailgate.

If I run the 'get email tickets now' in the individual mailreceivers it works fine: mailbox gets emptied and tickets are generated only once.
So I now run all receivers by hand 2 times every day but this is not sustainable. I tried to run the scheduled crontask but this doesnt work as expected, it looks like it does the mailgate 'automatic action' and that is what I do not want. Also in the old version it gave me information on how many mails were imported and the tickets that were created. Now there is very little info in the cron.log.

How can I do a scheduled task for every mail receiver as in the old version of GLPI. And how do I get my extended info back.

I tried to figure out what the difference is in 'automatic action' between GLPI and CLI modus but I can''t find any explanation.

Thanks in advance.

Regards, Bert de Groot

tomolimo

Member

From: Grenoble, France

Registered: 2009-05-12

Posts: 515

Re: mailgate problem in GLPI v 0.83.2

I've done a migration from 0.80.3 to 0.83.31 and I've configured one receiver (for the moment), and it goes well.
For the CLI/GLPI explanations:
* CLI means that the job will be executed by the cron task (normally running at a fixed frequency with AT command or else). It means that the job is executed on the server in background mode (no influence on GLPI response time).
* GLPI means that during the server execution of a GLPI page the job will be executed. It means that the response time of a GLPI page could be hindered by the execution time of a job.
Of course I've implemented the CLI mode for all the 'automatic actions' on my GLPI server.
regards,
Tomolimo

---

GLPI 9.2.4 - PHP 7.2.13 x64 / ProcessMaker 3.3.0-community-RE-1.7 - PHP 7.1.24 x64 / Windows 2012 x64 / IIS 8.5 / MySQL 5.7.17 x64
Worldwide: >12316 PC, >9400 users (16 languages, >11 timezones), >360k tickets, >3600 entities, >4200 groups
Raynet is ARaymond (http://www.araymond.com) IT service management

bdg66

Member

Registered: 2012-02-21

Posts: 14

Re: mailgate problem in GLPI v 0.83.2

Hi Tomolimo,

Thanks for the clarification on the CLI/GLPI mode.
We run about 15 mailreceivers, so its a little bit more complex. I discovered that in the new version the rules for assigning tickets were split up into two sections, 'rules for tickets' and 'rules for mailreceivers'. So I will have to look into that.

I think I found our problem with the mailreceivers locking up on getting the mail. If there is an email in the mailbox that does not not follow a rule or has an email address that isn't recognised, the system lockes up, puts the mail in the section 'List of not imported mails' (reason of rebuff: unknown user) and leaves the Inbox of the mailreceiver uncleared. So on every next run it encounters the same problem and keeps on generating new tickets from the mails and leaving the Inbox uncleared.

In the old system(0.72.3) it just generated a ticket and cleared the Inbox.
So I am looking for a way to accomplish this for the new system(0.83.2).

The solution must be in the rules but as I said, I will have to look into that. Any suggestions though would be appreciated.;-)

Regards Bert

bdg66

Member

Registered: 2012-02-21

Posts: 14

Re: mailgate problem in GLPI v 0.83.2

So here a little update on current affairs.

1. I found another post on the forum in wich you kan instruct the system to make a ticket even when the user is unknown. But the thing is that it will create a ticket, usually with an empty description, but will leave the mail (un)read in the mailbox. So on every run it will import the mail again. This is highly undesirable.
2. There was a mail in the inbox that would generate a ticket with an empty description. I removed the mail from the inbox but with every run form the mailreceiver it kept on generating a new ticket. It lookes like it is cached in GLPI somewhere. The only way to stop this behaviour is to shut down Apache and MySQL and start them up again.

Regards, Bert