The authorize payment API has deprecated their md5 based authentication
in favor of sha512. The `test_10_Authorize_form_render` test was failing
due to no-more-valid tests inputs.
As the `payment.transaction._authorize_form_validate` method verify the
status of the transaction before validating the form thank to 01216345,
calling `_set_transaction_done` is no more valid thus has been removed.
The reference has been changed due to the same commit.
closesodoo/odoo#36139
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
previously, with multi-company setup, when we switch company from
top right corner, that company was set as current user's main company.
But with commit a5b6f31cf2 it no more changes current user's
company but updates 'company' property of environment for specific
browser tab. So, env.user.company_id has to be replaced with
env.company.
Task: 2052484
Closes: 35851
closesodoo/odoo#35851
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Fine-tuning 180866fe1e
- Go to Sales > Configuration > Settings
- Enable "Multiple Sales Prices per Product" and select option "Prices
computed from formulas (discounts, margins, roundings)"
- Go to Sales > Catalog / Pricelists
- Select "Public Pricelist" and set "Discount Policy: Show public price
& discount to the customer"
- Add a discount to an event (20 % to "Open Days in Los Angeles" for
example)
- Go to the eCommerce, buy a ticket to "Open Days in Los Angeles" which
as a 20 % discount
Since 180866fe1e the discount is applied
two times.
opw-2058709
closesodoo/odoo#36106
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fine-tuning of 1da058f8ed, for the same use-case.
The _valid_barcode method is here to bypass the barcode_company_uniq constraint.
The constraint is put on barcode/company couples;
however if checked without a given 'company_id' in the values,
which ends up as False, then the check is actually not the correct one:
the company_id is going to be filled later by the default_get.
Instead we use the value given by the default_get, consistently with the create.
The same error could affect _create_missing_locations,
since it gives an explicit value to company_id that was not passed in values.
We give it to make sure that the company is consistent there to.
opw 2058888
closesodoo/odoo#36102
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Have a product template, assign a dynamic attribute to
(the corresponding variant will be created when used in a SO)
Try to name_search for it
e.g.: in the product configurator modal, type some letters to catch it in theory
Before this commit, the product template was not found by the name search
this is because the template doesn't have any variant yet
After this commit, it is found by the name search
OPW 2060603closesodoo/odoo#36215
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Create a partner with a child *WITH THE SAME NAME*
Create an invoice for the child
Create bank statement and line, with the field partner_name equals
to the child's name (and to its parent)
Open the reconciliation wigdet for that statement
Before this commit, the widget searched lines for the child partner
because partner_name matches the child in priority
Hence the invoice just created was not present
This is because when validating an invoice or a payment
the journal entry's partner will be the commercial_partner_id of the child
By definition the commercial partner_id doesn't have a parent_id set
After this commit, the invoice is visible in the widget
OPW 2039768
closesodoo/odoo#36184
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Fixed backgrounds are disabled when using a mobile/tablet device,
which is not a big deal but, on some of them (iOS...), defining the
background as fixed breaks the background-size/position props.
So we enable this only for >= XL devices.
We may want to find a better alternative for future versions.
opw-2055073
closesodoo/odoo#36187
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit changes the '_get_combination_info' signature according to main
method signature to avoid inheritance problems.
closesodoo/odoo#36125
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
Test frontend and UI tools of eLearning.
SPECIFICATIONS
Commit fe518f1fea introduced a search on sale order model in checkout
process. However this may fail as access rights are not always granted
* portal users can see orders linked to their company;
* salesman and a lot of specific groups (accounting, ...) can see their own
orders, all orders, or depending on some condition;
* BUT standard users (employee only for example) cannot see any sale order.
Indeed they do not even have right to read, meaning a search fail. Let us
sudo the search as this is contained in a sub method used to fetch some
data.
LINKS
Task ID 1937768
closesodoo/odoo#36166
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
-Create a second blog
-Move one post to this second blog
-Access the post with the url from the first blog
Before this commit:
You will get redirected to the new url with a code 302 (temporary).
After this commit:
You will get redirected to the new url with the code to 301 (permanent).
OPW-2059194
closesodoo/odoo#36161
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When validating a picking from location A to B, location A's quant.quantity
may be updated to a quantity != 0 with _update_available_quantity.
This is because the quant value is written as quantity - float_round(quantity).
As a result, the consistency check would find two existing quants, and raise.
Therefore the picking cannot be validated.
opw 2040091
closesodoo/odoo#35913
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, a channel in mobile with option "Send messages
by email" had no composer when opening in mobile.
This issue happened because channel views in mobile are in fact chat
windows. Chat windows with such channels do no display any composer,
which is intended in desktop.
This commit fixes the issue by enabling the extended composer for
chat windows with email channels, just for mobile.
opw-2059468
closesodoo/odoo#36120
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The color picker in snippet options has two way to set a color: have a
data-color attribute => it is used, or have a o_custom_color class and
the background-color is set directly on that color.
In the case where we select no background color (transparent), it would
work in preview, but when applied the opaque color of the transparent
button (since opacity is not copied) is set which is wrong and
unexpected.
opw-2053636
closes#36131
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This reverts 0164c9dfcb
Have exchange rates:
Domestic - Domestic: 1.0
Domestic - Foreign : 1.113900
Make an invoice: 480 Foreign
Make a credit note: 140 Foreign
Make a payment: 287.20 Domestic
Reconcile all this with a writeoff: 18.04 Domestic
Before this commit, the first invoice was not fully paid
this was due to wrong summing of the partial lines that applies to it
account.partial.reconcile are made between only 2 move lines at a time
Whatever the amounts they hold, it has been computed at creation
and it makes no sense to aggregate their rounding error when computing
their impact on a move line (because, the information is already lost)
After this commit, the use case works, all invoices and payments are fully consumed and reconciled
Note that this is a simple use case, no dates or exchange rates involved
OPW 2057845closesodoo/odoo#36087
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Commit 54d30d5194 introduced `lastmod` and `priority` on sitemap locs.
This was broken with 4ecbacaf59 which introduced `website.page` model as it
removed the `PageConverter`.
Before website.page:
1. PageConverter returned records with `__lastmod`
2. `enumerate_pages` loop on converters would remove the prefixed `__`
After website.page:
1. code to remove `__` was still there but the pages would be found and looped
on after that code, making it useless.
With this commit:
1. The code to remove the `__` is moved after searching the pages.
Following #36090
Related to #35464
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Enable work orders, routings, and track components by lot numbers or serial.
Create an MO for a certain X quantity of finished products and plan work orders.
Only complete a partial amount Y of the overall X amount.
Specify the lots for the consumed tracked materials equal to the Y amount.
Then, return to the MO and click "Post Inventory".
An error is raised because the lot is missing.
This is because when processing workorders temporary lines
are created without lot/serial for tracked component products.
This is a limitation that require a task to be removed;
in the meantime we remove the button, in true bugfix fashion.
opw 2049806
closesodoo/odoo#35731
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
There is an open issue on the tempusdominus lib:
https://github.com/tempusdominus/bootstrap-4/issues/223
It occurs when there is a valid value in a date(time) field, and
the user unsets it by setting an invalid one.
This rev. fixes the issue in Odoo by preventing to reach the buggy
piece of code in the lib. In a few words, when the user sets an
invalid date, we reset the previous valid date (which is what the
lib tries to do anyway).
Task 2057009
closesodoo/odoo#36211
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
### [FIX] bus: background slave tabs should not loose notifications
Slave tabs missed some notifications in case the local storage
event's `newValue` did not match actual value in local storage. This
happens when master tab overwrites a value that slave tabs did not
take the time to read. Slave tabs should now always handle all local
storage events.
Task-ID 2044231
### [FIX] bus, mail: correctly synchronize document chat windows
Cross-tab synchronization of document chat windows resulted sometimes
with an infinite loop. This happens due to tabs relying on actual
value in the local storage and all document chat windows state being
set as a single local storage entry. Cross-tab communication of
document chat windows now is relying on event's `newValue`, and each
document chat window has its own local storage entry. Changes from
local storage no longer writes again in the local storage, so that
it no longer makes an echo (= infinite loop).
Task-Id 2034997
closesodoo/odoo#36177
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, there could be an infinite loop when changing
the chat window state of a document chat window.
This is caused when mutiple tabs overwrite the chat window state
with a different value everytime, resulting to an infinite loop.
Accross multiple tabs, `setItem` and `onStorage` are not synchronous.
That's why tabs should communicate through local storage events
instead of actual value in the local storage.
To illustrate the issue, suppose there are 2 tabs (T1 and T2) with
one document chat windows (C) and the following user interactions:
- T1 and T2 both have C open
- on T1, user folds C
- on T2, user folds C
Now let's add an example of local storage (LS) logics that could
apply from above example:
- T1 and T2 both have C open
- on T1, user folds C
[1] T1 writes 'C folded' in LS
- on T2, user folds C
[2] T2 writes 'C folded' in LS
[3] T2 detects 'C folded' in LS (from [1])
=> T2 writes 'C folded' in LS
[4] T1 detects 'C folded' in LS (from [2])
=> T1 writes 'C folded' in LS
[5] T1 detects 'C folded' in LS (from [3])
=> T1 writes 'C folded' in LS
[6] T2 detects 'C folded' in LS (from [4])
=> T2 writes 'C folded' in LS
etc...
This scenario could have been easily prevented by not writing on
local storage when the chat window state has not changed. However,
this wouldn't fix this scenario that also introduces an infinite
loop:
- T1 and T2 both have C open
- on T1, user folds C
[1] T1 writes 'C folded' in LS
- on T2, user folds C
[2] T2 writes 'C folded' in LS
- on T2, user unfolds C
[3] T2 writes 'C unfolded' in LS
[4] T2 detects 'C folded' in LS (from [1])
=> T2 writes 'C folded' in LS
[5] T1 detects 'C unfolded' in LS (from [3])
=> T1 writes 'C unfolded' in LS
[6] T2 detects 'C unfolded' in LS (from [5])
=> T2 writes 'C unfolded' in LS
[7] T1 detects 'C folded' in LS (from [4])
=> T1 writes 'C folded' in LS
[8] T2 detects 'C folded' in LS (from [7])
=> T2 writes 'C folded' in LS
[9] T1 detects 'C unfolded' in LS (from [6])
=> T1 writes 'C folded' in LS
etc...
This commit fixes the infinite loop issue:
- by turning local storage read during cross-tab communication into
local storage event read instead. This should prevent race
conditions based on read/write operations in local, since their
order is not guaranteed accros tabs.
- by isolating document chat window state to their own local
storage entry. This should prevent a tab from notifying a chat
window state that it didn't change, which may also result in
an infinite loop.
Some tests were adapted from the changes above. Also, some tests did
pass thanks to local storage being mocked by a ram storage: the
handler `_onStorage` should have been called, but it didn't because
it was registered on the actual local storage instead of the ram
storage. In order to make tests pass again, the following additional
changes were required:
- Cross-tab bus service now exports the unique tab ID with
`getTabId`.
- document thread entries in local storage now track the tab ID, so
that self-tab ignore their own local storage writes.
Task-Id 2034997
Closes#36177
Before this commit, some notifications may be lost while forwarding
them between browser tabs by means of the local storage (i.e. from
the master tab to slave tabs).
This happened when some slave tabs are in the background and are
throttled by the browser: the master tab writes twice in the local
storage (to notify slave tabs of new notifications), and slave tabs
drops the 1st notification. This is caused by the mismatch between
the new value in the local storage event and the actual value in the
local storage. For example:
```
t(0) - Master tab receives `message` notification;
t(1) - Master tab writes notifications (= `message`) in local
storage;
t(2) - Master tab receives `message_seen` notification;
t(3) - Master tab writes notifications (= `message_seen`) in
local storage;
t(4) - Slave tab detects new notifications (= `message`)
from local storage event, but drops it since it does not
match actual local storage value (= `message_seen`);
t(5) - Slave tab detects new notifications (= `message_seen`)
from local storage event, and handles it since it
matches actual local storage value (= `message_seen`);
=> Notifications received + handled:
- master tab: `message`, `message_seen`
- slave tab: `message_seen`
=> Slave tab lost "message" notification.
```
This commit fixes the issue by letting all tabs handle any local
storage events, regardless of the actual value in the local storage.
In the example above, this means the slave tab will not drop the
notification `message` at t(4).
Task-ID 2044231
Closes#36177
Backport from 12.0 to 11.0
When using barcode to change the customer to a customer with a different
pricelist than the pos default, the customer pricelist was not
automatically selected.
This is a fine-tuning on 5603b778f6
opw-2047070
closesodoo/odoo#36050
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When having a long systray (icons from different apps, mode debug,
multi-company...) the resize of the window can trigger a crash for apps
that have not too much top-level menus (e.g. Contacts).
This also happens when loading those apps.
Steps to reproduce (on an iPad, portrait):
* use a Runbot with all modules installed (12.0+)
* activate "debug mode"
* ensure that the menu/systray bar is quite full
* open the "Contacts" app
=> traceback with a "cannot call getBoundingClientRect of undefined"
error
The reason is that the resize's callback iterate over the systray/menu
items to find which one should be folded behind a "more" ("+") menu
item.
Sadly in some cases (combination of screen width, systray size, app's
number of menus) it can lead to a traceback.
This commit ensures that when looping for menu items, we don't try to
reach an non-existing item.
closesodoo/odoo#37329
X-original-commit: odoo/odoo@d7bae03299
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
SHA-1 is a cryptographic hash function that have weaknesses known since
2005, it has been deprecated by the NIST [1] about 10 years ago in 2011
and Google [2] have been able to perform a collision attack in 2017.
We use SHA-1 as filename for the attachments stored in our filestore.
Although practical attacks still requires quite a lot of computational
resources, it is time to prevent SHA-1 collisions on our filestore.
To prevent such attacks, when uploading a file that has the same SHA-1
as a stored file, we perform a SHA-2 computation on both files to verify
their signature. If their SHA-2 signature is different, an error is
raised.
We have selected the SHA-512 variant of the SHA-2 algorithm because on
64 bits platform, SHA-512 is the fastest SHA-2 variant, it is only ~1.5x
slower than SHA-1. [3]
We have not used SHA-3 because at the moment of writing, it is too slow
(~3x slower than SHA-1) [3] and it is not guaranteed to be available
with the Python 3.5 `hashlib` module.
[1]: https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions
[2]: https://shattered.io/
[3]: http://bench.cr.yp.to/results-hash.html
[4]: http://www.commitstrip.com/en/2017/02/27/the-sha-1-alternative/closesodoo/odoo#36430
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
SHA-1 is a cryptographic hash function that have weaknesses known since
2005, it has been deprecated by the NIST [1] about 10 years ago in 2011
and Google [2] have been able to perform a collision attack in 2017.
We use SHA-1 in order to generate unique URL for resources that can be
cached by the browser: assets bundle, translations, qweb templates and
qweb images.
Although practical attacks still requires quite a lot of computational
resources, it is time to upgrade SHA-1 to SHA-2.
We have selected the SHA-512/256 variant of the SHA-2 algorithm as
replacement for SHA-1 for the following reasons:
* On 64 bits platform, SHA-512 is the fastest SHA-2 variant, it is only
~1.5x slower than SHA-1. [3]
* Keeping only the 256 foremost bits protects against both collision
attacks and length extension attacks.
* The hexadecimal digest is only 24 chars longer than SHA-1 which is
nice to have somewhat short URLs.
We have not used SHA-3 because:
* At the moment of writing, it is too slow (~3x slower than SHA-1) [3]
* It is not guaranteed to be available with the Python 3.5 `hashlib`
module.
* One of the author of SHA-3 is Belgian.
[1] https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions
[2] https://shattered.io/
[3] http://bench.cr.yp.to/results-hash.html
[4] http://www.commitstrip.com/en/2017/02/27/the-sha-1-alternative/
`openerp` module/addons imports has been deprecated in v13 by 7c47eb1
for removal in v14.
If you were still using the removed aliases, please substitute all
`import openerp` by `import odoo` and `import openerp.addons` by
`import odoo.addons`.
If you were still using the removed `ad_paths` proxy, please use the
python standard `odoo.addons.__path__`.
closesodoo/odoo#37007
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
[PEP-594] is deprecating the `imp` module, that module is used in
`module.py` in order to dynamically import addons using any of the
`odoo.addons` or `openerp.addons` import anchor.
We are deprecating `openerp` module/addons imports in v13 in order to
remove the support in v14 and greatly simplify how modules/addons are
loaded. If you are still using the old `import openerp` or `import
openerp.addons`, `import odoo` and `import odoo.addons` are drop-in
replacements.
The `odoo.modules.module.ad_paths` addon paths list has been deprecated
too. The list is now accessible on `odoo.addons.__path__` where they
are now directly loaded [2].
See also:
[PEP-594]: https://python.org/dev/peps/pep-0594/
[2]: https://packaging.python.org/guides/packaging-namespace-packages/closesodoo/odoo#36597
Task: 2003936
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
[PEP 594] is going to depreciate the legacy `email.message.Message` API
and its related modules: `email.(charset|header|mime|utils)`.
The new `email.message.EmailMessage` API exposes a much easier interface
to create multiparted emails [1], is capable of doing all the necessary
headers value conversion (RFCs [2045], [2047], [2049]) [2] and get/set
different flavor of payload (text/bytes) in a straightforward way [3].
All headers are structured in a way to support python native types, i.e.
the `Date` header supports `datetime.datetime` objects and automatically
performs the required formatting. The same goes for multi-valued headers
like the `To` header, one can directly set a python list of values, it
will be automatically be formatted according to the RFCs.
The dedicated encoding and decoding functions are no more needed thus
has been removed has part of the refactor. FTR, [RFC2231] is an update
of [RFC2047] and based on tests we've just conducted, both GMail and
Thunderbird now support RFC2231 encoding just fine in all headers:
attachments names, From, etc.
[1]: http://docs.python.org/3/library/email.message.html
[2]: http://docs.python.org/3/library/email.headerregistry.html
[3]: http://docs.python.org/3/library/email.contentmanager.html
[2045]: https://tools.ietf.org/html/rfc2045
[2047]: https://tools.ietf.org/html/rfc2047
[2049]: https://tools.ietf.org/html/rfc2049
[2231]: https://tools.ietf.org/html/rfc2231closesodoo/odoo#35929
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
[PEP 594] is going to depreciate the legacy `email.message.Message` API
and its related modules. Among them the `email.utils.formataddr`
function, this function takes a `(name, email)` pair and returns a
string value suitable for From, To and Cc headers.
The stdlib function is capable of handling several character encoding
and two binary-to-ascii encoding. Odoo only uses `utf-8` which is
compatible with the base64 b2a encoding. The re-implementation of that
function has been simplified to only support base64-ed utf-8 and ascii.
[PEP 594]: https://www.python.org/dev/peps/pep-0594/\#email-lagacy-api
[PEP 594][1] is going to depreciate legacy `email.message.Message` API in
PY3.8 in favor `email.message.EmailMessage`.
All `email.message_from_x` constructor functions take an optional
`policy` argument. The policy can either be `policy.compat32` to
generate an `email.message.Message` instance, either be `policy.SMTP`
to generate an `email.message.EmailMessage` instance.
The [current][2] default policy is `policy.compat32` but will change in
a future version of python. It is recommended to always specify the
policy.
[1]: https://www.python.org/dev/peps/pep-0594/#email-legacy-api
[2] https://docs.python.org/3.7/library/email.parser.html#email.parser.BytesParser
[PEP 594] is going deprecates the `imp` standard modules in
PY3.8 in order to completely remove them in PY3.10.
The `imp` module provides the `new_module` function. It returns a new
module created solely using its name. The `types.ModuleName` is a
drop-in replacement.
Task: 2003936
[PEP 594]: https://www.python.org/dev/peps/pep-0594/\#impclosesodoo/odoo#36463
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Christophe Simonis