148 lines
4.4 KiB
ReStructuredText
Executable File
148 lines
4.4 KiB
ReStructuredText
Executable File
To use this module, you need to:
|
|
|
|
#. Go to ``Job Queue`` menu
|
|
|
|
Developers
|
|
~~~~~~~~~~
|
|
|
|
**Configure default options for jobs**
|
|
|
|
In earlier versions, jobs could be configured using the ``@job`` decorator.
|
|
This is now obsolete, they can be configured using optional ``queue.job.function``
|
|
and ``queue.job.channel`` XML records.
|
|
|
|
Example of channel:
|
|
|
|
.. code-block:: XML
|
|
|
|
<record id="channel_sale" model="queue.job.channel">
|
|
<field name="name">sale</field>
|
|
<field name="parent_id" ref="queue_job.channel_root" />
|
|
</record>
|
|
|
|
Example of job function:
|
|
|
|
.. code-block:: XML
|
|
|
|
<record id="job_function_sale_order_action_done" model="queue.job.function">
|
|
<field name="model_id" ref="sale.model_sale_order"</field>
|
|
<field name="method">action_done</field>
|
|
<field name="channel_id" ref="channel_sale" />
|
|
<field name="related_action" eval='{"func_name": "custom_related_action"}' />
|
|
<field name="retry_pattern" eval="{1: 60, 2: 180, 3: 10, 5: 300}" />
|
|
</record>
|
|
|
|
The general form for the ``name`` is: ``<model.name>.method``.
|
|
|
|
The channel, related action and retry pattern options are optional, they are
|
|
documented below.
|
|
|
|
When writing modules, if 2+ modules add a job function or channel with the same
|
|
name (and parent for channels), they'll be merged in the same record, even if
|
|
they have different xmlids. On uninstall, the merged record is deleted when all
|
|
the modules using it are uninstalled.
|
|
|
|
|
|
**Job function: channel**
|
|
|
|
The channel where the job will be delayed. The default channel is ``root``.
|
|
|
|
**Job function: related action**
|
|
|
|
The *Related Action* appears as a button on the Job's view.
|
|
The button will execute the defined action.
|
|
|
|
The default one is to open the view of the record related to the job (form view
|
|
when there is a single record, list view for several records).
|
|
In many cases, the default related action is enough and doesn't need
|
|
customization, but it can be customized by providing a dictionary on the job
|
|
function:
|
|
|
|
.. code-block:: python
|
|
|
|
{
|
|
"enable": False,
|
|
"func_name": "related_action_partner",
|
|
"kwargs": {"name": "Partner"},
|
|
}
|
|
|
|
* ``enable``: when ``False``, the button has no effect (default: ``True``)
|
|
* ``func_name``: name of the method on ``queue.job`` that returns an action
|
|
* ``kwargs``: extra arguments to pass to the related action method
|
|
|
|
Example of related action code:
|
|
|
|
.. code-block:: python
|
|
|
|
class QueueJob(models.Model):
|
|
_inherit = 'queue.job'
|
|
|
|
def related_action_partner(self, name):
|
|
self.ensure_one()
|
|
model = self.model_name
|
|
partner = self.records
|
|
action = {
|
|
'name': name,
|
|
'type': 'ir.actions.act_window',
|
|
'res_model': model,
|
|
'view_type': 'form',
|
|
'view_mode': 'form',
|
|
'res_id': partner.id,
|
|
}
|
|
return action
|
|
|
|
|
|
**Job function: retry pattern**
|
|
|
|
When a job fails with a retryable error type, it is automatically
|
|
retried later. By default, the retry is always 10 minutes later.
|
|
|
|
A retry pattern can be configured on the job function. What a pattern represents
|
|
is "from X tries, postpone to Y seconds". It is expressed as a dictionary where
|
|
keys are tries and values are seconds to postpone as integers:
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
{
|
|
1: 10,
|
|
5: 20,
|
|
10: 30,
|
|
15: 300,
|
|
}
|
|
|
|
Based on this configuration, we can tell that:
|
|
|
|
* 5 first retries are postponed 10 seconds later
|
|
* retries 5 to 10 postponed 20 seconds later
|
|
* retries 10 to 15 postponed 30 seconds later
|
|
* all subsequent retries postponed 5 minutes later
|
|
|
|
**Bypass jobs on running Odoo**
|
|
|
|
When you are developing (ie: connector modules) you might want
|
|
to bypass the queue job and run your code immediately.
|
|
|
|
To do so you can set `TEST_QUEUE_JOB_NO_DELAY=1` in your enviroment.
|
|
|
|
**Bypass jobs in tests**
|
|
|
|
When writing tests on job-related methods is always tricky to deal with
|
|
delayed recordsets. To make your testing life easier
|
|
you can set `test_queue_job_no_delay=True` in the context.
|
|
|
|
Tip: you can do this at test case level like this
|
|
|
|
.. code-block:: python
|
|
|
|
@classmethod
|
|
def setUpClass(cls):
|
|
super().setUpClass()
|
|
cls.env = cls.env(context=dict(
|
|
cls.env.context,
|
|
test_queue_job_no_delay=True, # no jobs thanks
|
|
))
|
|
|
|
Then all your tests execute the job methods synchronously
|
|
without delaying any jobs.
|