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
- 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
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.
Before this commit, when loading the data and calling the prostprocess,
the viewType was not correctly passed which could lead to broken
behaviour. For example, if one was to load a record from a list view
embedded in a form view, the viewtype passed was the list which
prevented to load the data from the form view.
OPW 1891295
closesodoo/odoo#28279
When creating a record in a grouped kanban view, it tries to add
the record to the first column but if no column exist, it fails
to find the first one and raise an exception.
This PR correct that bevahior by checking it exists a column and
fallback to the view form when it does not.
opw-1902851
closesodoo/odoo#28262
Backport of 17bb0ca443
Before this commit, the user could not receive any notification
from the chatter of a document when having Notification Management
set to "Handle with Odoo".
This problem occurs when the user opens (or has opened) the document.
Any messages received from the document are automatically marked
as read, so it removes the notification right after receiving it.
In order to no longer have this issue, the user had to reload all
pages that have opened this document.
This commit slightly changes the behaviour of the chatter, so that
it automatically marks it as read only when accessing the document,
but not when the document is open (or has been opened). Consequently,
if the user has opened the document and then receives a notification
from this document, it won't automatically mark it as read.
Task-ID 1895359
opw-1890556
closesodoo/odoo#28113
The "copy link" to clipboard button ancestrally used a flash (.swf) dependency
(ZeroClipboard) to work.
Since Odoo honours its history, it was still there.
However on Firefox you are asked to activate flash to make it work,
and on Chrome nothing happens.
We get rid of this shibboleth, using instead clipboard.js that is already used
elswhere for the same purpose.
closes#27958
opw 1896509
VAT number should be readonly when parent_id is set
This is already what is done in base.view_partner_form and
base.view_partner_short_form
closesodoo/odoo#28190
Before that, the body of the message was never displayed if the message had tracking values. This was annoying for account_asset module, were we prompt the user for some justification when she modifies the depreciation data of an asset, and then call message_post with this text as body, and tracking values reflecting the change that was made.
Spamming the "send" button on the chatter send multiple times the
same message. This PR simply disable the send button to fordib the
spam.
opw-1895511
closes#27233closesodoo/odoo#28078
Steps to reproduce the bug:
- Create a credit note for an amount of 100$
- Validate it and register a payment
- Let's pay an amount of 90$ and mark this credit note as fully paid
Bug:
An error message was raised saying: Wrong credit or debit value in accounting entry !
The field residual_company_signed must be positive for out_invoice and in_refund and
negative for in_invoice and out_refund. In this way, the correct writeoff amount
can be computed in function _create_payment_entry.
PS: In function _compute_payment_amount, the field residual_signed and residual_company_signed
are already signed, that's why it was wrong to multiply a second time on it with MAP_INVOICE_TYPE_PAYMENT_SIGN
opw:1893570
closesodoo/odoo#28148
It appears that chrome headless with sandboxing is failing when running
containerized because it tries to use Linux namespaces.
With this commit, the no-sanbox optional arg is used to avoid this
issue.
Closes#26456Closes#28053
Christophe Simonis