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>
If time off type is in hours, I want to have hours as unit in the summary
(upper my personnal calendar).
closesodoo/odoo#36421
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this rev., classNames 'oe_read_only' (only display in
readonly mode) and 'oe_edit_only' (only display in edit mode)
didn't work in x2m lists inside form views (only the cells in the
tbody were hidden, but not the header). This rev. makes this work.
Task 1949618
closesodoo/odoo#36117
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Werkzeug 0.15 modified ProxyFix such that by default it only forwards
the REMOTE_ADDR when enabled, whereas before 0.15 it would also
forward scheme and host. This breaks proxied odoo as the base url
becomes incorrect (cf #34412).
Use properly configured ProxyFix when running with werkzeug 0.15, old
configuration otherwise.
Closes#35085closesodoo/odoo#36212
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When uploading an attachment from a chat window, the label
"Uploading..." was not visible. This comes from attachment preview
being too small, thus cutting entirely the filename and the upload
progress bar.
This commit fixes the issue by increasing the size of attachment
previews in chat window, so that it takes 50% width. It also provides
more space for labels on attachment preview while uploading, by
removing the right padding for the animated "unlink" feature that
works only for uploaded attachments anyway.
Note that this commit does not entirely solve the issue: half the
width of a chat window being enough to display the icon, the file
extension, and sometimes the label "Uploading..." completely. The
width of the icon and text extension combined is always the same,
but the label "Uploading..." changes with the locale. The extra space
from the padding removal makes this label fully visible in English,
but not necessarily in other languages. The proper fix requires
re-designing the style of attachment preview, which will be done in
master.
Task-Id: 1978640
closesodoo/odoo#33638
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
- Create a new tax, using the 'Python Code' tax computation
- In 'Applicable Code' field, use a field only available on the
`product.product` model (e.g. `product.code`)
- Attach this new tax to a product that is available in the eCommerce
- Access the eCommerce, search for the product if not displayed.
The template `website_sale.products_item` crashes at rendering because
`code` is not available on a `product.template`.
`product` is supposed to be a `product.product` recordset. However, the
method `_get_combination_info` of `sale` is made in such a way that we
can fetch the information of a template, not a product. Utlimately,
methods `compute_all` and `_compute_amount` are called with the wrong
object.
We fall back on the first variant in this case.
opw-2056722
closesodoo/odoo#36134
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a COA is installed being loaded for current company, the
translations of taxes, account name, ... (in l10n_be, l10n_ca, l10n_ch,
l10n_sa) are copied from the templates to the accounting records.
This is done in `post_init_hook` which is correct since then
translations are available to be copied.
But when an accounting localization is already installed and we set it
to a company, the translations are not copied.
eg. install l10n_be for company1: accounts name are translated in
french and dutch, set company2 to belgian accounting: only original
language is available.
With this changeset, the translation copy is also performed when an
accounting localization is loaded for a company after it has been
installed.
note: if we install language for first times after setting accounting
localizations, chart of account are translated in that language.
opw-2047013
closes#35985
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
usecase to reproduce:
- Set the warehouse with manufacturing 3 steps
- Create a BoM with a Components that use a Sub BoM
- Set Both product MTO + Manufacture
- Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.
It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO. So the solution would be to
add a condition to _assign_picking and don't merge moves if they come
from different MO, at this point the field created_production_id would
fit. However this solution is not robust if a customer creates a
new rule that add a 4th steps to the production process.
opw-2055688
closesodoo/odoo#35915
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Andrea Grazioso (agr-odoo) <agr@odoo.com>
Let's assume an action with 'create': 0 in the context, and a non
inline subview in the form view. Before this rev., the 'create': 0
was applied to both the form view and the subview.
This rev. applies the same logic as what the server does for inline
subviews: the rule is applied to the subview iff its model is the
same as the one of the form view (with key 'base_model_name' set
in the context).
Task 2035653
closesodoo/odoo#36109
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
- In stock, create a new transfer (stock.picking);
- Enter a source location ('A'), a destination location ('B') and an
operation type;
- Add product (whit out packaging);
- Change the source ('C') and the destination ('D') location;
- Hit save.
Before this commit, when opening the details of the move, the source and
destination location where setted as 'A' and 'B', the locations that
were setted before adding the product.
Now, the source and destination location of the move line are 'C' and
'D', the current location at the time we save the picking.
opw-2058240
closesodoo/odoo#36089
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Display your website in Right To Left
Go see the phone number of the company
Make that number in the form
```
123[space]456[space]789
```
Before this commit, the blocks of that number were inverted
(intra-group order did not change)
Leaving us with
```
789[space]456[space]123
```
After this commit, we introduce a little class to force Left To Right
display
OPW 2059917
closesodoo/odoo#36115
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Product category: FIFO (real_time) / Automatic
- Product: storable, nvoicing based on delivered quantity, FIFO category
- Receive 3 units @ 30
- Create and confirm a SO for 1 unit
- Deliver requested qty to customer
- Unlock the picking, update the qty done to 3, lock.
- Invoice delivered qty
In the journal entry of the customer invoice, the COGS entry is 180
instead of 90.
The root cause of this is the incorrect price unit on the modified stock
move, which equals to -60 instead of -30.
The price unit should compute the weigthed average of the already
delivered quantity with the extra quantity.
opw-2047719
closesodoo/odoo#36065
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the code that was supposed to close the dropdown in the
navbar when scrolling was not working anymore.
Indeed, it would removes the `show` class from the `nav-item dropdown`
(dropdown menu entry) but not from the `dropdown-menu` (dropdown content).
Fixes#35320closesodoo/odoo#36069
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When pasting from clipboard, the editor filters the nodes to paste.
Among other things, it removes `meta`, `style` and `script` nodes. It
did so using `jQuery`'s `not` method but that method has a side effect:
it removes text and comment nodes as well if you pass it a `jQuery`
selector. As a result, unwrapped text nodes could not be pasted. This
commit fixes that by using `each` to remove the targeted nodes instead
of using `not`.
closesodoo/odoo#36012
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since implementation of repartition lines on tax in accounting, the
amount on the tax is not always the effective amount to apply on price
of a product. You can have a tax with amount of 20% for example, and two
repartition lines of 100% and -100%, that will lead to have to apply 0%
on the tax.
So we are computing the effective amount on the tax by multiplying the
amount of tax by the sum of repartition lines factor.
closesodoo/odoo#36140
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
1) Suppose a tax of 21% intracomm +100%, -100% applied on 100.0.
The computed price_excluded was 121.0 instead of 100.0 because the
assumption was made the sum of repartition lines factor was always 100.0%.
After this fix, the amounts are always multiplied by the sum of repartition lines factor
in order to reflect correctly the impact of each repartition lines.
2) The rounding is now working for any kind of repartition lines and the consistency
of tax amount regarding the repartition lines is always ensured.
See use cases described by the tests for more details.
closesodoo/odoo#36082
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, a field selection which was required
did not have an empty option
ref: 4dfabb8f7a
This is fine, but overlooked the fact that modules can modify
the required attribute, or even views can do it
So, we may end up in a situation where the field is required but set to false
This configuration is problematic, at least for the timezone selection field
(see OPW)
After this commit, the empty option is just not visible
note that `disabled = True` would not work because val is not accessible
Because of commits:
- 4dfabb8f7a for the selection feature
- d77ce4c2a9 overriding the required attribute of tz in res.user form
OPW 2057913
closesodoo/odoo#35989
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
It is an important information as it is different that the domain.
The users computed with the domain are added to the list, never removed.
closesodoo/odoo#36033
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If a goal definition with a target goal of 0 and "higher the better",
instead of dividing by 0, set a progress of 0% (it is not possible to
compute the progress)
Task id: 2057898
It should be possible to open the view form of a goal from the
"Related Goals" action. This is an easy way to set progress for manual
goals.
Task id: 2057898
Alexandre Kühn