Infinite warning loop
The unique key of user warnings is often composed of the record representation and some fixed string. If a record was created during the transaction and raises a user warning, it leads to an infinite loop of warnings. This happens because once the warning is acknowledged the request is reexecuted and the newly created record gets a new id this time (at least with postgresql, see comment below).
This happens for example with the no_origin warning of stock.move. If the quantity in moves and outgoing moves in a shipment is not balanced, the _sync_inventory_to_outgoing() method creates a new move to compensate for this difference. But this new move has no origin and therefore raises the no_origin warning. If the warning is acknowledged, the request is reprocessed but the newly generated move gets a new id this time and the warning is reraised.
This bug only occurs with the postgresql backend, sqlite works fine. The difference is, that with sqlite the assigned id in both requests is the same, but postgresql assigns a new id every time.
I'm not sure about the best way to fix this issue, so I'm leaving it unassigned. But if there is an agreement about the source of the problem, I'm willing to provide a patch.
Files
Download | Creator | Timestamp | Type |
---|---|---|---|
unnamed | @guillemNaN | 2014-10-20 11:28:00.727000 UTC | text/plain |
unnamed | @guillemNaN | 2014-10-20 12:26:45.581000 UTC | text/plain |
unnamed | @guillemNaN | 2014-10-20 13:30:10.986000 UTC | text/plain |
unnamed | @guillemNaN | 2014-10-20 13:55:43.591000 UTC | text/plain |
unnamed | @guillemNaN | 2014-10-20 14:23:52.413000 UTC | text/plain |
unnamed | @guillemNaN | 2014-10-20 16:56:27.839000 UTC | text/plain |