On 07/11/2011 12:14 PM, Leonardo Pistone - Agile BG - Domsense wrote:
>> So if you make sure that the rules of your database only permit
>> seeing the sequences of the current user company,
>
> i.e. i'd be very happy to set up a rule on ir.sequence for my needs.
>
> The problem is that in that the l.9 of the diff says
>
> company_ids = self.pool.get('res.company').search(cr, uid, [],
> context=context)
>
> that uses the record rules of the company object, not the ir.sequence
> object. I think that is wrong.
Oops, I apologize to Ila and Leonardo, I meant to say that it should
work if you setup a rule on *res.company* that only allows the user to
see her own current company! In that case line 9 will only select the
current user company.
And this rule on res.company does not prevent switching to a different
company (if you have several company_ids), as the user preferences
specifically allow you to see all your company_ids.
This certainly seems consistent with your database rules: it explicitly
prevents the user from selecting an incompatible company on any document
-> the company selection field will only ever show one.
> My proposal is to forget all SQL here and just do a simple
> self.pool.get('ir.sequence').search
>
> That would follow rules for ir.sequence, and everyone would be able
> to set them up according to their needs.
I agree that it would be simpler and more intuitive.
The reason for the SQL here is the "FOR UPDATE NOWAIT" clause, that
implements the proper serialization of sequence increments, and is
definitely required.
But perhaps we could still improve this with the following:
- add an ir.rule on ir.sequence (like all defaults, filters on current
and child companies)
- use ir.sequence.search() to find the visible sequences for the current
user (limit=1) + read/browse to get the sequence data
- then do a "SELECT FOR UPDATE NOWAIT" on the selected sequence, to
implement the proper locking mechanism
- and finally do the update of the sequence (could be done with write())
This would make it more intuitive during the configuration of
multicompany setups, but it will require an update of 'base' during
upgrade, to make sure the rule on ir.sequence is created.
Jay, Ila, what do you think of this proposal? Is it perhaps too much for
stable, and should go in trunk only?
Leonardo, even if we perform this change, you should still have an
appropriate rule for res.company, to make the security policy
consistent. So regardless of what we do, if you have consistent rules on
both res.company and ir.sequence, you'll be safe.
Does it sound right (this time ;-))?
--
https://code.launchpad.net/~openerp-dev/openobject-server/6.0-opw-10420-ira/+merge/66546
Your team OpenERP R&D Team is subscribed to branch
lp:~openerp-dev/openobject-server/6.0-opw-10420-ira.
_______________________________________________
Mailing list: https://launchpad.net/~openerp-dev-gtk
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-dev-gtk
More help : https://help.launchpad.net/ListHelp
