Required clicks per Button

Rational

Some buttons are approbations and in some cases we need to have clicks of multiple users. Such multiple clicks can require click from a specific group or click from a number of user. Also they can depend on the record approved (ex: amount of the purchase). And this is configuration specific to the company rules so it must be configurable from the interface.

Proposal

We could extend the ir.model.button to contain a list of rules. Each rule is a constraint that must be passed.
We extend the ModelView.button decorator to record who has clicked on the button and to check all approbation rules. The decorator will filter out all records that does not pass the rules from the super call.
The rule will be composed of a group, a number (of user) and a condition (PYSON). It will also have a list of buttons that will clear the “click” if clicked.
The “click” will just record the user.

Implementation

https://bugs.tryton.org/issue5944
https://codereview.tryton.org/26791002

Future

  • Add “clicked by me” Function field to use as filter

I’m not sure about the name ‘Approbation’ but I could not find a better one?

“Approval” ? “Acceptation” ? “Authorization” ? “Allowance” ?

Indeed I think I will just use the names: Rule and Click

I like this names as then they can be used as “Approval”, “Reject” or whatever option that requires a click of several Users.

I have a working implementation at
https://bugs.tryton.org/issue5944
https://codereview.tryton.org/26791002

But I feel it is missing something on the UI because the user click on the button and nothing happens. He doe not have feedback about his action.
My proposal is to show a counter of clicks on buttons that have rules and a tool-tip which shows the user names who clicked.
This will require to set automatically new attribute on the XML definition of the button and create an RPC method that compute the values.

I think there will be a problem for example if the “confirm” button of the sale is configured with a rule and one user click on “confirm”. But before a second one also click, the sale is reset to draft and changed. Once the sale is back to “quotation”, the older clicks are still counted.

A possible solution will be to remove (or inactivate for history) the clicks of all record button once another button (or a defined list of buttons) of the same record is clicked.
Or each document must take care of their clicks themselves but this solution is less customizable.

That’s a great feature!!

IMHO by default any change of state or click in another button should remove the clicks of our button and could be customized with a list of buttons as you propose.
Another point is user notification. +1 for tooltip and counter for current user, but I think another users that clicked the button should be notified as well (when another user click or when their clicks are removed). This can be achieved with the “new” notes functionality.

The counter and tooltip is visible to all users.

Using note will be a wrong usage of it. Note should be filled by users for users, not by the system. Indeed notification about modification should be managed by the email notification

That’s correct. But I was referring to notify other affected users at the moment in a reactive way.

Email notification would be a great option as well.

What about permissions about change workflow state when one button was clicked but needs more clicks? In your examples of sales if an user clicked Confirm but two clicks are required, did any user (with correct permissions) can go back to previous state?

For direct notification, I have an idea which is out of the scope of this feature. I will write another blueprint.

Yes he can because he has the right. If for some reason company has a work-flow that prevent such behaviour, it should be added by customizing the workflow method or create a new workflow state. But I do not think it is a common use case because if we want multiple validation it is because we want to allow to cancel the validation.

We recently created an “approval” module [1] (not finished) but it basically aims to cover the same requirement as this feature proposal.

The main difference (apart from the fact that you hack the button system) is that we expect a “sale_approval” (or purchase_approval) module, for example, that explicitly creates the “approval” records.

Some features we aimed to cover are:

  • By creating the approval requiests explicitly it is very easy to have a “pending approvals” section for each user.
  • Expects the user to explain why an item is rejected.
  • Moving the sale to draft state, will set all the approval records to “Cancelled” state, so it keeps the history of what has happened.
  • We keep track of when the request for approval was created and when has been approved (the company wants to know if something was purchased/sold too late) and whose fault it was.
  • It is explicit who has to approve a document. Having the record of pending approvals it is more obvious what is missing for the document to be approved and who to press for their approval.

[1] https://bitbucket.org/nantic/trytond-approval

I think the rule must to have a “Description” required field and the button contain a badge * per rule that shows the number of clicks that match this rule (user group), a color or icon that shows if the rule is accomplished (with an alternative text for blind people that says if its approved or not) and a tooltip that shows the rule description to explain the user what are these badges and how to get the document approved (or reach the next state).

Indeed it is still easy with the current design. As what you called “approvals” are button clicks.

As rejection will be based on clicking on other button, you still can put a comment wizard on the cancel/reject button.

I think it is a wrong design. It should not be “who has to” but “who is allowed to”. So approbation should follow our current button design using groups.

Added but not required like the record rule.

Indeed I think rejection explanation is not linked to this feature at all. It should be something build in the document because rejection can even occurs when there is no multiple validation.

In fact, I think this feature will create a new need to improve existing domains of documents. Common multi-validated document will require to have a Function Boolean field with searcher which will be True if the user has clicked.

I think this would be solved by your Function Boolean fields but just in case:

What we do is to have an explicit Group of users that have to approve it (not an explicit user). But in case there are several groups who must do it, you end up having two approvals.

Note that in some cases the company needs something like this: Users of group “X” must approve, if they do and the amount is > 10.000€ then (and only after the it has been approved) somebody at group “Managers
of X” has to approve too. And in that case, if amount > 100.000, then “Managers of Managers of X” must approve too.

So “Managers of Managers of X” should have a list of documents to approve.

It seems to me that with the proposed design it will not be easy to create such list. Isn’t it?

I think the main difference is that in your proposal you check the rules in “real time” while what we do is check the rules (we don’t have rules, but you get the idea) and then create the approval requests on the group of users that have to validate them.

The order is pointless. So it is just a matter of showing the records that a user must click on.

I don’t think the order is pointless. Most of the time, only if the “lower” level manager has approved a purchase will you want to raise it to an upper level.

The upper level does not want to be annoyed if the lower level are still deciding if they really need that purchase.

Such archaic company will have the resources to customize the domain.