[FEATURE REQUEST] customize fetch-mail-interval

[rdxmb]

When using IMAP for fetching Mails, the interval is 10min by default. https://doc.otrs.com/doc/manual/admin/6.0/en/html/email-settings.html#email-receiving

I'd like to have this customizable on runtime. How can we do that?

[rdxmb]

is this the right position? Kernel/Config/Files/XML/Daemon.xml

[snip]
    <Setting Name="Daemon::SchedulerCronTaskManager::Task###FetchMail" Required="0" Valid="0" ConfigLevel="100">
        <Description Translatable="1">Fetch emails via fetchmail.</Description>
        <Navigation>Daemon::SchedulerCronTaskManager::Task</Navigation>
        <Value>
            <Hash>
                <Item Key="TaskName">FetchMail</Item>
                <Item Key="Schedule">*/5 * * * *</Item> <!-- default each five minutes -->
                <Item Key="Module">Kernel::System::FetchMail</Item>
                <Item Key="Function">Fetch</Item>
                <Item Key="MaximumParallelInstances">1</Item>
                <Item Key="Params">
                    <Array>
                    </Array>
                </Item>
            </Hash>
        </Value>
    </Setting>
[snip]

Or is there another place we can use for customizing?

//edited: Changing this has no result. Also, the default is definitely 10m and not 5

[juanluisbaptiste]

We had that feature before but I removed it because when you change it via cli you cannot change it later via sysconfig.

[rdxmb]

Is this still in sysconfig? I cannot find it.

[juanluisbaptiste]

Daemon::SchedulerCronTaskManager::Task###MailAccountFetch

[rdxmb]

Thanks! I just changed the value for that from */10 to */5 in./Kernel/Config/Files/XML/Daemon.xml

After a container restart, this works :+1: Is this update-persistent with this image?

# mountpoint /opt/otrs/Kernel/
/opt/otrs/Kernel/ is a mountpoint

[juanluisbaptiste]

Yes, but currently I'm not sure how editing settings directly on the filesystem vs doing it via sysconfig works.

I just did the same test, edited $OTRS_ROOT/Kernel/Config/Files/XML/Daemon.xml and then checked the value of Daemon::SchedulerCronTaskManager::Task###MailAccountFetch on sysconfig and it still has the default value, and it also asks for deployment of that configuration change. But, If you deploy the change the Daemon.xml file still has the edited value.

At this point I'm not really sure which one is taking precedence. Looking at the database, these settings are also stored in the table sysconfig_default_version and in other tables that seems to be used to track sysconfig changes, so this makes me think that the one that counts is the value set with sysconfig and if you later do any other change on it and deploy it your modification on Daemon.xml will get invalidated even if the file stays the same. That File seems to be present for the default value.

Your best bet is to find out if there is a way to modify that value using ${OTRS_ROOT}bin/otrs.Console.pl. Take a look at this function as an example, this is how I at least disable the email fetching which is useful for testing or debugging issues. AFAIR there was no way to change the fetch time with it, but maybe you can figure it out.

I hope this helps.

[rdxmb]

Hmm. I just changed that through the GUI to /4 instead of /5 . Daemon.xml:

    <Setting Name="Daemon::SchedulerCronTaskManager::Task###MailAccountFetch" Required="0" Valid="1" ConfigLevel="100">
        <Description Translatable="1">Fetch incoming emails from configured mail accounts.</Description>
        <Navigation>Daemon::SchedulerCronTaskManager::Task</Navigation>
        <Value>
            <Hash>
                <Item Key="TaskName">MailAccountFetch</Item>
                <Item Key="Schedule">*/5 * * * *</Item> <!-- default: every 10 minutes -->
                <Item Key="Module">Kernel::System::Console::Command::Maint::PostMaster::MailAccountFetch</Item>
                <Item Key="Function">Execute</Item>
                <Item Key="MaximumParallelInstances">1</Item>
                <Item Key="Params">
                    <Array>
                    </Array>
                </Item>
            </Hash>
        </Value>
    </Setting>

However, I will close this issue as this is working as expected at the moment with the changing of the file and restarting the pod. If this will be overwritten with the next image-upgrade, we can reopen this again.