account - level - wrong computation
Bug #783670 reported by
Ferdinand
This bug affects 3 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Addons (MOVED TO GITHUB) |
Fix Released
|
Low
|
OpenERP R&D Addons Team 3 |
Bug Description
account/account.py
def _get_level
currently the calculated level (except level 1) is very much random, depending on the sequence of processed records
2 issues:
1) IMHO the function makes the wrong assumption that the level of the parent account is already calculated, which is not necessarily the case
2) the level (stored=True) of all childs must be recalculated if the level of a parent changes. IMHO this would also solve issue 1).
change of structure may be done any time manually.
Related branches
lp:~openerp-dev/openobject-addons/trunk-bug-783670-mtr
- Meera Trambadia (OpenERP) (community): Needs Resubmitting
- qdp (OpenERP): Needs Fixing
- Raphael Collet (OpenERP) (community): Needs Fixing
- Fabien (Open ERP): Disapprove
- Mustufa Rangwala (Open ERP) (community): Approve
-
Diff: 49 lines (+11/-7)1 file modifiedaccount/account.py (+11/-7)
Changed in openobject-addons: | |
assignee: | nobody → OpenERP R&D Addons Team 3 (openerp-dev-addons3) |
importance: | Undecided → Low |
status: | New → Confirmed |
Changed in openobject-addons: | |
status: | Confirmed → In Progress |
Changed in openobject-addons: | |
status: | In Progress → Fix Committed |
Changed in openobject-addons: | |
milestone: | none → 6.1 |
tags: | added: maintenance |
To post a comment you must log in.
Note:
1) I don't think the code makes any assumption that the parent's level is already calculated, because it recursively calls the function field, which should be computed on-demand, as far as I can see. However the process of doing this is a bit inefficient. I think the computed values should be correct, provided the tree hierarchy is correct and did not change, because of 2). parent_ left), which will return pairs of (id, parent_id) for all possible ancestors of the current account, and then post-process these in python by putting the pairs in a map and walking up from the node's parent.
It is not easy to implement this in an efficient way (in terms of DB queries). A possible approach might be to use cr.execute('SELECT id, parent_id WHERE parent_left < %s', account.
2) That's quite correct indeed, the values should be recomputed when the hierarchy changes, e.g. via a different "store=..." trigger.