Question

I need to set up different permission on an object based on its workflow state. For instance, ‘manager group’ can edit the object only if state=draft but ‘super manager group’ can edit it also if state=validated.

It seems that’s not possible using ir.model.access and I’m evaluating if it could be done using ir.rule. It seems not…

Is there a official way to get this or do I need to implement this feature (maybe by adding a condition into ir.model.access machinery).

Answer 1

This is not possible by default with ir.model.access, because this permission model is designed to act like simple Unix permission on CRUD operations, and it is statically defined, per-model and per-group.

You may be able to implement something like this using ir.rule, as it implements dynamic per-record access control based on field values. By having a set of rules defined only on the write and unlink operations and based on the state field, you will be able to prevent some groups from modifying records in certain states. By using the technique of an always-true rule [(1,'=',1)] you can then relax a non-global rule for users who have a “super-access” group. See also this answer.
This option will have important caveats however:

• Be careful not to make those rules apply for read, as it will make the records completely disappear, and generally wreak havoc in your processes
• The interface will not become read-only when the rule is in effect, and if you want to make the fields and buttons read-only you will have to find a way to specify this via attrs in a manner that depends on the user’s groups. See also this Launchpad question.
• the Save button in the UI will not be disabled
• The standard error reporting in case of ir.rule restriction is not very clear, so it will certainly confuse users (note: it’s being improved for 7.0)

As you see, using ir.rule filters for this purpose is far from a perfect solution, and you will first need to find appropriate solutions for the above issues.

Ultimately, you might have an easier task of implementing your own logic for this, plugging a new mechanism in the ORM primitive API methods: fields_view_get (for making fields dynamically read-only based on the user groups) and the CRUD methods (for actually restricting the operations)