In the contacts app, you can select 2 partners and merge them.
Before this commit:
- If a partner was added by a SQL query and not directly on Odoo,
the create_date will be empty. This causes a crash because the
merge wizard try to sort the partners by date
After this commit:
- If a partner do not have a create_date, it will be considered
as 01/01/1970. The merge wizard will sort the partners by IDs too.
OPW-2091925
closesodoo/odoo#39523
X-original-commit: deeb769c0d579c51ab42b072ccc1c013d79fcea4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
odoo/odoo#30688 (6ce2d6efb5) added an
indirection in prefork workers: Python-level signal handlers are
delayed until native calls have ended (e.g. accept() or
execute()). Running the actual work in a sub-thread allowed the main
thread to handle signals in all cases.
However there is apparently an issue with SIGXCPU on linux (possibly
other cases as well): SIGXCPU is delivered to the child thread (if
possible?) and Thread.join apparently stops it from redelivered to
the main thread (Thread.join is signal-interruptible since 3.2 but
possibly not Python-interruptible).
Blocking SIGXCPU on the child thread causes the OS to deliver on the
main thread and fixes the issue.
Also split set_limits so it sets the signal handler in the parent
thread but properly updates the soft limit in the child after each
request, as the goal is to put a hard limit on the CPU time per
request, not on the worker. 6ce2d6ef would set the limit once then
never update it, likely cycling workers more than desired.
While at it:
* block other signals with a handler set, they seem to work
regardless on linux but other OS may have a different way of
dispatching process-directed signals
* unset signals which are set by the prefork server but whose
set behavior makes no sense in workers:
- TERM and CHLD were already unset
- HUP is used to restart the server, workers can just be killed
- TTIN and TTOU configure the number of workers
closesodoo/odoo#39731
X-original-commit: 549bd199bad269e4e28efac933efac3f41495877
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
`is_false` relies on no small part on equality tests between the input
triplets and either `TRUE_LEAF` or `FALSE_LEAF`. While these are
defined as tuples, RPC domains will always be lists (as neither
XML-RPC nor JSON have tuples, and their arrays deserialize to Python
lists).
This is an issue, because tuple and list never compare equal. As a
result, while the in / not in predicates can succeed, the TRUE_LEAF /
FALSE_LEAF never will, and thus domains which contain either and might
shortcut (avoid a query entirely) will always go through the entire
process.
Fix by having domain normalization also ensure all triplets are
tuples: that's the first thing `is_false` does, it should never cause
issues and could fix / improve / shortcut other routines.
Note: Also implements TRUE_LEAF and FALSE_LEAF handling in the
SSF's modifiers evaluator. And fixes the ValueError to work
correctly if it breaks on a tuple / dict.
closesodoo/odoo#39706
X-original-commit: a44f008b918ee66742f7e943b00e4ee3d7fe2b78
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When importing an O2M value (sub-record), rather than raising an error
if the value has a xid set (foo_ids/id) and the xid does not exist in
the database, re-insert the xid as the "id" field of the sub-record,
then re-extract it at creation (the ORM will have ignored it) and
associate it with the newly created record.
Advantages:
* keeps o2m creation in the proper order during import (sub-records
remain created after the parent) meaning o2ms with a required parent
can take advantage of the feature
* avoids breaking batching when creating the objects
* no new command or smuggling through an existing command
closesodoo/odoo#35995
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Turns out almost no user of odoo.tools.osutil actually imports
it. Following odoo/odoo#39573
(355e360973) removing what were
apparently the only two users of the submodule properly importing it,
other calls to osutil features now blow up, which went unnoticed as
these calls are lazy (so don't prevent starting the server) and only
happen for very specific operations.
The smallest change there is to simply re-enable the old behaviour by
explicitly importing osutil from tools.__init__.
closesodoo/odoo#39705
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When testing the import of records, a flush should be done to check
all databases constraints and fields computations.
Moreover, in case an exception is raised within a savepoint,
the environment should be cleaned up, to avoid tricky bugs (see below).
We replace the manual handling of savepoints with the savepoint
context manager, which already handles all of this.
This code predates the context manager, so in a way it was archaic.
When testing the import of records, the following could happen:
"An unknown issue occurred during import (possibly lost connection,
data limit exceeded or memory limits exceeded)."
This would happen on project tasks; the fields 'working_hours_open',
'working_hours_close', 'working_days_open', 'working_days_close',
all depend on the computation of _compute_elapsed.
Because this is a test import, the records would raise a MissingError,
and fields_to_compute would always contain 3 of the fields.
The resulting is an infinite loop giving this error.
opw 2092134
closesodoo/odoo#39682
X-original-commit: 1a315e87b05fcbdefcb3db6d8d4837f6cc3e835c
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Initial b6ed34e1 idea was to ensure that we always have
_rewrite_len and _routing_map defined. Unfortunately, this
is not correct since class attribute defined dynamically
are actually added in registry, and recomputed on each install.
More than that, the call si shared between multiple database
meaning that routing_map cache may be shared between multiple
database whcich is not correct.
After b6ed34e1, when installing discuss on a fresh database without
demo, all discuss routes will be unknown since None is already in
_routing_map and thus routing_map is not recomputed.
When routing_map is on the model class, in registry,
a new install will reset the class, remove the _routing_map attribute,
which will fix the problem.
Task #2117275closesodoo/odoo#39640
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Activate developer mode, generate a report (print an invoice)
The report will have missing pieces, like the footer or some part of the
header. This is probably caused by wkhtmltopdf not loading properly some
resources
Wkhtmtopdf generate the same warning message for every problematic resource:
"Warning: Received createRequest signal on a disposed ResourceObject's
NetworkAccessManager. This might be an indication of an iframe taking
too long to load."
Related issue on wkhtmltopdf project page:
wkhtmltopdf/wkhtmltopdf#1865wkhtmltopdf/wkhtmltopdf#3933wkhtmltopdf/wkhtmltopdf#2565
The problem is located in the response that wkhtmltopdf receive:
in debug mode the header of the response contains
'Cache-Control: no-cache' which probably create a race condition during
the rendering while a second request is attempted to verify the
resources.
Adding a raw user agent check to not include this header directive
fix the problem
Notes from odony:
We've considered some alternative solutions to preserve the purpose of the
DisableCacheMiddleware without having to explicitly test for wkhtmltopdf.
* 'Cache-Control: no-cache' (current behavior) breaks wkhtmltopdf rendering
* 'Cache-Control: no-store' breaks wkhtmltopdf rendering too
* 'Cache-Control: max-age=0' breaks wkhtmltopdf rendering too. It works
when increasing the delay to a few seconds, but no magic value will work
for very long documents, or it will stop serving its purpose, so it's not a
viable option.
* 'Cache-Control: must-revalidate' does not break wkhtmltopdf rendering (no
duplicate requests at all), but it is not clear from the RFC
(https://tools.ietf.org/html/rfc7234#section-5.2.2.1) that it
will have the intended effect for our middlewar
opw-2086708
Closes#38394closesodoo/odoo#39634
X-original-commit: 8cac60be37133cabef46dab016a5692876da9e5e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since a many2one_reference is simply an int, we can defer
_str_to_many2one_reference to _str_to_integer.
Note that to really validate the integer, we need the model_field of the
field, which should be stored in the record's values.
To get this information, _extract_records would have to be modified.
For the reported use-case, it does not matter as the create of the
message record checks for the existence of the related record,
so the validation works as expected.
Better support for this type of fields would be to allow for
import/export of xml_ids, which would avoid the need for the model.
opw 2087353
closesodoo/odoo#39601
X-original-commit: 77f616e9359272b2598d414672cffbc06cee2a33
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
After deleting records from model 'ir.model.fields', make sure to not
trigger recomputations based on those fields, as they have been removed
from the database schema.
Also shorten the deletion of 'ir.model.fields.selection' records: as
they are deleted after 'ir.model.fields', most of them have already been
deleted on cascade.
closesodoo/odoo#39607
X-original-commit: 6b048a8b86bb32955c165dfb31736e9df5828f7a
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
* walksymlinks is useless, os.walk got followlinks in 2.6
* tempdir is redundant with tempfile.TemporaryDirectory added in 3.2
* listdir(recursive=False) is just os.listdir (I guess recursive=True
is somewhat useful)
* zip_dir is *not* redundant with shutil.make_archive:
- zip_dir handles the archived root differently
- zip_dir sorts files, make_archive sorts directories
- make_archive explicitly adds entries for directories (including
empty), sorts directories, doesn't sort files; zip_dir sorts
files (including with a custom key function) but ignores directories
- zip_dir filters out a bunch of trash files
closesodoo/odoo#39573
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, console.error were catched by browser_js
in order to log them but only value was used on received object,
which is correct only when the received object is text.
With owl arrival, error object may be logged. This
commit add the ability to manage logged object, fallbacking on
a complete representation of object if object is not an error or
description is empty.
closesodoo/odoo#39592
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The two method valid valid_alternative_icon_text and valid_title_icon
represent ~13% of an install all. Rewriting them in master
with in #36373 is the main reason of the performance improvement.
Those two method logic were broken, because
`xpath += '[not(//*[' + valid_attrs_xpath + '])]'`
will actually search for valid_attrs_xpath from view root,
not from fa- node.
-since this check will only log a warning and so only impact
bugfix, no impact on user editing views,
-since a new check is added in master with the corresponding fix in views,
-since this check doesn't really test what it is suppose to check,
-since fa accessibility is great, but not critical
->removing those check will slightly speed up build without major impact
on views quality
closesodoo/odoo#39566
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Actually, the two class attributes are only set when calling the
routing_map method. As a consequence, when the url_for function in the
http_routing module tries to access the _rewrite_len attribute, it
may crashe.
This problem arrise in the TestQwebProcessAtt from the website module
when the test is run alone.
It was hidden on the runbot because some missconfigured HttpCase tests were run
at_install before TestQwebProcessAtt. In that particular case, the
routing_map method is called and sets the attribute.
With this commit, the _routing_map and _rewrite_len class attributes are
set on the class at class declaration time.
In some case, a browser_js test with login "None" following a browser_js
test with a defined login could result in the second test being executed
with the previous user.
This was caused by a race condition, a request response comming back
to chrome just after browser clear, restoring the old cookie.
(All odoo request have the set_cookie flag set in order to refresh
cookie timeout)
The solution here is to check one more time for cookie in authenticate,
but also to remove HTTPCase session from session_store. This will
only be effective when calling browser_js without login in the same
HTTPCase .
closesodoo/odoo#39525
X-original-commit: 218db53b9da1573dc18610678de3b7f763531c60
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The profiler was too optimistic. If the local variable self was not a
cursor, it assumed it was automatically an Odoo model.
Instead, only do the custom tracer methods when self is an instance of
BaseModel.
Full scenario to reproduce explained at odoo/odoo#39237
In case a method like the default_get of utm.mixing was profiled, the
tracer crashed when evaluating `__bool__(request)`.
The tracer considered self as an Odoo model while it was a werkzeug
instance with its custom __getattr__ that crashed while trying to
retrieve the content of `_name`.
Fixesodoo/odoo#39237closesodoo/odoo#39524
X-original-commit: c8fa8fb067dcfb15330acde35d66ac41a255f669
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
m2ms are internally represented as "6" commands, however in domains
it's possible to compare an m2m value to a list of ids (to
investigate: whether this is an artifact of internal webclient repr or
part of the real contract).
Add a workaround in SSF modifier computation to convert the m2m
command storage to a simple ids list.
A better fix would probably have been to represent the m2m as a list
of ids internally (and only convert on load / save) however it not
completely trivial as it has to be done recursively in order to
properly handle an m2m inside an o2m. So it's a complete change of the
internal data model (which should probably go alongide more
fundamental changes e.g. properly handling parent refs, etc...)
Also add very minor support for widgets (mostly so it's possible to
set widget=many2many on an o2m field).
closesodoo/odoo#39467
X-original-commit: 927979beff9e5d4f6c88078862779eaa88f4e07d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Have a parent template
Have a child, in extension inherit mode of the parent
The child has a xpath like
`<xpath expr="." position="replace" />`
Before this commit, there was a crash.
That was because the Comment
(which indicates which templates modified the parent)
was taken as the replacer node
instead of the actual content of the xpath
After this commit, there is no crash, and it works as expected
closesodoo/odoo#39453
X-original-commit: 02d790e1d21b78395e489f57bf30c82f728cbee6
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The purpose of this patch is to avoid `filtered_domain` to crash with
domains on date/datetime fields when the fields are `False` on some
records:
records.filtered_domain([('date', '<', '2019-10-28')])
closesodoo/odoo#39449
X-original-commit: dae379adebedb3ed9bd38a2d6925ba6aefef1e7f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
res_name is made non-stored in 8fffe89b0481af057fd6908a52af775578b9fce1
but the groupby filter using the field is not. The filter has to be
removed as well because groupby only works with stored fields.
closesodoo/odoo#39396
X-original-commit: 495124497c733b4bb272fb0d65e132b024a99917
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before, en_US was almost always the default in case of 'no language'.
Now, that should be superseded by lang=None;
yet still, en_US plays the role of source language.
In a multilanguage database where en_US was not installed,
writing a translation with lang=None would crash.
This could prevent module installation.
A test is added to cover that case.
In the case where we write a record with lang=None, the source is the
same as the record; in that case the cache contains the value for the
field.name under the context keys en_US and None, so we need to
invalidate the cache to avoid getting back the old value.
co-authored with mart-e
opw 2088487
opw 2083710
closesodoo/odoo#39130
X-original-commit: 1a5a999c2dd69c9a6a2dacb59e8bf45b09c6bc13
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Since https://github.com/odoo/odoo/commit/a5b6f31cf28e5381e1c85f66730bcdb55998e643,
the current companies of the user are saved in the context as "allowed_company_ids"
context key.
In case of invalid context content, the api was computing the intersection
between the context content and the user company(ies) and falling back on user
company_id(s) when catching an error.
A sanity check was done, but no feedback was given to the user,
saying that the context change was falsy.
This commits changes this behavior to :
* raise an AccessError when trying to access self.env.company(ies) when
invalid or unauthorized companies are defined in the context.
* take sudo mode into consideration, allowing inter-company impacts,
even when current user doesn't have access to a given company,
if the code is done in a sudoed environment.
Co-Authored-By: Raphael Collet <rco@odoo.com>
This is a preliminary work for task 2088171 that will
improve server action creation usability in marketing automation.
When creating a marketing automation activity, one can choose to trigger a server action.
This task aims at improving a the usability of this option for non-technical users
as well as cleaning the view a bit (because so far we display the standard server action form view).
closesodoo/odoo#38922
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The queries made by the method `_is_an_ordinary_table` represent about
8% of the time to do a full Odoo installation. Use a cached query for
all tables on the registry to reduce that time to some negligible
amount.
closesodoo/odoo#39262
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The nightly clickall runbot fail due to a crash of the underlying chrome
browser used to run the test suite. The problem is related to the
resources the browser is using. We leverage the problem by starting one
dedicated browser per app.
closesodoo/odoo#39190
X-original-commit: 228e57d980839bd2b4e9123bf26f8a64de2ae6ab
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The basic ORM methods should not silently discard unknown fields, as
they may be a sign of broken code.
X-original-commit: 9595dd06a1d349b2fb84969374d57c32a5faab74
This commits fixes user duplication.
Suppose there is a monetary field, with a currency_field that is a related.
When going through model's _create, we do:
`if field.type in ('one2many', 'many2many'):
self.env.cache.set(record, field, ())`
knowing that thse values are false, with the intent to clean them later:
`for record, field in cachetoclear`
However, when setting the scalar values, we go through:
`accessing cache_value = field.convert_to_cache(value, record)`
In the case of the monetary field, this depends on another field value
(the currency_field). If it is a related, we can access its value.
However, at this point, if we check any access rights, we might use the value
of a relational in cache for which the value is incorrectly set to False.
In the case of the user, this is what happens: it inherits its currency_id
from partner, as well as its debit_limit which depends on it.
When the access if checked, company_ids is set to False in cache.
So when going through the rule 'user rule', which checks that the company_ids
intersects with the env.companies.ids, the result is always False.
In some way this is essentially hiding the problem, but the true fix is
probably not feasible in stable.
opw 2086661closesodoo/odoo#39017
X-original-commit: aa05a9359b42317261c8e7ffcadbeb9fe74dcd58
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Start odoo-bin using a tier module (like `python3 -m pdb odoo-bin`), the
odoo/addons __path__ contains the relative link to the modules instead
of the absolute link like when directly started (`python3 odoo-bin`).
This cause trouble importing modules because it reuses the relative path
from within other directories.
closesodoo/odoo#39182
X-original-commit: 941e051fc6b33e7a90400c77d63d589049b027a6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This fixes a regression introduced by 291a0e99d137142bd24addd1054c1357ddd7125a.
closesodoo/odoo#39178
X-original-commit: 852ee32e3419c210a3844b0f943af8dd2bbdae88
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Do not return a boolean but skip bad translations
Introduced at 19e50ea374Fixesodoo/odoo#39001
At least fix the error that is thrown, however, this does not solve
the initial error of trying to export the terms of a record that is no
longer present in the database.
As this issue is no longer reproducable, just log a warning as it was
expected.
closesodoo/odoo#39122
X-original-commit: 5c0677bf2fbf6d18978989f1ee70e4a0946da035
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, if `max_width` and `max_height` are 0, the image would not
be opened by Pillow at all (to gain a bit of CPU) however this was actually a
bad idea in this case because then we don't ensure the given value is actually a
valid image when we save it, only later at display we notice it and it crashes.
This optimization only made sense when `image_process` is called many times,
from the route displaying images every time a visitor is requesting an image,
for example. It doesn't really have an impact for one time operations such as
creating/writing.
So when size parameters are 0, which is the default, another parameter must be
passed to `image_process` to ensure image validity, and `verify_resolution` is
actually built for this, as it does the minimal amount of processing:
- loading the image
- making sure it is valid
- and ensuring the resolution is not completely crazy (`IMAGE_MAX_RESOLUTION`).
It doesn't alter the original image if no other operation was requested.
Pr: #38292
X-original-commit: e16c36bb4bfa3ae1739712c69c72849665a057dd
Binary fields are supposed to be saved as binary in cache, and not as string
which is also supported as an input value.
Pr: #38292
X-original-commit: 64e0d106adccd8132cbfeb6b60da74b3feaf05e1
The compute methods are always expecting the real value and not the bin_size.
The solution is to always compute with `bin_size=False`, and then manually
compute the `bin_size` and set it on the cache of `bin_size=True`.
PR: #38292
Co-authored-by Sébastien Theys <seb@odoo.com>
X-original-commit: 7744886d6141ca7971d91807d0444c707e10fdf8
Assets bundle creation will try to find previous version of assets and unlink them.
This needs to invalidate ormcache to notify other workers.
Since assets are never commited during test, assets will be generate at each request if request is
not commited (cursor closed) whtch is the case with 404.
Invalidating the orm cache only when a previous attachement was existing will help to
mitigate the problem, and slightly improve HTTPCases test speed.
closesodoo/odoo#38979
X-original-commit: d4d63549e1b31e3f3c97a2b91155023dbac62847
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Without this patch, if a view defines a `<label for="forbidden_field"/>` anywhere, the web client tries to fetch the field data, but since the user has no access, it gets an error.
Now, if the label targets a forbidden field, it gets removed from the view, as happens with the related field. The client doesn't know of that field's existence and no errors happen.
closesodoo/odoo#38876
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Users sometimes define custom models on SQL views
e.g. @nseinlet
In such a case, Odoo should not attempt to create foreign keys
as it just cannot work on views.
This could prevent the migration of a database
with such a custom model using a view
when it attempted to fix the missing foreign keys
when updating the modules.
closesodoo/odoo#38988
X-original-commit: dfaea03de57394a9a188f499da664c57dd9adc29
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Purpose
=======
It sometimes happens that the last runbot build is green, but it's
impossible to create a basic record (a new user for example) in the
interface.
This commit adds new tests using the Form tool (so triggering the
onchanges, and so on), to check that those basic models can be
instanciated without any issue on the interface.
closesodoo/odoo#38962
Taskid: 2070350
X-original-commit: e6d8c471c036a35b2c86f91d0053435f468c0ab8
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
It is possible to get to a situation where Odoo would try to send an email without a `From:` header address.
In such case, you're unlucky if you don't have access to the underlying deployment, or if you use multiple databases in a single Odoo instance and each of them uses a different mail configuration.
To make this configuration easier to use and cover those use cases, here I add support for a new ICP: `mail.default.from`. It will be used when present, so it shouldn't affect existing deployments. When present, it will allow a admin to configure the default sending address just with Odoo itself.
closesodoo/odoo#38874
X-original-commit: 5010ce630a7f0e01d45d99c9083318b50f9f624a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After the refactor of mail sending with the newest python API
(18299d7e50),
the order of multipart/alternative was wrong for email.
Indeed, in the MIME protocol [1], for The Multipart/alternative subtype
the order is significant: "In general, user agents that compose
multipart/alternative entities should place the body parts in increasing
order of preference, that is, with the preferred format last".
This bug caused some issues with mail marketing (see related task)
with Gmail web client (see the plaintext instead of html mail).
The fix is to inverse the order of adding alternative in the mail
content.
[1] https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
TASK_ID : 2084989
closesodoo/odoo#38490
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* use an editable tree to edit the supplier info
* keep the original forms because they're used in the "vendor pricelist"
menuitem
* updated tour
* change the position of requisition_id
Task-2029380
closesodoo/odoo#35972
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
jvm-odoo