[6.0RC2] orm groupby doesn't add tablenames to fields and groupby clause
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Server (MOVED TO GITHUB) |
Fix Released
|
Low
|
OpenERP's Framework R&D |
Bug Description
orm.py, class orm function readgroup line 2167
There are no tablenames added to the fieldname, leading to the following error when grouping projects by parent
1. Create some analytic accounts with parent/childs
2. Create some projects with parent/childs
3. Try a grouped view by parent.
Environment Information :
System : Linux-2.
OS Name : posix
Distributor ID: Ubuntu
Description: Ubuntu 10.04.1 LTS
Release: 10.04
Codename: lucid
Operating System Release : 2.6.35-22-generic
Operating System Version : #34~lucid1-Ubuntu SMP Mon Oct 11 14:36:18 UTC 2010
Operating System Architecture : 32bit
Operating System Locale : nl_BE.UTF8
Python Version : 2.6.5
OpenERP-Client Version : 6.0.0-rc2
Last revision No. & ID :0 null:
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/
cr.
File "/home/
return f(self, *args, **kwargs)
File "/home/
res = self._obj.
ProgrammingError: column reference "parent_id" is ambiguous
LINE 1: ... id, count(project_
Solution my be to force the tablename to be joined to the fieldname.
Regards,
Ruben
On Saturday 15 January 2011, you wrote: project. id) AS parent_ id_count, parent_ id,...
> Public bug reported:
>
> orm.py, class orm function readgroup line 2167
>
> There are no tablenames added to the fieldname, leading to the following
> error when grouping projects by parent
> ProgrammingError: column reference "parent_id" is ambiguous
> LINE 1: ... id, count(project_
> ^
You are right that the 'group_by' feature should indicate table names.
However, note that project.parent_id has been removed a few commits ago, so analytic. account'
that model won't have a column conflict with its 'account.
base model.