access rules are ignored by create()

[Maximilian Gaß]

Access rules are checked by all other ORM functions, but not by create(). I understand this might be more hairy, because the domain is currently just usable for SQL WHERE conditions and create() needs to check the row *before* inserting it, but this loophole should be closed nevertheless.

[Numérigraphe (numerigraphe)]

Just a thought: maybe it could be worked around by first inserting the row, then testing if the row respects the access rules with a select/where, and throwing an exception if it doesn't?
Lionel

[Maximilian Gaß (mxey)]

On Mon, Mar 15, 2010 at 12:48:28PM -0000, Numérigraphe wrote:
> Just a thought: maybe it could be worked around by first inserting the row, then testing if the row respects the access rules with a select/where, and throwing an exception if it doesn't?

if that leads to the transaction being rolled back, it is a good workaround,
yes. It will make sure the entry does not stay in the database.

[xrg (xrg)]

On Monday 15 March 2010, you wrote:
> On Mon, Mar 15, 2010 at 12:48:28PM -0000, Numérigraphe wrote:
> > Just a thought: maybe it could be worked around by first inserting the
> > row, then testing if the row respects the access rules with a
> > select/where, and throwing an exception if it doesn't?
>
> if that leads to the transaction being rolled back, it is a good
> workaround, yes. It will make sure the entry does not stay in the
> database.
>
What about sequences then? If the entry had needed a number from them, do we
make sure we reset the sequence?

I'm also sure there is an SQL way to pre-check non-existent rows against a
WHERE clause.

[Numérigraphe (numerigraphe)]

>What about sequences then?
In simple cases like sale orders, I think the sequence is allowed to have gaps in the current implementation anyway. That's normal and doing otherwise is overkill IMHO. For cases like invoices the sequence is not used at creation time.

>I'm also sure there is an SQL way to pre-check non-existent rows against a WHERE clause
Some DBMS support constructs like
 "SELECT ... FROM VALUES (...) WHERE...",
or "HAVING (VALUES (...) AS temp_view) SELECT ... FROM temp_view WHERE ...".
Maybe PostgreSQL supports one of those?
Lionel

[Borja López Soilán (NeoPolus) (borjals)]

xrg, currently (there was a big and nasty bug before 5.0.7), the sequence number generation is done on the same transaction as the workflow activities, so if the transaction is rolled back, so it is the sequence number.
Also, the sequence number generation uses a SELECT FOR UPDATE that will lock any attempt to get another sequence number, for the same type of object, until this transaction gets commited or rolled back. That means that you won't get gaps in the sequence if you rollback a transaction (you still can get gaps if you delete objects).

[Anup(SerpentCS) (anup-serpent)]

Hello Maximilian Gass,

I would like to know the exact situation where I can face the situation.
I have gone through few ways, but I could not meet to the error.

Would you please exemplify the steps.

Thanks.

[Maximilian Gaß (mxey)]

Anup, I created an access rule that prevents users from creating timesheet entries/analytic lines for other users by ensuring that the user_id field has the same value as the current uid.

Using the RPC interface to OpenERP, it is still possible to create rows for another user though. Viewing, editing and deleting of foreign rows is not possible.

[Anup(SerpentCS) (anup-serpent)]

Hello Maximilian Gass,

  I created an access rule for hr_timesheet_sheet.sheet which will not allow the user to create,write or delete the timesheet. I tested it by trying to create a timesheet from the view, python code of the events and also using the xmlrpclib but it is not possible to create a timesheet as the user has no rights to do so. It gives the access error.

I think you have created a record rule. Record rules are only used for not allowing the users from viewing a particular records using some domain.

Can you tell me how you have created the access rule? How it specifically allows other users to create a timesheet.?

Thanks.

[Maximilian Gaß (mxey)]

Anup, yes, I meant record rules. Sorry for the confusion.

I know that record rules currently do not cover creating new records, that is why I opened this bug. I think they should. Otherwise there is no option to prevent users from creating timesheet entries for other users without adding/changing the code.

[Jay Vora (Serpent Consulting Services) (jayvora)]

If the user is trying to go beyond the rules, there is a message being thrown that user is bypassing an access rule.
Kindly check again.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Kindly specify proper Information how you get any error, so we can plan to develop in next version.
Thanks.

[Maximilian Gaß (mxey)]

I think I was pretty clear. Record rules apply to reading/searching, changing and deleting - why not to creating records?

[Anup(SerpentCS) (anup-serpent)]

Hello Maximillian,

  Yes. using record rules we can block a user from creating a record. I have tested it and it works as required. I created a timesheet with a user logged in and having another user in the timesheet but was unable to do so as the record rules blocked me from doing that. I even tried the same with xmlrpc but was still unable to create a record.
Would you explain the steps how actually you got the error? how you created a record rule on which object. And how you are trying to create a record?

Thanks.