Generic assignation of document


(Cédric Krier) #1

Rational

There are documents in the system that are waiting for action from the user.
But the problem is when the number of users is large enough, they will often compete to work on the same document (if there are no physical constraints which prevent it).
So an usual design is to assign the document to an employee but the process is manual and there are still a competition for the assignation (but at least it is earlier).

Proposal

The idea is to see all those documents as part of a queue and let the server assign them by picking from the queue. Indeed we should probably define a queue per specific action and document.
So a user will be assigned to many queues depending of his role.
When he is free to perform a task, he will run a generic wizard which will pick a unassigned document from one of the queues. The wizard will assign him to the document and open it.
Once the user has finished with the document, he will run again the wizard and so on.
The selection of the queue should be carefully designed because it should probably not try to empty one queue before selecting from another. Indeed the selection should be random but using weight for each queue, the computed weight should be based on the number of record in the queue and the coefficient of importance of the queue. The last coefficient is important because some queue may be very small but it could be very important to process them while other may always be full but less important to process. Finally the document should be picked inside a queue using the order.

Models

  • queue.group

    • name
    • priority (integer)
    • queues (onemany to queue)
  • queue

    • group (many2one to queue.group)
    • model (many2one to ir.model)
    • domain (PYSON expression to find records)
    • order (PYSON expression to order records)
    • assignation field (manyone to ir.model.field)
    • action (optional, many2one to ir.action)
  • res.user

    • queues (many2many to queue.group)

Wizards

  • queue.pick

    • start: Transition to select document from queues
    • open: Open the document using the action defined on the queue
  • queue.unassign

    • start: View to ask for user and queues
    • unassign: Unassign (write None) all pending documents assigned to the user

Implementation

Future

  • Implement assignation for document that need it: waiting customer shipment, draft purchase, draft sale, lead etc.
  • Add counting on menu entry for unassigned.

(Nicolas Évrard) #2

And why not a simple round robin solution ? Or even something more complicated as Weighted Fair Queuing


(Cédric Krier) #3

Because they require to store information and so it will create a contention lock.
Also each user will have a different sets of queues so we can not reuse previous choice to make a new one.


(Jean Cavallo) #4

Why setting the queues Many2Many on the user rather than on the group ? In large organizations, there will usually be teams with the same pool of queues.


(Cédric Krier) #5

Because for me, it is different purpose. Groups are for access rights and it is not because you have access rights that you have to work on it.
I even think user should be allowed to select the queues they work on because some queues may require to be physically somewhere (ex: in the warehouse to manage shipments).
But maybe we should link with a group of queues instead of directly the queue. Like that a group can be a unique queue or many queues.


(Jean Cavallo) #6

I think this is better than a direct user-queue Many2Many, at least for large organizations where tens of people may have the exact same configuration. I also agree that it is better to have a separate entity to store a group of queue. In that case, shouldn’t the priority set per queue / per group ? i.e. a given queue could have different priorities depending on the group they are in.

The use case would be two “teams” with the same qualifications, but different priorities. For instance, they both are able to manage invoices and payments, but one will prioritize invoices while the other will first work on payments.


(Cédric Krier) #7

Per queue. I forgot to change it in the blueprint.


(Cédric Krier) #8

A common need, I think, is when the employee leaves for vacation or permanently the company.
We need to reassign all his assigned documents. I think the simplest way is to loop over all the queues and search for records assigned to the employee. Then remove it from the assignation field.
I do not think we should allow to assign to someone else for two reasons. We will ask for each queue which employee to assign to ensure access rights are correct. We will overload the replacement employee.
But de-assign the employee will put back the documents in the queues and they will be redistributed evenly to all staying employees.