[wishlist] _order and _parent_order should support sorting using inherited fields and many2one fields and translatable fields
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Odoo Server (MOVED TO GITHUB) |
Fix Released
|
Low
|
OpenERP's Framework R&D | ||
Bug Description
If object (e.g. sale.order) is sorted by many2one (e.g. _order = 'user_id'), sorting is done by value of sale order table (user_id, integer) excluding many2one field value (e.g. user name).
From the technical side I see that orm.py _generate_order_by method is not fully used when _search is done.
One of fix is to set self.order for the _search function if it's order parameter is None.
To reproduce bug:
1. set _order = 'user_id' for the sale_order
2. create user with name 'C'
3. create user with name 'A'
4. create user with name 'B'
5. Create sale orders and assign each user to sale order
6. Open sale_order list
Result observed:
Sale orders order are: C, A, B
Result expected:
Sale orders order are: A, B, C
I've attached screenshot. Used trunk rev: 4504
Related branches
- OpenERP R&D Team: Pending requested
-
Diff: 11 lines (+1/-0)1 file modifiedopenerp/osv/orm.py (+1/-0)
- Olivier Dony (Odoo): Needs Information (functional)
-
Diff: 11 lines (+1/-0)1 file modifiedopenerp/osv/orm.py (+1/-0)
| Olivier Dony (Odoo) (odo-openerp) wrote | #1 |
| Changed in openobject-server: | |
| assignee: | nobody → OpenERP's Framework R&D (openerp-dev-framework) |
| importance: | Undecided → Low |
| status: | New → Confirmed |
| summary: |
- [6.0, 6.1, trunk] Sorting object by many2one field fail + [wishlist] _order should support sorting using inherited fields and + many2one fields |
| summary: |
[wishlist] _order should support sorting using inherited fields and - many2one fields + many2one fields and translatable fields |
| summary: |
- [wishlist] _order should support sorting using inherited fields and - many2one fields and translatable fields + [wishlist] _order and _parent_order should support sorting using + inherited fields and many2one fields and translatable fields |
| Ferdinand (office-chricar) wrote | #2 |
| Thibault Delavallée (OpenERP) (tde-openerp) wrote | #3 |
| Changed in openobject-server: | |
| status: | Confirmed → Fix Released |
| Cristian Salamea (ovnicraft) wrote | #4 |
| Changed in openobject-server: | |
| milestone: | none → 7.0 |
| Olivier Dony (Odoo) (odo-openerp) wrote | #5 |
| Cristian Salamea (ovnicraft) wrote | #6 |
Hello Paulius,
I agree that this behavior may be surprising and may constitute an annoying limitation, but it was designed that way: the _order attribute of OpenERP models is meant to be directly passed in the SQL query without any extra processing, whereas the `order` parameter passed to search() is post-processed to handle many2one and inherited columns.
The _order attribute is low-level, while the search order parameter is high level.
This allows to use arbitrarily complex ordering clauses in _order, combining any PostgreSQL operators like lower() substring(), coalesce(), etc. These arbitrary expressions would be very hard to parse in order to support many2one columns or inherited columns. It would also be quite strange, because we would be mixing low-level SQL operators with high-level OpenERP column definitions.
As a result, this is dangerous to change, and needs to support the complex cases properly.
I will confirm your bug for trunk, as a nice-to-have feature (priority Low), but this will not be changed in past stable versions, as it breaks all the rules of our stable policy [1].
We can discuss this further on the merge proposal...
Thanks for reporting,
[1] http://
[2] BTW the merge proposal is not linked to the bug, perhaps you forgot to use --fixes when for your commit. See also our documentation about merge proposals: http://