When displaying a video, with the browser window at a certain size, or
resizing it (or opening developer tools) we could the following error:
"ResizeObserver loop limit exceeded"
This can be reproduced in chromium just with this JS code:
window.onerror = function(e){ console.log(e); };
document.body.innerHTML = '<div><video controls src="v.webm"/>';
The issue only happen if:
- the video server does not support HTTP range requests
- the controls are displayed on the video
- browser size is in problematic size/resized to problematic size
And the error is raised in window.onerror but not displayed in the
developer console.
With this change, we ignore these errors until fixed in chromium.
chromium bug tracker: https://crbug.com/809574
backport of 12.0 535da9e (in pr #30239) since video loader was in 11.0
opw-1928512
closes#32983
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Set a product P to average valuation, real time
- Create a PO for 1 unit @ 100, validate the picking
- Create a PO for 1 unit @ 0 (e.g. you receive a free product)
You cannot validate the picking because of the message 'The cost of P is
currently equal to 0...'
This error message is historical, to prevent users from an incorrect
configuration.
Since we still want to prevent misconfiguration, but support the
mentioned use case, we introduce an `ir._config_parameter` for people
who 'know what they are doing'.
opw-1962249
closesodoo/odoo#32550
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
closesodoo/odoo#32951
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On the portal, in "/my/projects/x" it is possible to send messages in the
"Message and communication history" section. Those messages are attached
to the project model but it is not possible to access those messages
from the backend. The chatter on the project model is just a dummy
chatter with no message/thread capacities.
As messages are not accessible from the backend, the frontend section is
pretty useless. The section is no more present on v12 either.
opw-1970586
closesodoo/odoo#32952
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a new product, but don't save it just yet
give it a name,
Add some packagings
Save
Before this commit:
- the form to create the packaging had a mandatory product_id field
which is useless in a x2m context (fixed in v11.5 with a6557a2306)
- the packages disappeared after save
This was because at template creation, all "real" fields that are on
its variants must be manually set after the creation, including packaging_ids
OPW 1970589
closesodoo/odoo#32925
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The use case is a bit complicated so brace yourself:
OFFLINE
- Make an order, invoiceble with a partner
- Pay it, validate it
- An error popup is shown
=> Before this commit, the payment screen was still on
=> After this commit, the receipt screen is shown proposing to
print the invoice
ONLINE
- Make another order, non invoiceable.
- Pay it, validate it
- Both orders are now pushed to the server
=> Before this commit, it was still possible to click on "Back"
and add some products. The result of this will be that the order in DB (server)
would not have the newly added product, whereas the ticket would state that there was a new product
=> After this commit, we basically block the edition of a paid and validated order, even if the invoice
printing failed
OPW 1971028
closesodoo/odoo#32885
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Create 2 companies A & B
- Set the superuser in company A
- Create a POS and a user in company B
- Create a product P. The 'Inventory Valuation' must be different in
both companies:
Company A: Periodic (manual)
Company B: Perpetual (automated)
- Connect with the user in company B
- Sell the product P, select a customer and print the invoice
The COGS journal entry is not posted.
This is because `action_invoice_open` is called as `sudo()`, but
ultimately `product.valuation` is called in:
https://github.com/odoo/odoo/blob/0cce154794c8de945805d9b9acc4c33e5258191a/addons/stock_account/models/product.py#L325
`product.valuation` is computed based on the property field
`property_valuation`, which is therefore company-dependant.
Closes#32803
opw-1961861
closesodoo/odoo#32903
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The calendar should send to server:
- for an all day event (all_day field on view): the date in UTC (ie. if
we are on 22 august 2018 on UTC+2, not send 21 august 2018 22:00)
- for a datetime event not all day: the UTC datetime corresponding to
UTC (for 03:25 with UTC+5 timezone, we send 22:25 the day before)
- for a date event: the date in UTC (ie. same as all day)
The current code was alright for datetime, but there was a missing case
if the start_date was a Date field (eg. project task calendar view uses
a date_deadline Date field) and not a Datetime field.
This changeset apply the same behavior as an all_day event to a calendar
with a start date that is a Date field.
Note: the issue happen since 11.0's 03d74f4 (26th march 2019) that
solved a similar case but for datetime (a datetime event at 8:00 with
timezone UTC+9 would be moved the previous day when drag and dropped on
the month view).
opw-1969876
opw-1971106
opw-1971019
closes#32796
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Create product A (type='product',tracking='lot')
- Create product B (type='product',tracking='lot')
- Create product Z(type='consu',tracking='none')
- Create BoM for product Z with product A as component and product B
as sub_product (i.e. By product) + create any routing (i.e. 1 operation).
- Create an MO for product z, plan it, process the given work order,
input the serial/lot for the components and byproducts...
Bug:
Two lines for product B were displayed in the finished_move_line_ids of the MO
This bug occured in enterprise because the function _create_checks defined on model
'mrp.workorder' creates the quality checks that create the finished_move_line_ids
for the by_product tracked by lot or by serial number (in fuction _update_active_move_line
defined on model 'mrp.workorder').
So the finished_move_line_ids were created two times with the ones created in fuction record_production
defined on model 'mrp.workorder' in community.
Co-authored-by: amoyaux <arm@odoo.com>
opw:1963163
closesodoo/odoo#32779
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit 52c89ade added a test in v11.
Commit 1e0a92c9 forward-ported that commit to v12, that already had a test.
As a result, the class TestDropship was defined twice.
It follows that the first test was not executed.
opw 1957701
closesodoo/odoo#32792
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Currently in some screen sizes and themes, layout for author card
is broken (see iPad Pro for example).
This commit fixes the issue by improving the card layout, making
it uniform for all devices.
task-1938637
closesodoo/odoo#32753
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Task 1966321
There are 3 different ways to configure a bank account and it’s confusing:
- config bar wizard
- journal
- bank account (Menu: Configuration/Accounting/Bank accounts)
We want to use the wizard for creation and the journal for configuration, so removing the bank account (Menu: Configuration/Accounting/Bank accounts) view).
closesodoo/odoo#32590
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The link and media tooltips were not taking Summernote's `tooltip`
option into account. That option ensures that tooltips are disabled if
the option is off (which is for instance the case on mobile).
This fix ensures that these tooltips are disabled when the option is
set to `false`.
It also disables tooltips in the keyboard tests. They are not relevant
to the keyboard tests and occasionally caused the DOM to not be properly
cleaned after the tests were run (most likely due to their 2000ms
`setTimeout`).
Usecase to reproduce:
- Create a MO for drawer with SEC assemble BoM
- Plan the workorders
- In the first workorder record the production without specify a lot or
serial number.
- Second workorder, register a new serial for finished product and
record production.
A UserError that prevent to use a new serial number is raised. It
happens because the system check the remaing quantity on other
workorders + the quantity already produced for the current lot. In this
case the remaining quantity for the first workorder is 0 and the current
lot was not produced. However it should count the lines without lot as
a 'remaining quantity' since they could be used later to create a new
serial or lot number.
This commit register the lines without lot and use them to raise the
UserError and compute the allowed lot domain for finished lots.
closesodoo/odoo#32632
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- set the tax adjustment menu to be seen only in debug mode
- add a new reconcile model for suspense account
- change chart_template.py to consider 'to_check' field when loading
the COA
closesodoo/odoo#32780
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This commit ticks the 'Create component lot' checkbox for
the demo manufacturing operation type of first warehouse.
This change will leave the default behaviour for all warehouses
but tests with demo data are now more straightforward and do
not demand too much parametrization
Task : 1970450
closesodoo/odoo#32772
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Commit 84ae731d5d used 'self.code' in a method
called by a multi one. As 'self.code' expect a singleton, the transaction
raise an error in case of multiple records into the recordset
This commit calls the method into a loop on 'self and change its signature
to pass 'code' and be sure its a non multi one
Javascript is responsible of showing the menu, potentially with some
parts regrouped in an extra dropdown, on page load (this is what we
call the "autohide" feature). This was done on both the menu and the
affix menu. It worked on the affix menu because the affix menu widget
was initialized before (by luck: alphabetical order).
Since the jQuery 3 update https://github.com/odoo/odoo/commit/bb004e3d7f3df5a5af6b2e994ec0af79e2da890f
deferred are always delayed (even if their resolve condition is met on
creation). This made the animations to be initialized in the same order
as before but their 'start' method to be delayed (as the willStart was
delayed). So what happened before was:
1) Find menus to enable affix
2) Enable affix on found menus (duplicate the menus to do that)
3) Find menus to enable autohide
4) Enable autohide on found menus (both the menu and the duplicated one
were found)
And since jQuery 3:
1) Find menus to enable affix
2) Find menus to enable autohide
3) Enable affix on found menus (duplicate the menus to do that)
4) Enable autohide on found menus (the duplicated one was not found at
step 2 since it did not exist yet)
In fact, widget starting should never have relied on alphabetical order.
The fix only consists of starting widgets on the duplicated menu once it
is ready. This is what this commit does.
However, doing this revealed another bug: if the widgets are started
only for a DOM portion like a '.a' element, a widget with a multiple
parts selector like a '.a .b' selector will not be considered, as
searching inside a '.a' element will not allow to match elements with
a selector containing a '.a'. This is in fact not really a "bug" but a
limitation, so unless we get problems because of this in stable
versions, we can only "fix" this for the current saas. This is fixed
thanks to `dom.cssFind` which already existed. This commit however
improves it to try making it more efficient.
closesodoo/odoo#32465
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Using "async" in the event parameter is not enough, you have to
return correct promises in the event handlers.
closesodoo/odoo#32479
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The closure overrides the arguments, which makes it impossible to
recover the attachment_ids hence sending null python code which then
breaks.
closesodoo/odoo#32810
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Have a fieldHTML as:
```
<p>
Some text
<br>
<br>
More text
</p>
```
In the Html field widget, place your cursor before the "M"
press Enter to insert a newline
Before this commit "Some text" and the subsequent `<br>` were deleted
This was because the code:
- split the original `<p>` into two
( i.e. it became
```
<p>
Some text
<br>
<br>
</p>
<p>
More text
</p>
```
)
- took the last child of the first p, which is a text then fell back to the first p
- replaced the whole p with <br>
After this commit, the original p is still split, but we append the br to it instead of replacing it
closesodoo/odoo#32777
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
`reserved_availability` is a computed field of a move depending on its
move lines. We access this field at each iteration of the loop over the
moves to assign and then we create a new move line for it. This triggers
an invalidation of this field, The next iteration will again access this
field and prefetch it for all the next records.
We read the field out of the loop and don't access it again to prevent
these prefetch/invalidation issues.
Confirmation of a PO of ~800 lines goes from 5 minutes to 1 minute.
opw-1953398
closesodoo/odoo#32774
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Create a consumable or storable final product A with invoicing policy
in "delivered quantity"
- Create two storable products B and C
- Create a BOM kit for A with 1 B and 1 C
- Create a SO with 5 qty of A and confirm it
- Deliver 3 B and 2 C and either on "No backorder" or "With backorder"
Bug:
The delivered_qty on the SO line is of course not automatically updated
(as in this case, a right value is not computable) but the delivered_qty
was not updatable manually and then it was possible to invoice the SO.
Co-authored-by: nim-odoo <nim@odoo.com>
opw:1966170
closesodoo/odoo#32733
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Make sure the move, journal and the accounts will share the same company to prevent undeterministic error in runbot ('Cannot create moves for different companies.')
closesodoo/odoo#32759
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce the bug:
- Create two fiscal postions fp1 and fp2
- Create a customer C with fp1
- Create a SO for C and set fp2
- Create an invoice for the SO
BUG:
The fiscal position of the SO was set to False.
Now the fiscal position of the SO is kept when creating an invoice
from a SO.
opw:1963910
closesodoo/odoo#32713
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit 240d191ba3 introduced the field
company_id on model stock.move.line and a python constraint that check
if the company is the same on the move line and on the related move.
In order to avoid performance issue, this commit replace the constraint
by a 'related' parameter on the company field.
As the company_id is not editable we suppose this change will not introduced
unwanted errors
Task : 1970012
closesodoo/odoo#32738
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
It's quite common that the `$().text()` method returns lots of random whitespaces at the beginning and end of the string. They're pretty unpredictable (extension views can add or remove them) and invisible to the end user.
This code chunk should allow to select an `<option>` based on its raw text content, but most of them will just fail without this patch. And most chances are that current ones just work equally with this patch.
This will make frontend tours more pleasant to write.
closesodoo/odoo#32718
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The check on the ordered quantity should not apply to services.
opw-1981332
closesodoo/odoo#33138
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The UTM graph data in Website > Dasboard > Analytics is not getting
properly filtered on the basis of values of date_from and date_to on
website_sale dashboard.
The field confirmation date which is of type datetime while date_from
and date_to are of date string in local browser timezone.
Hence date_domain is not perfect as shown below on local date 29th april
2019, we would send:
('confirmation_date', '>=', '2019-04-22'),
('confirmation_date', '<=', '2019-04-29')
But in reality we could want a from midnight of week before the current
UTC day, and to current UTC now or 23:59:59 of current UTC day.
This way, the data sent back matches more what is expected, instead of
the preceding domain, we would then have the following:
- if UTC now corresponding to local now is on '2019-04-29'
('confirmation_date', '>=', '2019-04-22 00:00:00'),
('confirmation_date', '<=', '2019-04-29 23:59:59')
- if UTC now corresponding to local now is on '2019-04-28':
('confirmation_date', '>=', '2019-04-21 00:00:00'),
('confirmation_date', '<=', '2019-04-28 23:59:59')
- if UTC now corresponding to local now is on '2019-04-30':
('confirmation_date', '>=', '2019-04-23 00:00:00'),
('confirmation_date', '<=', '2019-04-30 23:59:59')
And each one will be displayed as days 22 up to 29 in line chart (with
local today 29 being the last day of the chart and contening orders of
the current UTC day).
With these change in the UTM pie chart:
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to before yesterday UTC
- a local date that is the same as an UTC date => we see the sale from
up to today UTC instead of yesterday UTC
And in the line chart (that already had half of the fix in f6fc7c2319):
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to yesterday UTC
- a local date that is after a UTC date => we see the sales of current
UTC day + range of days (eg. for a week 7) instead of current UTC day +
range of days minus 1 (eg. for a week 6).
opw-1971539
closes#33041
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
Having 4 products and 3 BoMs:
BoM 1:
product = Finished
quantity = 100 units
- Semi-Finished 10 units
BoM 2:
product = Semi-Finished
quantity = 10 units
- Assembly 10 units
BoM 3:
product = Assembly
quantity = 10 units
- Raw Material 10 units (product.product 5$/unit)
Before this commit, the price for 100 units of Finished product was
500$, which is wrong. The price was calculated using 100 units of
Semi-Finished product and not 10 units as it should be.
Now, the price is 50$
opw-1973347
closesodoo/odoo#33115
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Use task-#xxx is wrong since it will refer to an unexising or wrong hash
of github.
closesodoo/odoo#33121
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The action_subtask method adds 'default_parent_id' to the context.
If the creation or edition of a subtasks triggers an email creation,
(e.g. if there is an automated action 'send email')
the default 'default_parent_id' is still in the context.
Therefore, it tries to create the email with an arbitrary foreign key
(since it is an existing record on the project.task model), or crashes.
Similar to 816f3861.
opw 1978498
closesodoo/odoo#33111
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Commit 42530b02fe was fixing a bug in reports that were using the standard
bootstrap fonts instead of the changes we made in $font-family-sans-serif
To solve this, 42530b02fe replicated the change in the file
web_editor/static/src/scss/bootstrap_overridden.scss
which is imported in report_assets_common **before** web._assets_bootstrap
This was solving the issue for the report but had also the side-effect of
changing body font-family in enterprise as the bootstrap_overridden.scss file
is also used in web_editor._assets_backend_helpers and
web_editor._assets_frontend_helpers
42530b02fe had effect only on enterprise where the desired font is Roboto/Noto
Create a new bootstrap_overridden (6th of the name) file only for report
closesodoo/odoo#32902
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If there is no rating for user, it will throw error while publishing channel.
This commit check if there is any rating for particular user or not.
Introduced by ce20c29f82
opw-1966384
closesodoo/odoo#32553
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, a domain that had been written in order to be
JSON parsable, would trigger a JS crash when activated in the UI
It happens when adding custom filters through the edition of the search view with studio
This was because, Odoo developers write, in the XML of a search view
domains python style: `[('field', '=', 'value')]`
When parsing the view in JS, this doesn't get altered by `xml_to_json`
Then, the search view code evaluates it python style
This commit considers that behavior fortunate, but not really clear or conceptually correct
But, when customizing a search view with studio, the domain is written by the code, in JS
JSON parsable format `[["field", "=", "value"]]`
This should be supported too, as so many customizations may have been done before hand
After this commit, both expressions are supported by the filters menu
OPW 1957297, 1960732, 1965649 (at least)
closesodoo/odoo#32690
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Create a calendar meeting using Mark Demo. In the options of the event,
set the meeting as "Show Time as" = "Free". Using the admin user, send a
digest (KPI Digest module, technical > emails > digest email > send
now). It raises an User Error because the template cannot be rendered.
The problem is due to the way the "Show Time as" is implemented, the
"Free" option is used to not show the meeting in the different calendar
views. The events are hidden thanks to a record rule "Hide Private
Meetings".
Each digest is sent using the context of each subscripted user and not
the SuperUser ID 1. The call to `search_count` on `mail.message` calls
the dedicated `_search` of `mail.message` and ultimately end up in the
overriden `_find_allowed_model_wise` method of message in calendar.
That method does a browse of all the record ids containing new
messages in their chatter, but fail with an access error due to the
above record rule. Because it fails, the `kpi_mail_message_total_value`
compute fails and the field is missing when rendering the template.
Using `search` instead of `browse` ensures records unavailable due to a
record rule are filtered out.
opw-1966664
closesodoo/odoo#32735
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before on rubot
odoo.addons.sale_mrp.tests.test_sale_mrp_flow tested in 97.08s, 117272 queries
After on runbot
odoo.addons.sale_mrp.tests.test_sale_mrp_flow tested in 50.84s, 61903 queries
closesodoo/odoo#32537
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before on runbot
odoo.addons.mrp_subcontracting.tests.test_subcontracting tested in 11.40s, 14213 queries
After on runbot
odoo.addons.mrp_subcontracting.tests.test_subcontracting tested in 7.95s, 9863 queries
Nicolas Lempereur