CODEWITHSUNDEEP
permissionsworkflowodoo
simahawk
simahawk

Reputation: 2431

different permissions based on workflow state

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).

Upvotes: 4

Views: 2521

Answers (4)

OmaL
OmaL

Reputation: 5044

I got a similar requirement... My requirement was to make a char field(say "test_123") readonly in the sale.order if the user comes under the group "sale user" otherwise editable for the group "Sale Manager". That is, if the sale order is in draft state then anyone can edit, but it the sale order is confirmed then this field "test_123" is only editable for "Sale Manger"

What I did is I added a functional field (is_group_manager) which returns True if the user comes under the group "sale manager" and the state is not "draft" otherwise false. Then in the xml view I added the field "test_123" with attribute attrs="{'readonly':[('is_group_manager','=',0)]}" for example 

<field name="is_group_manager" invisible="1"/>
<field name="test_123" attrs="{'readonly':[('is_group_manager','=',0)]}"/>

This will work only in openerp v6.0. Maybe this will be helpful for you. :)

Upvotes: 0

Daniel Reis
Daniel Reis

Reputation: 13342

I have this feature working on a production environment, using just Record Rules: in Project Issues, "basic users" can create and cancel issues, but can't open or close them. Despite the GUI limitations mentioned by @odony, it works perfectly.

These are the Record Rules used:enter image description here:

There is a special case that needs attention: changing from a read-write State to a read-only State:

In the action's method, if the the State is changed after other write operations, the user will be able to change the State; but if there are some write operations after the State update, the user will not be able to change State.

In my example, the Project Issue method to Open an issue is case_open(). It first changes State and then does additional changes, like settting Open Date, User and Message history. Because of this, basic users can't Open issues. If you want them to be able to do so, case_open() must be overridden so that it changes State after all other write operations are done.

Upvotes: 0

odony
odony

Reputation: 4117

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)

Upvotes: 5

Ruchir Shukla
Ruchir Shukla

Reputation: 805

There is another way instead of hacking web-client. You can always have 2 views for the same Object .

  1. For manager group.

  2. For super manager group.

In manager group you can use attrs = {'readonly': [('state', '!=', 'draft')]}

or any condition as you needed.

And in the same way in super manager group, you can put his condition for fields.

Upvotes: 1

Related Questions