Steps to reproduce the bug:
- Go to any field Date
- Enter wrong date
Bug:
A traceback was raised.
Now a warning is raised and the wrong value is removed.
opw:1974747
closesodoo/odoo#33362
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit and since 2f7c03d9ca, the admin user has not ID=1
anymore.
Thus, some old condition were not doing what they were expected to.
Firstly, the admin was not considered as such on the forum, and if its karma
points were not high enough, it would not be possible to do anything for the
admin. Note that it was fixed in saas-12.1 with 1dac413130
Secondly, some _search functions would not return a truthy value anymore.
closesodoo/odoo#33359
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Commit 98ee15977a made the Stock Interim accounts reconciliable,
and introduced auto-reconciliation of related entries. This has the
advantage to clean-up entries in these accounts. However, since these
accounts are reconciliable, the entries will show up in the manual
reconciliation widget (expected) and the bank reconciliation widget (not
expected).
There are 2 cases where it causes issues:
- after migration from v11, the entries were not reconciliced. Although
this will be fixed in the near future, it is too late for already
migrated databases
- using MRP. A list of components i costing Xi might be used to create a
finished product of cost Y != sum(Xi). Indeed, the routing cost has to
be taken into account. In this case, the entries are not fully
reconcilied.
The result is that the bank reconciliation widget ends up with an
growing number of unreconcilied lines, and in the end making it
impossible to use.
In order to work around the issue, we prevent any account used as a
stock interim account to be included in the bank reconciliation widget.
For performance reasons, we directly search the `ir.property` table for
the corresponding accounts instead of filtering AML thanks to
`excluded_ids`.
Closes#32611
opw-1963025
opw-1967462
closesodoo/odoo#32957
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When using `sales_team.team_sales_department` as fall back default
team, last condition that checks if such team can be default was
incorrect, because `active` value check was mixed with lead type check.
In other words: True or False and False => True
But intention is: (True or False) and False => False
opw 1997715
closesodoo/odoo#33316
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The field session_ids is fetched from the server for what seems to be no
good reason at all; for database with a lot of sessions (test case with
40k+ sessions), this can lead to an extremely slow dashboard.
closesodoo/odoo#33303
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 2 companies A & B
- For each company, create a website linked to a different URL and
activate 'Free sign up' and 'Specific User Account'.
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account
The user is created in company A (the company of the user template)
instead of company B (the company of the website).
We set the company of the user based on the company of the website.
opw-1962197
closesodoo/odoo#32823
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 2 companies A & B
- For each company, create a website linked to a specific URL
- As a public user, visit website of B
- Buy a product, register your address
The partner is in company A (the company of the superuser) instead of
company B (the company of the website).
opw-1962197
closesodoo/odoo#32822
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
We remove the remaining comparisons to use the precision rounding of the UoM.
opw 1969888
closes#32707closes#32745closesodoo/odoo#32844
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- When changing the `holiday_type` of a leave allocation while having an
employee set and if this `holiday_type` has as its value `employee`
the field `employee_id` is set to False.
This is not the intended behavior. We want the field `employee_id`
to be filled if the `holiday_type` is set to `employee`.
closesodoo/odoo#32886
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Backport of 7bc53ac30e.
Assume an editable list view with a date(time) widget, click to
edit a line, focus the date field (the datepicker opens), press
ESC: there is a crash in the lib, and the datepicker remains open
forever.
This fix is twofold:
- we added a check in the lib to prevent it from crashing (it is
easily reproducible: it crashes when an opened datepicker is
removed from the DOM).
- we added an event handler of ESC keydown event to hide the
datepicker before the field is removed from the DOM.
closesodoo/odoo#32647
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Create a SO with two lines (sol_1, sol_2) selling a given service.
On the corresponding Project/Task, set the partner so that the sale_line_id
can be chosen to one of the lines.
Add an AAL with x hours, save.
This updates the delivered quantity (x) on sol_1.
Edit, change the sale_line_id to the second one:
it updates the delivered quantity on sol_2 (to x) but not on sol_1.
Has a result, the delivered quantity has been doubled.
The issue is that the quantities are only recomputed on the SOL that we write;
instead they should be recomputed on the old one and the new one.
We base ourselves on 371a92fb which solved a similar bug to add the recompute on
both lines.
opw 1959509
11.0-opw1959509-sltmsht-len
closesodoo/odoo#32820
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Fine tuning of ac31252d54
Do not pre-filter on canceled entries since they are used a few lines
below.
opw-1964459
closesodoo/odoo#32835
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have a SO with a quotation template and some optional products set
Display it on the portal
On an optional product, click on the cart icon
to add it to the SO
Modify the quantity of the optional product
Before this commit, the feature was barely working:
- the total price of the optional product did not change
- negative quantities were allowed
- there was no reaction when directly putting a number in the input
- when decrementing the quantity, it crashed
- untaxed and tax amounts were not dynamic
After this commit:
- the total price of the optional product changes as a function of the quantity input
- negative quantities are not allowed
- it is not possible to manually input the quantity with a keyboard
only +/- buttons are used to change the quantity
- decrementing the quantity works
- untaxed and tax amounts are dynamic
OPW 1947769
closesodoo/odoo#32715
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Commit 1da63f0ab0 removed the
uninstall_hook defined in sale/__init__.py but forgot to remove it from
the __manifest__.py, resulting in a traceback when uninstalling the
`sale` module.
closesodoo/odoo#32804
Signed-off-by: Raphael Collet (rco) <rco@openerp.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>
closesodoo/odoo#32805
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, when the PO was locked:
- the button create bill did not appear on the form view
- on the invoice form view, the field autocomplete did not mention the PO
After this commit, the button create bill is present, and the PO appears in
the auto-complete field of the Vendor bill
OPW 1970537
closesodoo/odoo#32794
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Commit 27d41ccb introduced record rules on resource.calendar.leaves.
However it gave no way to create, edit or delete a global rule.
We grant this right to the group_erp_manager, so that an admin can do it.
opw 1968376
closesodoo/odoo#32832
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
OPW-1967543 on non-trivial multi-level test BOM, MO creation goes from
30s to 13 on my system.
closesodoo/odoo#32819
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Install 'quality_mrp_workorder' without demo data
- Go to the General Settings
A warning is raised regarding the uninstallation of 'mrp_workorder'.
This is due to `_onchange_group_mrp_routings`, which assumes that the
installation of 'mrp_workorder' is only linked to the group
`group_mrp_routings`.
This is incorrect: `group_mrp_routings` might not be activated, but it
might be in the dependencies of another module. Therefore, we change the
logic: if we activate `group_mrp_routings`, we install 'mrp_workorder'.
If we deactivate `group_mrp_routings` we do not uninstall
'mrp_workorder' if it is already installed, since it might be required
by a dependancy.
opw-1970910
closesodoo/odoo#32811
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The base_setup.show_effect parameter is created at module installation (with
an external id) and is removed (and its external id) when the option
"Show Effect" is unchecked from the general setting.
When this option is checked again, the ir.config.parameter entry is recreated
but without an external id (as it is user-provided data, not from a data file).
When the module base_setup is updated, the record base_setup.show_effect is
recreated and the unicity constraint on ir.config.parameter is raised.
Set the record as forcecreate="False" to avoid recreating it when the module
is updated.
Anyway, if somebody uncheck the option, it is not expected to get it back when
the module is upgraded.
Fixesodoo/odoo#32806closesodoo/odoo#32808
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Set the company currency to USD, activate multi-currency
- Create a rate of 0.5 for EUR
- Create a purchase tax T:
Percentage: 10 %
Included in price
- Create a PO in EUR with the followind line
Quantity: 10.0
Price Unit: 1.0
Tax: T
- Validate the PO, receive the product
The journal entry is composed of 2 lines:
- debit: 18.18; amount currency: 10.0
- credit: 18.18; amount currency: -10.0
This is not correct: the amount currency should not include the tax.
In order to prevent this, we use the subtotal, and divide by the
normalized quantity (yeah, because it was also failing in case of multi
UoM, as one could have expected).
opw-1958287
closesodoo/odoo#32797
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fine tuning of commit b9e3c153, for the same use-case.
The route may not be passed in values, in which case the bug is still present.
There are two ways to go around that.
We could add the stock.rule in values, which contains the route.
The solution we adopt here is to use the sale_line_id field on the purchase line
If it is present, it was added through _prepare_purchase_order_line,
and thus we want to keep track of the origin.
opw 1957701
closesodoo/odoo#32683
Signed-off-by: Nans Lefebvre (len) <len@odoo.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#32791
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The depends value on picking weight and package_ids of picking are only
set on the move_line_ids, which lead to compute the value of the picking
weight only when move lines are created or deleted and not when a
package is set on a line, quantity done changed and/or unit of measure
changed.
To fix this issue, we've changed the depends, of thos computed fields.
closesodoo/odoo#33114
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Set the company currency in USD, activate multi-curency
- Create an invoice in EUR
- Create a payment in EUR for less than the invoice
- Open the payment matching => all amounts are in USD
- Create a write-off, reconcile
The write-off amount is incorrectly converted.
The write-off amount is sent in USD, but considered in EUR in the
server since the currency considered is the one of the line. However,
the currency in the widget is computed based on the account currency:
https://github.com/odoo/odoo/blob/b6f55dac5633d8ccb16568e0c85a5c32072e8846/addons/account/models/account_move.py#L654
Note that this is the opposite of commit 1806ea1859,
introduced in v9. Since the widget was refactored in v11, many changes
have been introduced, and we assume that this change is now justified.
opw-1907332
closesodoo/odoo#32723
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit d7a3f39d refactored hr views.
This broke the inheritance of the view in that module.
opw 1971570
closesodoo/odoo#32972
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The use case is similar to 084dbf9b8f, but
applied to pickings.
When the picking contains many stock move, the manual edition of the
quantitites is quite slow due to the `onchange` call. In the example of
the OPW with 300 stock moves, the modification of the done quantity
triggers an `onchange` which lasts about 1 second.
The reason is the same than in the mentioned commit: the `onchange` is
triggered on all lines in the case of an inline tree view, and there is
not much we can do to optimize the business logic.
Therefore, the solution is the same: add a stat button to access the
stock moves directly in a tree view instead, to avoid this `onchange`.
opw-1965248
closesodoo/odoo#33004
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 2 invoices for a customer:
Inv 1: 100
Inv 2: 200
- Register a partial payment of 80 on Inv 1
- Select both invoices and pay the remaining amount (220)
- Print the 'Payment Receipt'
The 'Amount Paid' for Inv 1 is 100, while it should be 20.
This is because the report doesn't take into account which part of the
payment was used in the corresponding invoice.
Closes#32755
opw-1970401
closesodoo/odoo#33012
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since commit 56645335b7
the subtype `gamification.mt_badge_granted` is not used anymore. Therefore
this method will never return anything.
However, it is very costly on performance, and it is run on every page of the
forum! The problematic performance point is that `needaction` is a computed
field, which implies all existing `mail.message` having the target subtype have
to be fetched to compute this field, which obviously does not scale well at all.
closesodoo/odoo#32861
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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>
Goffin Simon