Could not set "_order=name" for object which inherits from product
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Server (MOVED TO GITHUB) |
Confirmed
|
Wishlist
|
OpenERP's Framework R&D |
Bug Description
This bug is another improvement of comment 10 from bug: https:/
Steps to reproduce:
+ In object "hotel.room" of module "hotel", set "_order = 'name'" to order Room list by name
+ View list of Rooms, then below error occurred
Traceback (most recent call last):
File "/home/
result = ExportService.
File "/home/
res = fn(db, uid, *params)
File "/home/
return f(self, dbname, *args, **kwargs)
File "/home/
res = self.execute_cr(cr, uid, obj, method, *args, **kw)
File "/home/
return getattr(object, method)(cr, uid, *args, **kw)
File "/home/
return self._search(cr, user, args, offset=offset, limit=limit, order=order, context=context, count=count)
File "/home/
cr.
File "/home/
return f(self, *args, **kwargs)
File "/home/
res = self._obj.
ProgrammingError: column "name" does not exist
LINE 1: SELECT "hotel_room".id FROM "hotel_room" ORDER BY name limi...
Hello,
Currently, _order supports any complex syntax that PostgreSQL supports. It can be completely arbitrary, including multiple columns, database functions, etc. As a result, we can't easily extract column names from it, and find out if we need to JOIN the parent table for _order on inherited fields to work. And always adding the JOIN(s) might introduce performance penalties but could also lead to issues in case of ambiguity between column names in the parent and child tables.
So what you describe in the bug report is simply not meant to be possible at the moment, it's a technical limitation.
If you look at the product.product class, you will see that _order refers to local product.product columns, including a stored related field containing the name of the template. This is a possible workaround for your use case: add any necessary related+stored field you need, in order to be able to define the _order based exclusively on 'local' columns.
We will keep this bug report as wishlist, as there are a few options we can investigate in order to enable this in the future, but this is not in the scope of the framework for now.
By the way, having multiple levels of _inherits is not often a good design choice (but that's a different topic)
Thanks for suggesting this improvement!