The class modal-open on body tag allow to scroll on the modal content
which is useful if the content is taller than the window viewport.
When closing the modal, this class is removed but there may be another
modal open on which we will not be able to scroll to view
buttons/content if too big.
This commit check if a modal is still opened after closing an editor
modal and in the affirmative add back the modal-open class.
opw-674475
note : was already present in 8.0 with ec47493, it is also present for
web.Dialog (but the modal of the editor do not inherit from web.Dialog)
========
Purpose
========
POS : It is annoying process to put coin/bill value repeatedly in the cash register.
If user select cash control check box it should add default values.
In pos configuration the option cash control checkbox move to a new category
called Cash Control.
-When opening a POS session, when doing the cash control, it should already prefill
the modal with the defaults cash control values (Coin/Bill Value, Number of
Coins/Bills, Subtotal).
-When closing the POS session, the closing balance should just take the Coin/Bill
Value defaults values. The user has to type in the number of Coins/Bills manually).
Steps to reproduce:
-go to runbot 8.0 and connect
-go into human ressources/job positions
-pass into list view and click on the first item
-click on the url to open this record into the website (website_published)
-go back (back into the browser)
-you're now into the form view again and then next step is to click on the button
"next" to access the following record
-click on the url of website_published
Before the fix:
wrong record, this is the previous one that is into the href
After the fix:
correct record with the correct id into the href
Closes#11800
opw:675832
In the report "Invoice Analysis", the view under the report is grouping
lines by invoice and also by product on this invoice.
Thus, quantities in the pivot view are not the real quantity of invoice
lines, but of invoice lines with different products.
eg:
invoice a:
- line 1: product X
- line 2: product Y
- line 3: product X
in the report there would appear to only be 2 invoice line, whilst there
is in realy three (this information is accessible via "# of Lines").
closes#11954
opw-676651
Used case:
-Configure admin as multi-company user
-Create 2 fiscal positions (one for company "Odoo BE" and one for company "Odoo US")
-Set admin on company "Odoo BE"
-On supplier (Asustek) configure fiscal position Odoo BE
-Set admin on company "Odoo US"
-On supplier (Asustek) configure fiscal position Odoo US
-Configure a product (Laptop E5023) with:
*route "Buy"
*supplier (Asustek) without company
*reordering rules (min qty: 20, max qty: 40)
-Set admin on company "Odoo BE"
-Run scheduler via the cron
Behavior before the fix:
-Fiscal position on the created PO is the fiscal position for "Odoo BE" (and PO is for the company "Odoo US")
Behavior after the fix:
-Fiscal position on the create PO is the fiscal position for "Odoo US".
Closes#11537
opw:673288
When recomputing stored function fields, the `write` may trigger a
cache invalidation which lead to a recompute of all the recordset
values, even the ones already saved in database.
- Only invalidate cache for fields and records we modify
- Rewrite query to be more efficient
- Avoid o2m commands to be more efficient; write directly on reverse m2o
With new api, this call is not wanted anymore. The cache is cleared
automatically, no need to clear the whole cache; that's a little bit
overkill and reduce performances.
Avoid that an invoice for 'SO042' matches with the invoices of 'SO04'.
The use of the like is required as it may contains more than one reference to an
invoice.
opw-676921
9f541d29bf made it so that date_order on
pos.order records is set using the creation_date of the clientside Order
record to avoid weird date_order values when syncing to the server is
not done immediately.
The downside of this approach is that creation_date is set during Order
creation on the client. A user that has an open POS will also have an
open order. So if it takes one hour before the first order can be made
then the date_order will reflect this.
To avoid this we will instead use a validation date, which will be set
when the user clicks on the green 'Validate' button.
Because this is a stable release we won't change the name of the key in
the JSON data that gets sent to the server. This means that from the
server point of view nothing changes.
Fixes#11933
When clicking on a m2o without typing any search text, the dropdown
shows results for the empty search string. The problem is that, on
some databases, records with empty names exist. However ui-autocomplete
library shows empty string label as dropdown divider.
Since a task is in development to prevent users from having non
trimmed record names, the solution that was chosen here is to
exclude empty names from the results. As the name_search can't evaluate
trimmed field, this commit fix the problem for up to three spaces
record names.
Convert YAML tests into Python tests:
- translation tests moved to test_translate.py
- test phases tests moved to test_phase.py
- safe_eval tests moved to test_base.py
- parent_store tests moved to test_base.py
- float rounding tests moved to test_float.py
- `ir.rule` tests moved to test_acl.py
- search tests moved to test_expression.py
"Depreciation Account" must be renamed in "Depreciation Expense Account"
Reason: This is the account that will be shown in the Profit and Loss, the original
label "Depreciation Account" is confusing because it could mean a depreciation asset
account.
"Asset Account" must be renamed in "Depreciation Asset Account"
Reason: This makes it clear that this is an asset account that will receive
depreciation entries, without this wording it could mean that we are simply
informing the Asset module which account is the asset account, but that depreciation
entries go elsewhere.
opw:672852
When dealing with issues related to 'rescue' sessions we are very
limited in what we can do because the actual orders sent to the backend
exist only in localStorage in the browser on the device of the
user. Because of this it is important that we log some data about the
orders we receive in the backend to have an idea of what's going on.
opw-676497
When several accounts are selected to print their GL, the GL of only one
is printed. This is due to two issues:
- 'active_id' is retrieved instead of 'active_ids'
- the method `get_action` is called with the wrong records. `self`
refers to the wizard, not to the accounts selected.
opw-676061
Aaron Bohy