Comment 6 for bug 1070884

Hello,

I have to agree with Daniel here, because this behavior is indeed by design, pretty much for the use cases he mentioned.
It is common for rules to restrict write or read access based on the ownership of a record, for example the "Sales - See own leads only" group prevents seeing leads that are not assigned to you.
Even if you can't see your colleagues' leads, you should be able to transfer one of your leads to your colleagues - and the system should allow that.

So yes, there are use cases where this is important, and we should not change this is stable versions.

Now it is true that administrators might want to have more control over this gray area in the future. We have discussed this many times internally, and we always came to the conclusion that adding more permission types (such as perm_pre_write/perm_post_write) would needlessly complexify the already complicated OpenERP ACLs.
An idea that came up was to automatically decide whether an access rules check is necessary at the end of a write() operation based on the other operations that the relevant access rules apply to.
As you said, it is not quite consistent that a rule will prevent you to create a certain record, but will allow you to modify it to reach the same state. Hence we could say that a `write-restricting` rule would be checked *also* at the end of the write() operation if and only if it applies to `create` as well.
Or to `read`, I'm not sure. Indeed it's also surprising that sometimes you cannot read what you can create, but it might still make sense for a certain kind of automated operations: in 7.0 a contact form system in the portal will allow anonymous users to post contact requests (i.e. leads), but they must not be allowed to read any request over RPC, even the ones they've just created (it's like a black box).

So probably having a post-write check for rules that also restrict 'write' is the most logical behavior.
What do you think?

Thanks for raising attention to this gray area of the OpenERP security model!

PS: I'll set the bug to Confirmed/Low, think we can still target it to 7.0. I don't think we can allow this behavior to change in 6.1.
PPS: Please don't set unconfirmed bugs to Fix Committed - even though it looks like the most appropriate status when a merge proposal is awaiting review, it might confuse others into thinking the bug is confirmed and the solution was decided upon.