Vanliga tekniska frågor¶

”Schemalagda åtgärder körs inte vid exakt den tidpunkt de förväntades”¶

På Odoo.sh-plattformen kan vi inte garantera en exakt körtid för schemalagda åtgärder.

Detta beror på att det kan finnas flera kunder på samma server, och vi måste garantera en rättvis andel av servern för varje kund. Schemalagda åtgärder implementeras därför något annorlunda än på en vanlig Odoo-server, och körs enligt en bästa ansträngning-policy.

Finns det ”bästa praxis” för schemalagda åtgärder?¶

Odoo.sh begränsar alltid exekveringstiden för schemalagda åtgärder (*aka* crons). Därför måste du ha detta faktum i åtanke när du utvecklar dina egna crons.

Vi rekommenderar detta:

• Dina schemalagda åtgärder bör fungera på små partier av poster.

• Dina schemalagda åtgärder bör utföra sitt arbete efter bearbetning av varje batch; på så sätt behöver du inte börja om från början om de avbryts av tidsgränsen.

• Dina schemalagda åtgärder bör vara idempotenta: de får inte orsaka bieffekter om de startas oftare än förväntat.

How can I automate tasks when an IP address change occurs?¶

Odoo.sh notifies project administrators of IP address changes. Additionally, when the IP address of a production instance changes, an HTTP GET request is made to the path /_odoo.sh/ip-change with the new IP address included as a query string parameter (new), along with the previous IP address as an additional parameter (old).

This mechanism allows custom actions to be applied in response to the IP address change (e.g., sending an email, contacting a firewall API, configuring database objects, etc.)

For security reasons, the /_odoo.sh/ip-change route is accessible only internally by the platform itself and returns a 403 response if accessed through any other means.

Here is a pseudo-implementation example:

class IPChangeController(http.Controller):

    @http.route('/_odoo.sh/ip-change', auth='public')
    def ip_change(self, old=None, new=None):
        _logger.info("IP address changed from %s to %s", old, new)
        # Then perform whatever action required for your use case, e.g., update an
        # ir.config_parameter, send an email, contact an external firewall service's API, ...
        return 'ok'