lp:~akretion-team/openobject-server/openobject-server-fix-ir_model-field_description

Branch merges

Propose for merging

No branches dependent on this one.

Ready for review for merging into lp:openobject-server/7.0

Raphaël Valyi - http://www.akretion.com (community): Approve on 2013-09-27

OpenERP Core Team: Pending requested 2013-09-27

Diff: 43 lines (+5/-5)

1 file modified

openerp/addons/base/ir/ir_model.py (+5/-5)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Bug #1231900: unicode support for field_description field in ir_model_fields

Medium

Fix Released

Link a bug report

Related blueprints

5089. By David BEAL (ak) on 2013-09-27

[FIX] replace 'str' by 'unicode' in 'ir_model_fields' class (write method) in 'model_props' list for 'field_description' field : avoid to crash when you change 'field_description' value with some non ascii chars

5088. By Launchpad Translations on behalf of openerp on 2013-09-27

Launchpad automatic translations update.

5087. By Launchpad Translations on behalf of openerp on 2013-09-26

Launchpad automatic translations update.

5086. By Launchpad Translations on behalf of openerp on 2013-09-25

Launchpad automatic translations update.

5085. By Denis Ledoux (OpenERP) on 2013-09-24

[FIX]base, ir_translation: in _get_src, if model or record id does not exist anymore, do not apptempt to read it

5084. By Launchpad Translations on behalf of openerp on 2013-09-23

Launchpad automatic translations update.

5083. By Launchpad Translations on behalf of openerp on 2013-09-22

Launchpad automatic translations update.

5082. By Launchpad Translations on behalf of openerp on 2013-09-20

Launchpad automatic translations update.

5081. By Launchpad Translations on behalf of openerp on 2013-09-19

Launchpad automatic translations update.

5080. By Olivier Dony (Odoo) on 2013-09-18

[FIX] ir.mail.server: improve support for user names with emails

The previous fix in revision 5072 only allowed user names
that contained the exact same emails, but users will do
the wildest things like having `<email address hidden>` as
name but setting their email to `<email address hidden>`.

This was blocked by our sanity check looking for a single
email in the From header. As this check is only done
in order to provide a better error message, it should
not impact valid cases.
Modifying the check to pass when at least one email
was found should be enough to catch most invalid cases,
without requiring a more advanced analysis of the
header value (the RFCs allows very strange things!)