[6.0] Inheriting _constraints "list index out of range" if original len(_constraint ) is bigger than the new one
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Server (MOVED TO GITHUB) |
Opinion
|
Undecided
|
Unassigned |
Bug Description
branch: 6.0
addons : 4677
server: 3452
My module example:
class stock_move_
_inherit = 'stock.move'
_columns = {}
def _check_
print "I checked"
return True
_constraints = [
stock_move_
When I try to update my module ($python openerp-server.py -u mymodule -d mydb) this traceback is received.
Traceback (most recent call last):
File "./openerp-
db,pool = pooler.
File "/home/
addons.
File "/home/
processed_
File "/home/
modules = pool.instanciat
File "/home/
res.
File "/home/
if new[c2][2]==c[2] and (new[c2][0] == c[0] \
IndexError: list index out of range
I printed variables of this method (check patch it is corrected) and some kind of bad logic is used, the server is trying to check as a list an integer....
Original problem
~~~~LINE 348 on osv.py
####THIS IS MY PRINT it is an integer,,,,,
#on the range(len(new)) always will return an index in c2 of the original class never, and if the original
#_constraint list in class is bigger than the new one it will broke.
Changed in openobject-server: | |
assignee: | OpenERP Publisher's Warranty Team (openerp-opw) → nobody |
importance: | High → Undecided |
milestone: | 6.0.3 → none |
status: | Confirmed → New |
tags: | added: maintenance |
Changed in openobject-server: | |
status: | Incomplete → Confirmed |
importance: | Undecided → Medium |
assignee: | nobody → OpenERP Publisher's Warranty Team (openerp-opw) |
Changed in openobject-server: | |
status: | Confirmed → In Progress |
Changed in openobject-server: | |
status: | In Progress → Invalid |
Changed in openobject-server: | |
assignee: | OpenERP Publisher's Warranty Team (openerp-opw) → OpenERP's Framework R&D (openerp-dev-framework) |
tags: | removed: maintenance |
Hello Nhomar,
I have checked similar issue with latest stable and trunk code but did not face any traceback while updating the exiting db.
Would you please provide me more steps to reproduce the same traceback at my end.
Thanks.