openerp-india team mailing list archive
-
openerp-india team
-
Mailing list archive
-
Message #07221
[Bug 921442] Re: [6.0/trunk] Encoding trouble in mail_message parsing and base_action_rule processing
Hello,
Their are two points proposed in this bug as per Comment #7 by Jignesh
Rathod.
So We have tested the first part of the bug which is "Parsing the rules (base_action_rule) breaks if the regexp or the name of the resource (model) has some non-string char". And Technically it is valid bug, we have reproduced the bug and I am adding step here for the same :
Test case :
- Install Module crm.
- Create 'Automated Action' under Settings/Customization/Automated Actions/Automated Actions for the model crm.lead.
- Now Supply non-character (e.g. "ààààààà") string under following two field :
- First field Under Conditions on Model Fields Section, 'Regex on Resource Name '
- Second field Under Section 'Condition on Communication History' Regular Expression on Case History
- Now, When Automated action with non-character string will be trigger we will have traceback on server saying :
File "/home/jam/rdtools/addons/trunk-calendar-phase2/base_action_rule/base_action_rule.py", line 372, in do_check
ptrn = re.compile(str(reg_name))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-6: ordinal not in range(128)
2012-02-15 05:55:44,278 4176 ERROR ? openerp.netsvc: ascii
ààààààà
0
7
ordinal not in range(128)
(You can see the Video on Comment#13 for the same)
SO the Merge Proposal Given by Kuldeep Joshi(OpenERP) at Comment#8, Fixes the First Part of Bug,
MP Link : https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-bug-921442-kjo/+merge/92248.
About second Part we do not any case which produce bug.
So I request Community Team to take Appropriate Decision for the Second Part of the Bug.
Update me If I am wrong.
Thank You.
--
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/921442
Title:
[6.0/trunk] Encoding trouble in mail_message parsing and
base_action_rule processing
Status in OpenERP Addons (modules):
Confirmed
Status in OpenERP Addons 6.0 series:
Fix Committed
Status in OpenERP Addons trunk series:
Confirmed
Bug description:
hi,
We've got an issue with encoding in the crm part. This will be difficult to reproduce.. :( So, please look at the code to understand the problem..
First bug part : Parsing the rules (base_action_rule) breaks if the
regexp or the name of the resource (model) has some non-string char.
In the function do_chek you have :
if reg_name:
ptrn = re.compile(str(reg_name))
_result = ptrn.search(str(obj.name))
Calling str() method here breaks if some unknown char are present in
the object name or in the regexp name it-self.
See my patch, I suggest to just remove that call to str() as both are
already in unicode which is perfect => no need to convert with str().
Second part: Fetching mail when some character are broken in the body_html part. It could happend that you receive an email with broking characters in it, you should not block everything because of that. Currently, if it happend, no other mail are fetched, and you got an PostgreSQL error when trying to write it in DB : invalid byte sequence for encoding "UTF8": 0xe96ce9
In the parse_message of mail_message.py, you make everything to take
care of the coding, nothing to improve there I think. But, if the
message (body_html) contain broken char (I mean non-valid one, not a
coding trouble, like in this example : unicode('abcdef' + chr(255))),
then it breaks the mail fetching.
As body_text is encoded in unicode, I suggest the same in my patch,
but with the option errors=ignore. This way we skip all non-conform
char, and ensure the write method will only write valid char in DB.
The provided patch worked on more than 900 mails, so I think it's
good.
Thanks for your consideration,
Regards,
Joël
Ref: http://docs.python.org/howto/unicode.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/921442/+subscriptions
References