On mobile (specifically in landscape orientation as the height of the
viewport is narrower), the content appear over the bottom toolbar
instead of going below.
Solution is in 2 parts:
* raise the toolbar way above the content
* make the toolbar opaque
closesodoo/odoo#28429
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28408
Before commit 60f143c8e7, the dashboard
parameters did not use the parameters from the action, so some important
information could be lost.
However, in this same commit, the action context overrides the context
from the user defined views, which means that some information is lost.
For example, customized group bys are ignored.
This commit fixes the issue with some careful context manipulation.
Some special care was done to remove the groupby from the action context
if it is not empty, because that same logic is used in views.
Introduced by: 3d46887d38
Before this commit, creating an invoice from a SO always chose
the payment_method=all when the number of invoice linked to the SO >0
OR all the lines of the SO were with invoice_policy = 'order'
After this commit, creating an invoice from a SO just choose the payment_method=all
when the number of not canceled invoice linked to the SO > 0 AND when there are at
least one downpayment in the SO
SO:
Steps to reproduce the changement of behavior:
- Create a SO for 10 units (invoicing policy based on ordered quantities)
- Create the invoice for 10 units (from SO) and validate it
- Change ordered quantities to 5 units
- Click on create invoice on the SO
The payment method chosen was delivery instead of all. So choosing the default option
lead to a user error saying: there are no invoicable line instead of creating a credit note.
opw:1904258
closesodoo/odoo#28426
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
As empty arrays are considered truthy, the call to `/web_unsplash/get_app_id`
would always be performed even if no Unsplash images.
closesodoo/odoo#28421
Before this commit:
Reserved column appeared with 0 qty when Delivery Order goes to done Stage
After this commit:
Hide Reserved column when Delivery Order goes to done stage.
This task is related to #1888361Closes: #27223closesodoo/odoo#28409
Let's assume a form view with field A and B (a one2many list), with
a column with attrs column_invisible depending on A.
If the user sets A manually, everything works fine (the column is
hidden/shown directly). However, if A is updated by an onchange
(e.g. depending on the number of rows in B), it doesn't. This
rev. fixes that issue.
Related to Issue: 1851451
Co-authored-by: Priyanka Kaakdiya <pka@odoo.com>
payment_term.id, creates a tuple wich works if payment_term.id is set
in case payment_term.id is False this creates the tuple (False,) which
is then converted by the Odoo ORM to a account.payment.term(False, )
record set, which in term may cause weird behaviour as this value does
not eval to false in cases like `if self.payment_term_id:`
Closesodoo/odoo#28397
Before that, when reversing an account.move, if two lines of the move shared the same account, we tried reconciling them once for each line: it worked the first time but triggered an error message the second, since the lines had already been reconciled.
On the BoM structure report the price on line with a
child BoM is inchoerent. Also the sum of all lines in
the report is not always equals to the total of the parent
line.
For the first issue, it happens due to commit 17b6256955
that use the number of operation cycle as quantity.
The second issue happens because sometimes the rounding is not done
at the smallest level and thus the rounding of the sum is different than
the sum of the rouding.
Before that, taxes were only applied with the most recent currency rate, which caused problems in multi currencies, when reconciling statement lines made in the past with invoices, causing the amount currencies in the payment account.move to be wrong.
//Scenario to reproduce the issue (from customer ticket 1903497):
(for a company with USD as base currency)
1. Create a new bank journal for EUR payments
2. Create a new customer invoice for 90€
3. Create a new tax for the reconciliation model, price-included and amounting to 15%
4. Create a new reconciliation model using this tax
5. Use the currency rates from the demo data, add one that is closer to current date than the most recent one.
6. Create a new bank statement for the created EUR bank journal. Make sure that the transaction is less than the actual amount due on the invoice so that we can apply the reconciliation model. Also make sure to set a date on the transaction that lies in the past at some point when the currency rate was (significantly) different.
7. Hit the reconcile button, select the amount due from the invoice and apply the discount reconciliation model(take note of the amount on the created tax move line). Now reconcile.
What is the current behavior that you observe?
Now go back to the bank statement and check the created journal entries. You will see a difference in the amount currency values of the payment and the tax account move line. This difference should not exist.
Revert commits da2140b726, e65c8826ef and 06cd145a79. They
introduce an incorrect UOM.
The original issue was an `AccessError` due to the fact that the
employee chosen was not in the same company than the user. Therefore,
instead of changing the logic of the UOM selection, we make sure to
select the employee in the appropriate company first, then fall back on
any company then.
opw-1888299
Due to the implementation of PEP-475[1] in Python 3.5, revision
e98e8e9b1b used the recommended technique
of wakeup file descriptors in order to detect interruption of sleep() and
select() by signals, when running in multi-process mode (workers > 0).
The technique works well, however the initial patch never bothered to
read the byte that is written to the wakeup pipe when a signal is
processed. This does not matter when the signal is meant to shut down
the server, but it matters when the signal is SIGQUIT: it simply prints
thread dumps, and continues operating normally.
As a consequence, that byte remains in the wakeup pipe forever, causing
all the subsequent select/sleep calls to return immediately because
the wakeup fd *is* already ready. The symptom was that worker
processes would start cycling their main run loop very fast after
receiving a SIGQUIT signal, eating 100% CPU.
This patch ensures we always empty the wakeup pipe after an interruptible
call, to avoid this effect. It also refactors another occurrence of the
"empty pipe" pattern, in the PreforkServer, and incidentally uses readable
aliases for the file descriptors bound to the ends of the wakeup pipe
(wakeup_fd_r / wakeup_fd_w).
[1] https://www.python.org/dev/peps/pep-0475closesodoo/odoo#28356
This commit extend commit https://github.com/odoo/odoo/commit/ef48b81ab127dd717a4a9d106edd5c51121bc8f7
When you have a cart on multiple session and confirm the card in one of them,
you could still access your cart from other session (note that you could not do
anything with it as it would be reset when adding product or changing qty).
Closes#28210
Creating a service and stockable that create a PO on SO confirmation
(with different suppliers) will indeed work, but the status button
will only display 1 PO. The problem is that stock is not linking
the SO line with the PO line.
Thus, we prefer desactivated the button displaying the wrong value, as
it brings confusion to the user.
A proper bugfix should be done in master, to correctly link SO line with
PO line making the PO count correct.
opw-1905189
closesodoo/odoo#28410
Before 762adedece the search was done on the related field product_id
This was equivalent to make a search on the records order_line.product_id
and to use the name_search of product to find it.
With the filter order_line.product_id.name, it was explicitly searching on the
name of the template
Fixesodoo/odoo#28344closesodoo/odoo#28390
- Activate multi-currency
- Create an Journal Entry manually
- Create a line
Do not fill Account
Fill in Amount Currency
Fill in Currency
A traceback occurs because `line.company_currency_id`.
An extra condition `and line.company_currency_id` is not sufficient to
have the onchange working properly. Indeed, the related field
`company_currency_id` goes through another related field (`company_id`),
leading to an empty value in some cases.
opw-1904854
closesodoo/odoo#28389
When a record inaccessible by the user is linked
to a message in a channel accessible to the user,
Avoid to raise an access error due to this linked record.
Also need an aditional query in test query_count.
closesodoo/odoo#28312
- Scan a barcode for employee 1 in kiosk mode
- At greetings message, scan a barcode for employee 2
2 attendance entries are created for employee 2 instead of 1.
When scanning the barcode for employee 2, the event listener
`_onBarcodeScanned` is still active on `KioskMode`. Therefore, the RPC
call to `attendance_scan` is performed twice.
We deactivate the event listener after scanning, and reactivate on
`KioskMode` only if there is an issue. This is sufficient since the call
to `do_action` in `GreetingMessage` will create another instance of the
client action. In `GreetingMessage`, we add back the redirection to
`KioskMode`.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Linked to Task ID 1878251
opw-1878632
opw-1888402
closesodoo/odoo#28150
When a view is loaded, it checks which fields it has to load.
In the case of a many2one, it could be the case that a context key is present in
one view and not in the other; if it happens, we should reload the data, as a
name_get result could vary.
opw 1891295
closesodoo/odoo#28298
- When using perpetual inventory valuation, the accounts used for scrap, manufacturing,
and inventory adjustment operations are set on the corresponding locations .
- In a multicompany environment, you will have a separate chart of accounts for each company.
- Account fields on locations are not property fields.
- Therefore, in order to separate the accounting of manufacturing, scrap, and inventory
adjustment operations, you must use a location for each operation for each company.
- Set up one location for each company for scrap, production, and adjustment
locations, setting the company field on each.
Bug:
- When attempting to create a MO, inventory adjustment, or scrap order while signed
in to the second company, you will receive a permissions error on stock.location.
Fix:
- Now the right location is taken according to the company of the user.
Backport of this commit: c7526407ab
opw:1817339
The percentage field is computed in _compute_percentage as a value
between 0 and 1. This is good because that's what widget="percentage"
in views expects.
This makes read_group also return a value between 0 and 1, instead of
0 and 100. Otherwise list views will show e.g. 5000% when grouping
lines that sum to 50%.
Introduced in saas-11.4 at odoo/odoo@9148960174.
*Do not forward port, already ported to 12.0 via
odoo/enterprise#2975 (odoo/enterprise@a1484e650c)*
opw-1904481
This shorten form is aa-bbb-x. The a characters are the first two digits of the number, x is the mod10r verification digit, and b characters consist of all the intermediate digits, without the leading 0s. The chain of b characters' length can range between 1 and 6 characters.
Sylvain Van Hoof