Old terms feature display the default terms from company.
But if you have more than that 10 words, it was just unusable.
Now, we just add a link to a page.
When receiving new mail (not replies) to an alias we should not take
case into account.
This also homogenize the treatment of local parts. For instance, lines
967 and 980 convert the local part to lower case to avoid
case-sensitivity issues.
Also `mail_alias` normalizes alias names by lowering case and finding,
if necessary to make it unique, a suffix to alias name provided.
From RFC 5321, section 2.4:
> Exploiting the case sensitivity of mailbox local-parts impedes
> interoperability and is discouraged
Closes#334Closes#13037
Commit 9676ceec02 removed/replaced image files in mass_mailing
module but two of them were still used by website_mass_mailing.
This commits adds these two images in website_mass_mailing module and
use a more standard convention to define associated snippets and
link them in the snippet panel. Also lint JS files.
mass_mailing snippets contained links to "/page/contactus", url which
only exists if website is installed. Also, t-if="website" which were
in snippets were unclean.
Now, the website_mass_mailing module which was already there to install
website snippet and which was already in auto-install with website and
mass_mailing is also in charge of extending mass_mailing features. It
extends the snippets to add the parts which were marked with t-if
website and add the links to "/page/contactus".
broken by e11f23b
If not full, result was always empty
This commit fix the list of view when you click on Customize top menu in website.
This menu should only display the 'customize_show' views.
When changing tracking mecanism in v9 'always' tracked fields lost their meaning.
They were managed like 'onchange' fields. This commit sets the old behavior back.
* 'onchange' fields are displayed in tracking every time they change
* 'always' fields are displayed in tracking every time they change or whenever
other tracking exist; those are used to display some contextual
information
It wasn't possible to validate a vendor bill
using a product with an asset type due to the fact
the `default_type: in_invoice` was propagated through the
context to the asset creation, and `in_invoice` is not a valid
type for an asset.
opw-689897
On a given instance with 600 000 stock.history, the query changed by
this commit takes:
- before this change => 32 minutes
- after this change => 20 seconds
opw-685747
Purpose of the code is to automatically add the recipients of quotation emails
as followers. It is done using the mail_post_autofollow context key. However
current code add the context key in all cases and not just when composing
a message on sale order.
Following commit 3cbc7ebc4c, the bug for customize menu
could have been ignored but as it is an easy fix :
The customize menu is filled after a rpc which is performed on
mousedown on the menu toggle. But in the case the user clicked on the
customize menu before the mousedown handler was attached... nothing
occured. It is possible since the customize menu is rendered but its
JS widget is only attached to it once everything is ready.
Now, the menu is filled on first mousedown or if the menu is already
opened when the JS widget is attached.
Frontend tours have to wait for base.ready() before starting otherwise
they can find DOM elements whose event handlers have not been attached
yet.
Note that this is a workaround to ignore these real "bugs" as users
should not be able to see buttons they can't click at once but there is
no safe and small fix which will resolve that. The time between the DOM
becomes visible and handlers are attached is small enough to ignore
this bug for now anyway.
Previous commit tried to handle iframe assets in a more standard way
but instead broke the order followed to install iframe communication.
While waiting for a more clean way to handle iframe assets and
communication, revert to old set up.
by auto-extending addons path with odoo.addons.__path__.
This patch also introduce
* an explicit declaration of odoo.addons as a namespace package
This is necessary because the standard way of declaring namespace
packages in setup.py does not work as long as odoo/__init__.py
contains code.
* a more reliable way to find odoo root path.
Creating a centos docker image fails on our nightly server with
this issue: https://github.com/docker/hub-feedback/issues/461
To create a centos image, we used another repository to host the
image and we make it build in docker hub, then we pulled it. It
was getting really annoying.
The use of an entry point was considered in order to provide
an `odoo` command in the path for the packages users, but the
generated entry point will first check that all the things in
install_requires were provided in a not bright way: it'll check
that it matches a distribution name. This does not work because
python-chart does not have the distrubtion name "pychart" which
is provided by the python-pychart package in debian jessie. Same
for suds-jurko which is provided by python-suds in debian stretch
but does not have the distribution name "suds".
Also, adapted the packages tests to these cli changes.
and move it under the setup package. Since the rename of the
openerp directory into odoo, having a script named "odoo.py"
conflicts with a package named "odoo".
This way we do not have to pass the version as argument. This
was error prone. If the timestamp has to be included in the
version, just patch it during before running package.py. This
was already done in our nightly servers anyway.
Odoo Translation Bot