Steps to reproduce the bug:
Let's consider a product P with a unit price = 10
- Create a SO for two lines of the same product P
- Validate the SO and create the invoice
- Refund the invoice and validate it
- Go to Reporting > Sale report and select "Invoiced amount" as measures
Bug= -20 was displayed for the invoiced amount.
Technically, the two refund invoice lines of P were used two times in function
_compute_invoice_amount because for each SO line we catched all the refund lines
of the same product.
opw:1906445
closesodoo/odoo#29095
**Description of the issue/feature this PR addresses:**
Addon hr_attendance adds a check_in/check_out status icon in every card of the employee kanban view. The status is figured out using computed field ``attendance_state``, itself relying on a computed Many2one field, ``last_attendance_id``.
The current way to compute the latter field seems to fetch all attendances before getting the most recent one. For each employee. Which causes the employee kanban view to load very slowly (~30 sec in 90-employee Camptocamp's instance).
This PR suggests to load only the last attendance entry.
Co-authored with @guewen
**Current behavior before PR:**
Employee kanban view loads very slowly.
**Desired behavior after PR is merged:**
Employee kanban view loads reasonably fast.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28953
Suppose that a Task is added on a task via a studio customisation.
Then the _get_message_needaction method gets called on the onchange of the
toplevel task, which triggers another call to _get_message_needaction.
During that update, we get a self with a model.newID; its ids field is empty,
so the list of tasks res itself is empty.
As a result the method crashes on a malformed query.
This can in turn prevent the completion of some higher-level operation,
e.g. a state change on the task.
opw 1909043
closesodoo/odoo#29084
Have:
- Model A with a x2m to model B
- Object A with multiple objects B in x2m (that will be sorted)
- On the list view of model A, click on a column to sort by a field
- this field shall not exist in B
- open a record A (towards form view)
Before this commit, the sorting of the x2m crashed, because the key orderedBy was propagated
Due to commit e713ed2a69
After this commit, it doesn't crash
OPW 1913133
closesodoo/odoo#29094
Usecase to reproduce:
- Enable 'Managers must approve orders'
- Set agreement type as 'exclusive'
- Connect as purchase user
- Create a requisition and an RFQ linked to it
- Confirm the RFQ
It raises a usererror that ask to close other PO linked
to requisition.
It happens because the purchase requisition code do not take
care of double validation on PO. It will try to close the requisition
once button_confirm is called. However it will only write 'to approve'
on PO state and thus trigger the requistion error will be raise since
all linked PO are not 'done' or 'cancel'.
In order to fix it, the action_done on requisition should be call
on button_approve instead of button_confirm. (button_approve is
automatically called when double validation is not enable).
Task: #1884410Closes#28068closesodoo/odoo#29049
Modifying a source term in an XML/HTML translated field can lose translations
if the same term is translated in several languages.
closesodoo/odoo#29078
The other methods do test password length before verifying it, so even
if check_credentials() is not meant to be called directly, it's better
to keep it consistent with the alternatives.
Closes#29023
We now support version 0.12.5(.1), which is available for all recent Debian and Ubuntu versions,
and contains quite a few bug fixes. An up-to-date version of Odoo 10 or later is required, for
pixel-perfect compatibility with the result of 0.12.1.3.
See also the wiki for more info: https://github.com/odoo/odoo/wiki/Wkhtmltopdf
This revision brings the compatibility for our reports
using wkhtmltopdf 0.12.5.
Up to now,
the supported wkhtmltopdf version was 0.12.1.
The goal of this revision is to add the compatibility
to wkhtmltopdf 0.12.5,
while keeping the same exact rendering than in 0.12.1.
There is a behavior change with the `--dpi` parameter,
which no longer has a "zoom" level effect as it did with 0.12.1.
To deal with it, we pass the `--zoom` parameter when
the detected version installed of wkhtmltopdf is after 0.12.2,
with a ratio 96:dpi. 96 being the default dpi of wkhtmltopdf.
This trick allows to render the reports with the exact same
zoom level, whatever the dpi value configured in the reports paperformat.
(at least with dpi values up to 149, after 150, included,
the dpi parameter with wkhtmltopdf 0.12.1 as a weird behavior,
it no longer zoom out)
opw-1907346
closesodoo/odoo#28864
Fixing it directly by commit since there is no es_AR on transifex.
The issue of the ticket has been solved by transifex, this is for
another similar issue that has been found.
opw-1907924
closes#28923
Steps to reproduce the bug:
- Let's consider a product P with a BOM in kit
- Create a PO with P and confirm it
- Cancel the shipment and the PO
- Reset to draft the PO and confirm it
- Valide the new shipment and receive P
Bug:
The qty_received was not updated
opw:1904678
On firefox if we do for example:
ALT+GR + [ALT+GRable ´ key]
Firefox may send keys "AltGr" and "Dead" instead of just "AltGr".
This was possibly causing caret to go a position too low when writing
speedily with diacritical marks.
opw-1903865
closes#28739
Fine tuning of this commit:https://github.com/odoo/odoo/commit/7501691da9a9dae832b7d6e78c6a5f57fc983b5c
Fields signup_token, signup_type, signup_expiration are protected
When sending a quotation (mail template 'Sales Order - Send by Email'):
the token needs to be read (and sometimes written)
opw:1907157
The patch fixes the issue related to repeated orderline rerendering. It means
that if products of the order were printed before, those will not be rendered
again when new updates of order is sent to the kitchen.
Closes#28577
If cost(purchase_price) was 0, margin calculation was incorrect.
The function _product_margin didn't consider the use case
where the cost of the product was set to 0 on the line.
So before the fix it fallback on standard price instead of considering a cost of 0.
opw:1890452, 1885587
Consider the generation of an invoice for a SO having the following lines:
quantity | unit price | taxes | subtotal
----------------------------------------
1 | 100 | 15% | 115
1 | -110 | | -110
Previously, the invoice wrongly received the type 'out_refund' instead of 'out_invoice'. This was because the code was only considering the untaxed amount.
Closes#28259Fixes#26726
Co-authored by pedrobaeza
This code is called by account_reports to build the Aged Receivable/Payable.
However, no support for the multi-company/multi-currency is there and then,
the multi-company filter on account_reports never worked.
In a multicompany environment, an user who has access to multiple companies is
able to select accounts and analytic accounts of multiple companies. This can
easily lead to mistakes in the definition of the asset category.
With this commit the user can only read/select accounts and analytic accounts
belonging to the company already set in the asset category.
This is what is already done in most invoice or other accounting views
Closes#26578
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.
Fix translation placeholders in invite wizard, to make them easier to
understand for translators. Also rework the message generation code
to ensure proper XML structure.
Fix translation placeholders in invite wizard, to make them easier to
understand for translators. Also rework the message generation code
to ensure proper XML structure.
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
Goffin Simon