[FIX] product
Context in _set_standard_price and many2one in product.packaging;
Set required at false for product template field when creating a product product;
Remove wrong field on product.template. TODO: move packaging field form product.product to product.template
[FIX] mass_mailing: fixes
- backport (+ cleaning) of eb22d202e4 (saas-5): mail_thread: routing: instead of exclusive routing heuristics, use each case as a fallback of the previous.
- better fix for dd36a0e509 (saas-5): mail_thread: routing: fixed replies always choosen even when replying to emails with a specified reply_to (using ref_match in the algorithm)
- backport of d6a2ae642b (saas-5): avoid evaluating a False / None domain
- fixed keeping the original message for routing, only when choosing to reply in the original thread (notification=True)
- mail_thread: routing: fixed replies always chosen even when replying to emails with a specified reply_to (using ref_match in the algorithm)
The read_group behaviour has changed and read_group no longer sum on the field you are grouping.
Instead agregate on the field we want to sum and use no groupby.
For future version, grouping on a user such as what is done in batch mode is a better way to process.
Most probably due to github migration
+ fix: directly redirect to login redirect paramas, instead of redirecting on the complete web/login + redirect url
Some browsers (e.g. chrome) trigger onEmptyClick as well as
onBeforeLightbox during drag&drop which calls two slow_create
calls (and two popups). Workaround to kill the second one.
[FIX] mail: detection of MIME type
When parsing the mail headers, the content-type may has a 'type' attribute for Multipart/Related objects (rfc2387).
Previous check would match on attached files of type text instead of real `content-type: text/`.
- fixed keeping the original message for routing, only when choosing to reply in the
original thread (notification=True)
- auto delete sent emails explicitely
- mail_thread: routing: fixed replies always choosen even when replying to emails
with a specified reply_to (using ref_match in the algorithm)
- mail_thread: routing: instead of exclusive routing heuristics, use each case
as a fallback of the previous.
Be careful, content-type may contain tricky content like in the
following example so test the MIME type with startswith()
Content-Type: multipart/related;
boundary="_004_3f1e4da175f349248b8d43cdeb9866f1AMSPR06MB343eurprd06pro_";
type="text/html"
same_thread boolean field of mail.compose.message model define wether or not replies should be posted in the thread or not
On composer creation, this boolean should be passed according to the reply_to_mode of the mass_mailing
Otherwise, all replies would be posted in the thread, and the reply_to will be ignored (if same_thread id True, reply_to is poped from the mails values, mail/wizard/mail_compose_message.py:284)