[table].id IN (false) HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.

[Holger Brunn (Therp)]

When getting many2one fields via the value= parameter which *name* is False, the error above is thrown.

This is caused by the fact that bool is an instance of int and http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/osv/fields.py#L465 filters out [x for x in res.values() if isinstance(x, (int,long))]

This applies to 6.1, 7.0, trunk, MPs follow

[Ronald Portier (Therp) (rportier1962)]

Horror:

bool(False - 1) == True

[Olivier Dony (Odoo) (odo-openerp)]

Looks correct, thanks for the analysis and for the patch!

[Olivier Dony (Odoo) (odo-openerp)]

Note: please don't make identical merge proposals for trunk and the last stable unless trunk really needs a different kind of patch. The last stable branch can always be assumed to be periodically merged into trunk, and having both increases the administrative burden and the chance of creating conflicts.

Similarly, I'm not sure you should be making merge proposals for your various backport branches immediately after making them for the official branches: that sounds like increased noise, more administrative work, more chances of conflicts... perhaps only do that when you think the official MPs have been pending for too long? (not sure what makes the most sense, you decide)

[Gustavo Adrian Marino (gamarino)]

The problem arises because the function receives 3 types of res
dictionaries:
- values with None/False
- simple ints
- tuples (id, name)
The attached patch handles the three cases correctly

2013/2/13 Olivier Dony (OpenERP) <email address hidden>

> Looks correct, thanks for the analysis and for the patch!
>
> ** Changed in: openobject-server
> Importance: Undecided => Medium
>
> ** Changed in: openobject-server
> Status: New => Confirmed
>
> ** Changed in: openobject-server
> Assignee: (unassigned) => OpenERP's Framework R&D
> (openerp-dev-framework)
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Server.
> https://bugs.launchpad.net/bugs/1124130
>
> Title:
> [table].id IN (false) HINT: No operator matches the given name and
> argument type(s). You might need to add explicit type casts.
>
> Status in OpenERP Server:
> Confirmed
>
> Bug description:
> When getting many2one fields via the value= parameter which *name* is
> False, the error above is thrown.
>
> This is caused by the fact that bool is an instance of int and
> http://bazaar.launchpad.net/~openerp/openobject-
> server/trunk/view/head:/openerp/osv/fields.py#L465 filters out [x for
> x in res.values() if isinstance(x, (int,long))]
>
> This applies to 6.1, 7.0, trunk, MPs follow
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-server/+bug/1124130/+subscriptions
>

--

Gustavo Adrian Marino

Mobile: [phone]

Email: <email address hidden>

Skype: gustavo.adrian.marino

[Stefan Rijnhart (Opener) (stefan-opener)]

@olivier Are you kidding? I do not think that any of our fixes were ever applied to stable. We don't expect you to do so anymore. The OpenERP SA bug fixing policy also expresses that only high/critical issues will be taken into account. So when we say 'backport', it usually means 'apply to stable'. That warrants immediate backport branches of contributed fixes.

[Olivier Dony (Odoo) (odo-openerp)]

@Stefan: well I certainly don't blame you for doing the extra effort and I understand why you do it. It's just that I was planning to merge the fixes in the various stable branches and thought you were going to do the work twice or risked getting unnecessary conflicts.
BTW what we mean in the policy is that we will only backport patches ourselves for High+ issues. That does not preclude accepting MPs for past stable versions, especially if the issue is sufficiently serious (nothing that looks remotely like a wishlist) and if we receive a ready-to-merge MP from the community. No guarantees, but that means your MPs for 6.1 & 7.0 are useful :-) I'll adapt the wording on the bug management policy to make that more explicit.

[Stefan Rijnhart (Opener) (stefan-opener)]

That would be the best, thanks! Of course, if it turns out that backporting current fixes immediately is double work on which the official branches catch up quickly we will adapt the process. Conflicts should not occur because the change is represented by the same bzr revision id in all branches (using the clone script), although bzr seems to be pretty robust against identical code changes merged multiple times in distinct revisions too. Just don't add any extra spaces while merging ;-)