When parsing incoming messages, ignore white-space around
In-Reply-To headers, and extract message-id items inside
the References header using a regex.
This actually serves as a workaround for broken MTAs
mangling References (such as outlook.com nesting past ones
with commas, violating RFC2822).
Closes#516 as a manual rebase.
[FIX] mass_mailing, website: fixed unsubscription link, fixed mobile preview of email designer crashing because of the redirection not taking search parameters
[MERGP] Inline Searchview
This task split the searchview in two parts: SearchView and SearchViewDrawer. The drawer is displayed inside the main view and the searchview stays in place. It also changes the scrolling behavior of the web client: the main view area can scroll without affecting the UI (so the various menus stays in place)
Because of this, other large changes have been made:
the drawer has been redesigned,
the Custom Filter widget has been split in two (Custom Report and SaveCurrentFilter),
the main view is now scrollable, so the UI stays in place and only the view can change
The text 'Group By...' has been changed into 'Group By' (most addons had to be modified)
bootstrap classes are used when it makes sense (for example, badge)
the left menu is also scrollable (separately from the main view)
It is likely that some stupid bugs have been introduced. Please don't hurt me.
- added possibility in mail to have a model adding custom headers in emails sent for notifications for new messages
- mail.group now add list-id and precedence: list in the headers to inform mailing systems that those mails are to be considered as mailing lists
- website_mail_group adds some further data in the headers (subscribe, unsubscribe, archives)
- groups page now display the number of message in the last month
- notification emails are now queued after 50 recipients
The problem was that the do_searchview_search callback was registered
after the event 'search_data' was triggered. For some reason, it
waited that the searchview was appended instead of registering directly.
- 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)
the height of the oe_view_manager_header is variable, and the top can't
be positioned correctly with pure css without a lot of work, so this
commit adds a touch of javascript to make sure that the view is
correctly positioned.
the mail menu is a client action, so not subject to the same template
as regular views. so, it had to be patched to properly scroll like
other views (meaning: the 'header', left menu and top menu are fixed)
Also, changes the width of the searchbbar into a min-width css property,
to allow it to grow more. The reason is that we don't want the searchbox
to take two lines (or more), which will force the view_manager_header to be
higher, and which will cause slight issues with the scrollbar (absolutely
positioned)
opw-608251: When coming from website > My account, and clicking on a lead link from a message in the inbox, and then deleting the lead, the history_back is triggered and we come back in the website, while we should have come back in the inbox. This is because the action performed was not pushed in the breadcrumb
after some thought, the extra method insert was not really necessary.
It was at first a way to force the user to give two nodes to determine
where the searchview and the drawer were to be inserted. However,
the second node can be omitted, a perfectly reasonable default is
to append the drawer just after the searchview.
Then, the role of insert is exactly the same as appendTo, so it makes
sense to override appendTo and remove insert. Simpler, and the job is done.
Before, the searchview and the searchview drawer had to be instantiated by
the user and appended separately to their correct place. Now, the
searchview is responsible for creating/destroying the drawer, and the
user is responsible for correctly using the insert method with
the node where the searchview/drawer are to be inserted.
incomplete work. So far, the search view widget has been split in
two widgets: SearchView and SearchViewDrawer. The SearchViewDrawer
has been inserted inline, and some preliminary work has been done
to improve the layout.
Jaydeep Barot
Thibault Delavallée
Gaurav Panchal
Christophe Simonis
Anael Closson
Denis Ledoux
ged-odoo
Fabien Meghazi
Ravi Gohil
Jean-Baptiste Quenot
Denis Ledoux
Christophe Simonis
Antony Lesuisse
Olivier Dony
Martin Trigaux