[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.
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"
This restriction behavior copied from the sale.order model
Moreover, the purchase.order lines state were not set to cancel when the purchase order was cancelled.
This is now the case, this behavior is also coped from the sale.order model
When the purchase order is reset to draft, we also reset the order lines state to draft
This fix is related to a37bad205b
This previous fix did solved the issue of its purpose, but had a side effect for actions using these active* params, e.g. search views
For instance, Go to Project > Projects, click on any project, you are than redirected to tasks/issues of this project
If you reload the page, an error pops up, complaining that active_id cannot be found
[FIX] website_mail_group: discussion group snippet
- moved into website_mail_group, instead of having the snippet in website_mail and the archives in website_mail_group
- fixed routes to avoid security issues
- better display of email on groups and archive
event.event.ticket were set in website_event_sale, while this model is set in event_sale module
Manager acl moved from website_event_sale to event_sale
Created a new acl for event user in event_sale
Left the acl for everyone in website_event_sale, meaning that when this module is installed, everyone can read tickets, event those who aren't event user
[FIX] Fix o2m record duplication when clicking on a button
The button action will execute a write call, creating the new line.
The reload is necessary to avoid recreating the line when using the save button.
Christophe Simonis