RFC attachment_queue depending on queue_job

[florian-dacosta]

Today, the module attachment_queue implements its own way to process an attachement, by a cron. It should depends on queue_job as it does the same but better and it would benefits from all the cool features of queue_job. I think we could do something a bit like what was done in this module : https://github.com/akretion/sale-import/tree/14.0/queue_job_chunk

Here are the change I propose to do for v16 :

• Depends on queue_job - create one default channel "attachment_queue"
• Delay a job on attachment.queue creation
• get the default jobs attributes (priority, eta, max_retries, channel) from a method so it is overridable depending on the attachment.queue type (field file_type) Example :

def _get_job_attributes(self):
    self.ensure_one()
    return 10, 60*60, 10, attachment_queue

In case a module want different attributes for the file_type it is implementing, it would just have to override and change the returned value depending on its file_type.

• The job should not do anything in case the state is not pending
• The job should always be done after running, never fail. (in case of error during the process, the attachment_queue's state should become failed)
• We should keep the fields state and error message on attachment.queue and the job should fill the error message if any and change the state
• We should have 2 buttons on the attachment.queue : "Reschedule" : visibile when state is failed => put back the state to pending and delay a new job. "Run manually" : visible when state is pending or failed => run the attachment.queue synchronously (no job needed, raise errors in the normal way...)
• When an attachment is beeing processed, we should add a LOCK on it, so the job and synchronous button do not conflict. (in case record is lock, the job should retry later, or the synchronous button should display an error message to indicate it is already running.

[legalsylvain]

Nice proposal. I think that if the module dépends on queue, it could move into the oca/queue repo. Dont you think ?

[florian-dacosta]

I was wondering if we could have a better repo than server-tools for this one too. But I am not sure queue job is better. I mean, it is a dependency but that's it, maybe we should ask queue job PSCs what they think ? And attachment_synchronize (which depend on this attachment_queue module) would stay in server-tools ? @sebastienbeau @bealdav what do you think ?

[bealdav]

@legalsylvain @florian-dacosta I suppose queue_job maintainers don't want to have their repo commits polluted by modules which depends on queue_job.

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.