Field definition translate=Yes is not stored in ir.model.fields

(tested on 6.0.2 and up-to-date lp/6.0)

Hi!

For a customization, we need to find out in python code if a field is
set to be translatable.

https://bugs.launchpad.net/openobject-server/+bug/780584

The field translate exists in the database, but it's not used, NULL in
all databases on all fields here.

Reading ir.model.fields over OpenObject doesn't work either, compare
http://www.openerp.com/forum/topic24970.html
<http://www.openerp.com/forum/topic24970.html>.

I compared two dumps: dumped database (with pg_dump), changed one field
to translate=True, -u modulename, dumped again:
diff shows no indication of translate= being stored anywhere in the
database. Same effect on removal of translate=True.

In ir_model.py, create and write are customized, handling model_props
like translate somehow, but I can't figure out where translate is
stopped from going into the database properly.
As read is not customized, though, I think this might be the problem.
(Actually, I think write/create is the problem, was the field in the
database can easily be set)

This effects occurs at least in 6.0.2+ (regularly updated from
launchpad), I haven't tried it on trunk.

I asked about this in IRC on May 10th, and xrg prepared a short fix to
this problem:
http://git.hellug.gr/?p=xrg/openobject-server;a=commit;h=d7a8fa5352e995d526c

see diff:
http://git.hellug.gr/?p=xrg/openobject-server;a=blobdiff;f=bin/osv/orm.py;h=7a750710b3d31599ce2838cf2bd91d40b9ac50f9;hp=0a2300d6bb99ffad7e91596923dcacb96e277c40;hb=d7a8fa5352e995d526c;hpb=9c5a74926ff9d46e231a07e31f657a151aeba873

The comment added by Stephane above is a OPW request that was declined as feature request, not a bug.

I still think it is a bug, as the field translate is present in ir.model.fields, with a help text that indicates it's uses.
'translate': fields.boolean('Translate', help="Whether values for this field can be translated (enables the translation mechanism for that field)"),

There is also a checkbox on the Administration - Customization - Database Structure - Fields form.

But they don't work at all - the field is simply not filled when orm.py initializes the models.
In my book, that's a bug.

Therefore I propose the fix as developed by xrg in the link in the post above as merge request.

With the reference of Last comment I am assigning this to OPW team.

Thanks.

Yes, in fact, it's a real bug.

This branch will be merged in stable.

Regards,

Stéphane

Hi,

For the record, this can be considered as a bug but a very small one :)

Actually, the 'translate' column in ir_model_fields doesn't exist right at the start of the ORM; i.e. it is not created by base.sql. This means that the proposed fix is not enough, the column should be added in base.sql.

Now, the bug materializes itself only when doing a 'read' on ir_model_fields for a python field: we will always read that a python field is not translatable. For a custom field, the value will be correct.

But in the GUI, the flag next to a field to show if it is translatable is always correct: it is still possible for a non-custom field to see if it is translatable by inspecting the _columns attribute of the model.

We will probably add the translatate field in base.sql so the information is correct even for python fields though.

A fix is available at lp:~openerp-dev/openobject-server/trunk-bug-780584-store-translate-vmt and will be merged in trunk soon.

The fix is merged in trunk at revision 3430 (revision-id: <email address hidden>).

Thanks VMT and OLT,
It has been fixed over stable 6.0 by revision 3451 <email address hidden>.