Have a product with internal reference
Open POS session
Create an order with the product
Invoice
Issue: Internal reference is shown twice on the invoice line
opw-3343170
closesodoo/odoo#125293
X-original-commit: 4fbcbd2bb04b35635db7903648ba7c39c41c2dad
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Have an Egyptian company setup
Go to Currencies > USD
Add a new entry with Unit per EGP 0.03232062055591467
Issue: Warning will raise
"Please make sure that the EGP per unit is within 5 decimal accuracy.
Higher decimal accuracy might lead to inconsistency with the ETA
invoicing portal!"
Even if the shown EGP per Unit is 30.940000000000 it is actually
30.940000000000005 and it will fail the equal-to-rounding test
opw-3333395
closesodoo/odoo#125292
X-original-commit: 2867a68534212efd8549764a03c26e86c5109381
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
For a `pos.payment.method`, it is possible to define an outstanding
account, but if this account is not defined as an outstanding account in
the company settings nor in the journal, the payment will not be
considered in the bank reconciliation, nor in the bank reconciliation
report.
Steps to reproduce (demo-data with POS and Accounting installed):
-go to 'Point of Sale/Configuration/Payment Methods'.
-click on the "Bank" payment method.
-add an 'Outstanding Account' which is not the default outstanding
account of the company, nor an outstanding account of an
`account.payment.method.line`. So for example "Liquidity Transfer".
-then open a POS session, sell smth, pay with the Bank method, validate,
then close the session.
-If you go to 'Accounting/Customers/Payments', you can see that an
`account.payment` has been created, with the outstanding account being
"Liquidity Transfer".
->It is not possible to reconcile that payment with a
`account.bank.statement.line`. If you go to the accounting dashboard,
then click the reconcile button of the journal "Bank", then on a
statement line with no partner, you will not see the outstanding line
of that payment.
->If you open the 'Reconciliation Report' of the journal "Bank"
(accessible from the journal dashboard, by clicking the options of the
journal), the line will not show in the 'Outstanding Receipts'
category.
FIX:
Override the `_get_journal_inbound_outstanding_payment_accounts`
method of `account.journal`, to add the accounts from each
`pos.payment.method` linked to the journal. Using the field
`pos_payment_method_ids` from `account.journal`.
opw-3271090
closesodoo/odoo#125238
X-original-commit: c002e6bfbb194b0d609956b36f23a5dbf7acffd4
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Arnaud-Sibille (arsi) <arsi@odoo.com>
In this commit, we renamed the calendar filter in task from
'Undefined' to 'Private' to be consistent with the terminology
used in the other views task.
task-3214107
closesodoo/odoo#115621
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose of this commit by making the popover look less cluttered by
hiding fields when they don't have any value and moving fields around
in task calendar popover.
task-3214107
Part-of: odoo/odoo#115621
This commit fixes the object reference issue which was linked to the
TaxTotals Component computations. The issue was that discarding changes
on the tax field of a vendor bill wouldn't roll back the field's value
visually while the record would still have correctly updated values.
This issue originates from the fact that operations were made to compute
the taxes in the component but these would affect the server data as
well since the object reference between the local data and the server
data was the same. This means that the discard operation would bring
the displayed value back to the server data's one which has been
modified by the computations so it would not work. The reference to the
server data is now separated from the local one so that the bug won't
appear anymore.
opw-3285209
closesodoo/odoo#125304
X-original-commit: 9178c96f5788989c38fbb335ea79fc6ea8698131
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Before this fix, the tour pointer is always repositioned and the animation is
behaving very poorly. Like it's suffering from epilepsy. This is because
`reposition` method relies on dom mutation to calculate the correct position
which is detected by the tour runner and the tour runner thinks that it needs to
check the current step which eventually calls the `reposition` method again,
being stuck in a loop.
In this commit, we introduce and additional check before calling `reposition`.
If the last x and y of the anchor (current step's element) changed by less than
a pixel, we consider it as static, and we don't call the `reposition` function.
Task-id: 3369617
X-original-commit: cf42ed86220a397f24fca497bf5a77e2b72ba4e2
Part-of: odoo/odoo#125262
There were two issues with the `getNormalizedCursorPosition`:
1. If the selection was in a non-editable element, the function called
`rightPos` only once, without ensuring that the new position was editable.
-> The current implementation fixes that by making it loop while in a
non-editable element, and also allows the normalized position to use `leftPos`
if the offset of a position is 0.
2. When searching for the deepest leaf to the right, the `DOMPathGenerator` was
allowed to traverse non-editable elements, which is not correct since the result
should always be editable for a normalized position.
-> This is fixed, and the name of the `DOMPathGenerator` utils is updated for
clarity.
task-3280704
closesodoo/odoo#125204
X-original-commit: 3d44028a7722f61900b8669489ff929244b1a4b8
Related: odoo/enterprise#42615
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
The previous iteration (394e4fe) prevented the editor to fix selections in
`contenteditable="false"` elements if they had a `data-oe-protected="true"`
parent. This caused undesirable side-effects such as being able to click in an
embedded view in Knowledge, then type `Backspace` and remove view elements.
The solution implemented in this commit allows the editor to fix such a
selection, only if it is not currently targetting a `<input>` or `<textarea>`
tag, as they are supposedly the only `isContentEditable === false` elements that
are editable by a user in an Odoo view.
task-3280704
X-original-commit: 98767b805fe26883cf851bac4f8d5382a3303eb4
Part-of: odoo/odoo#125204
Prevent custom editor selection of protected tables. The previous iteration
(394e4fe) did not take into account non-collapsed selections.
This iteration does not handle `data-oe-protected="true"` on `table` elements
below the `<table>` tag (i.e. `<tbody>, <tr>, <td>`...), because there is no
need for that currently and it would add further complexity to the code.
task-3280704
X-original-commit: 885d52c9b814d908438e8e424d17c4e4b6e9e731
Part-of: odoo/odoo#125204
Some commands of the editor are able to modify non editable nodes in the editor,
notably those that use the `formatSelection` util. This commit intent is to
prevent such commands to have an effect on `contenteditable="false"` nodes.
Here is the list of impacted methods:
- setTag
- switchDirection
- unlink
- indentList
- toggleList
- applyColor
- every function using `formatSelection`:
- bold
- italic
- underline
- strikeThrough
- setFontSize
In knowledge, `Behaviors` are OWL components that are used in the editor, and
they all have `contenteditable="false"` parts that are managed by OWL. Those
functions could modify those managed nodes and make OWL crash.
task-3280704
X-original-commit: 6d90274e0a21848d704cfd86d7a1d0c5860a9b18
Part-of: odoo/odoo#125204
When a `pos` is configured as `self order`, the dashboard buttons become misaligned.
This PR brings back the buttons into alignment.
Task 3357989
closesodoo/odoo#124255
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The link to the `Floor Plans` configuration is only visible in debug mode.
This makes for a bad user experience.
This PR makes it so the link is always visible to `pos users`, regardless of whether
or not the user is in debug mode.
Task: 3357989
Part-of: odoo/odoo#124255
before this commit, karma_user_bio was not added in the
forum forum view and the default value set for the field
was 750, this field decide whether the pop over has to
show or not when user places the mouse hover the author
box in the frontend forum post.
after this commit, as the field is added to the view
end user will be able to adjust the value as per the
need.
closesodoo/odoo#123638
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Most e-mail clients do not support CSS rules for hover effects.
Previously, the mass_mailing application allowed to add buttons with
such effects. This was confusing to some and introduced discrepancies
between the editor preview and the actual e-mails.
This commit removes such hover effects from buttons in the context of
mass mailing.
Task-2936682
closesodoo/odoo#125298
X-original-commit: 55aff2dcdf5537e16bdaf01ee68d776510572171
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
- Be sure to have two languages installed;
- Open a record with translations (product, for instance);
- Modify the field with translation, from "apple" to "peach";
- Open the translation.
- Modify the English term, from "peach" to "apricot";
- Save;
Before this commit, the field on the record still shows "peach", you
need to revert the changes to came back to "apricot" (the last modified
term). This occurs because the record is not yet saved, but the
translation is. This can create confusing behaviors.
Note also, that there is a different behavior when clicking on a
translation button between new record and existing records. The first
one will ask to save the record before doing the translation,
contrariwise, the last one will let you modify the translation without
saving.
In this commit, to avoid all confusion, and to be coherent between new
record and existing record, and to be also coherent with the always save
policy. We will save the record automatically before opening the
translation dialog.
part-of task-id 3179751
closesodoo/odoo#125149
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When user tries to enter extra info from Configure Form from 'settings' so
'website.sale_get_order' method does not get any order.
Steps to reproduce:
1) Install website_sale module.
2) Click on settings > activate 'Extra Step During Checkout' > click on 'Save'
button.
3) Now in 'settings', click on 'Configure Form' under
'Extra Step During Checkout'.
4) Now, click on 'Discard' button on top right of screen.
5) Enter something in textbox 'Give us your feedback' > click on 'Next' button
and traceback will be generated in backend.
Error: ValueError: Expected singleton: sale.order() traceback will be generated
because in method '_message_log' it is expecting a record.
Sentry-4126876202
closesodoo/odoo#125259
X-original-commit: 43506c5934e50bc1b132a135466b405f1d1ebb20
Signed-off-by: Mohit Beniwal (mobe) <mobe@odoo.com>
Before this commit, when deleting an attachment from composer,
an undefined message was inserted in the store.
closesodoo/odoo#125313
X-original-commit: ec814f14222509caa27d627a193e6eaebe9bbf60
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
In discuss when a user receives a message containing strings from any of
these '>,<,&' it gets converted to `>,<,&` respectively.
For example, if a user sends '<abc>' , when the chat is out of focus,
the toaster notification will show a notification with an escaped message
i.e.`<abc>`.
After this commit:
The message will be shown as it is, in the toaster notification.
Task-3284244
closesodoo/odoo#125306
X-original-commit: bbc9966198eb644c220d98452e0ef53c8424f5ea
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When odoo tab is out-of-focus and user receives a new message,
it should play a sound effect. This works when showing notification
in Odoo, but when push notifications were enabled it did not play
the audio.
This commit fixes the issue by playing audio when receiving push
notification of new message while out-of-focusing the tab.
closesodoo/odoo#125305
X-original-commit: b0b4f300705595df31588e747e1b12ad99f6d8d0
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When using the Send & Print wizard in invoice_single, the error is raised if any
making all changes rollbacked including the update of the 'peppol_move_state'.
closesodoo/odoo#125302
X-original-commit: ec1209c2853ead82bcf27728612d1a7efc6dc97a
Signed-off-by: Laurent Smet <las@odoo.com>
- Create an invoice
- Sent it using the Send & Print wizard
- Remove the PDF manually
=> The Send & Print button is still secondary instead of primary
X-original-commit: ef9e266c86cbc4abc24e2a6f597a2014e6e3439a
Part-of: odoo/odoo#125302
When creating the attachments for the mail.message, copy the attachments
instead of linking the existing ones.
That way, even if the user deletes the PDF or another business documents,
the history remains the same and can be retrieved easily.
X-original-commit: 7434cbe47ec58695a2dde40bcf4bd3bdaf6f1964
Part-of: odoo/odoo#125302
In a Sale Order, it is possible to select an invoice address without a
name. The partner of the transaction does not have a name, which leads
to a traceback when trying to split the name.
The idea is to force the name to be filled, with a fallback on the
partner' parent name.
OPW-3338406
closesodoo/odoo#125282
X-original-commit: 505109d4111208aaf934a31373e9abec2bb38ad7
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
With an mx company setup
Create Invoice
Validate CFDI
Click "Send & Print"
Issue: xml not in attachments
In e9e90811aeee46989a83b21f9b59071a9c7bc362 the name of method responsible
for loading attachment was changed from
`_get_default_mail_attachments_data`
to
`_get_default_email_attachment_data`
But the account_edi override wasn't changed so no xml was attached
opw-3370272
closesodoo/odoo#125275
X-original-commit: 0bf8296d74002ab691b809c484d38c3ead2c090b
Signed-off-by: Josse Colpaert <jco@odoo.com>
To reproduce:
1. Create a storable product with ordered quantities policy for purchase and with a category set as FIFO automated
2. Create a purchase order in a different currency and set quantities for partial deliveries
3. Create a partial delivery
4. Fully invoice the purchase order
5. Create the delivery of the complementary units
6. Check the stock valuation layer
The valuation of backorder is wrong.
The value on valuation layer is in company's currency, while the value
on invoice line is in the PO's currency. When create valuation line for
backorder, we didn't convert them to same currency.
opw-3300266
closesodoo/odoo#125206
X-original-commit: c2de679fcba7f153201dde5b3aa989eb3f329910
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Fix wrongly generated link when "Other" department filter is active
(introduced by odoo/odoo@54f246f9c)
To reproduce (on runbot):
- Log-in as 'admin'
- Go to the website /jobs page
- Edit page and enable both 'Country' and 'Department' search filters
then save changes
- Choose "Others" in the departments filter
- Choose any country in the countries filter
=> traceback with:
`ValueError: invalid literal for int() with base 10: '233is_other_department=1'`
closesodoo/odoo#125203
X-original-commit: 12085c9b653412b976279495804f672f3307764b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The Gevent worker has specifc needs in term of maximum concurrent
connections to the database and those needs are not compatible with the
default limit that is primerly set for http workers.
This PR makes it possible to supply a configuration dedicated to the
gevent worker.
task-id-3193565
task-id-2146565
closesodoo/odoo#125190
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Following an FP-Request, this PR aims to ease the life of the user
by indicating the full name of the elements that are truncated due
to their length as a tooltip.
task-3332648
closesodoo/odoo#125186
X-original-commit: 8512402d803e788347aa5f7012c4380c3dd34fae
Signed-off-by: Kevin Baptiste <kba@odoo.com>
After creating a sales order for a product with cost 0, automatic
inventory valuation and AVCO, and validating the delivery, no account
move is created for the stock move. If an invoice is then created from
the sales order, it will create 0 amount COGS lines. Automatic
reconciliation of the invoice with the corresponding stock account move
will fail because no such entry exists, resulting in unreconciled lines
remaining in the invoices.
This issue can be prevented by either creating a 0 amount journal entry
for the stock move, or preventing the creation of the 0 amount COGS
lines on the invoice. Not creating unnecessary COGS lines is preferable
and this was also the solution used for the same problem with purchase
order invoices: https://github.com/odoo/odoo/pull/106785 .
So this fix does the same for sales order invoices.
opw-3000320
closesodoo/odoo#125185
X-original-commit: 999451e6ea0b2b1591a3644725b5313c6e062b39
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>
The triangle pointing towards an option in the editor is pointing
right and the symbol └ is used to show a sub option in the editor panel.
In a RTL setting, this does not make sense and should be mirrored.
task-3284274
closesodoo/odoo#125153
X-original-commit: a66ff40b28717617e28387b22bdfe9e468242907
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In case the journal currency is set on the company currency, we should
compute the 'Bills to Pay' sum on amount_residual_signed as it is
the residual amount in the company currency.
In the current state, you can have differences between the sum in the
dashboard and the sum showed in the list view from the 'Bills To Pay'
button.
Steps to reproduce (clean db with accounting):
-Set a foreign currency with 2 different rates (significant if you want
to see the issue clearly).
-Create an invoice in a sale/purchase journal which has no currency set
(like Vendor Bills), with the foreign currency and with an invoice_date
corresponding to one of the rate.
-Register a payment for that invoice, with a date corresponding to the
other rate and having an amount lower (like half) than the invoice, so
the invoice is partially reconciled.
-> Go to the accounting dashboard, the amount next to 'Bills to Pay' is
different than the amount (the sum of the column 'Amount Due') in the
list view generated after clicking that button.
These two values should be the same. They are currently different
because the dashboard takes the amount_residual, which is expressed in
the invoice currency, and apply the exchange rate to get the residual in
the journal currency.
But if the target currency is the company currency, the field
amount_residual_signed is already the residual amount in the company
currency. Unfortunately, in case of partial reconciliation, it is not
always equal to amount_residual expressed in the company currency
anymore. Because amount_residual and amount_residual_signed are
substracted by the payment amount, expressed in each currency, using the
payment date exchange rate.
opw-3184567
closesodoo/odoo#125150
X-original-commit: d71d8e90667ccc9c5428cc15b927747b4b3556cd
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Arnaud-Sibille (arsi) <arsi@odoo.com>
This commit adds a new module in web that contains a few helpers to
make it easier to use reactive in Odoo.
closesodoo/odoo#125136
Related: odoo/enterprise#42588
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Steps to reproduce:
- Go on a backend HTML field (project task description for instance)
- Write and select some text
- Open the text background color colorpicker
- Hit the "reset" button (the trash icon)
=> The text becomes black (or white in dark mode)
This was because of [1] which indirectly removed the CSS variables
`--black` and `--white`, on which the colorpalette relies.
Note: the test update made by the original commit was lost in the
forward-port because [2] removed the test. It will be restored at some
point thanks to task-3177674.
[1]: https://github.com/odoo/odoo/commit/28444a5792b9929f5250e38f3f864694e22e9370
[2]: https://github.com/odoo/odoo/commit/49297bc7bba75541ca139e6c84e0d3b311765145closesodoo/odoo#125131
X-original-commit: 907c5b6cc24e0b86c219cda1299a87b7901f4e76
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website
Commit [1] (and [2]) from the "website in backend" refactoring adapted
the colorpalette to read color information on the right document (as
the right document could now be the one of an iframe which is inside the
editor environment). Unfortunately, it did not do that correctly, making
an inconsistent API relying on the fact the colorpalette should receive
an "editable" param... while a jQuery version "$editable" param of the
same thing already existed. Doing so, it forgot to give that important
"editable" param in two cases:
- For editor toolbar colorpickers (text foreground/background edition)
- For colorpickers inside another UserValueWidget (like we-multi).
This commit solves the inconsistency by removing the need of that
"editable" params and relying on the previously existing "$editable". In
the future, this should be refactored anyway.
Steps to see the issue (A):
- Enter edit mode of one of your website page
- Select some text
- Hit the "reset" (trash button) of the text background colorpicker
=> The text becomes black for no apparent reason.
Steps to see the issue (B):
- Enter edit mode of one of your website page
- Choose a new main color for your website via the theme tab
- Select some text
- Open the colorpicker for the foreground color
- Go to the solid tab and input explicitly the main color of the website
=> The color is hardcoded on the selected text instead of using the
text-o-color-1 class.
=> A test has been added to check this usecase. Making a test for (A)
is less robust as it also requires the backend color names not being
the same as the frontend ones to have the bug (otherwise it works by
chance)... and that will be solved by the next commit of this PR
(another test will be added by that commit too) **.
Note:
- After this commit, following (A), a bug remains: the text receives a
strange padding (as a "inherit" background is actually applied).
Another PR will be made to solve that (see task for more info).
- ** After this commit, (A) done in backend HTML fields instead of a
website page leads to the same bug still. This is because of another
problem that the following commit of this PR will solve.
[1]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-3237693
X-original-commit: a30206606423af9e6c8e0313c74fd6200247437e
Part-of: odoo/odoo#125131
Since [1] thread actions are stored in a specific registry.
Some of those actions require props to be passed to their
component.
Those props are not correctly passed as the `componentProps`
key is in fact a function that returns the props but is
treated as the props themselves.
This commit fixes this issue by transforming `componentProps`
into a getter, so that `action` is internally passed to
`componentProps` definition. The templates using thread
actions can still use `t-props="componentProps"` as getter,
as the active action is deduced by transform automatically.
[1]: odoo#123454
closesodoo/odoo#125120
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce the bug (in 16.0):
- Create a hoverable mega menu
- Drop inline Search snippet inside the menu
- Search for something.
- Hover on the search result and move the cursor outside of the search result.
=> Result Error.
Since [1], is having a fix to the overflows of the page. In that fix
we are triggering hide(), and show() events on a 'dropdown-toggle' element
without checking whether the element is exist in the target or not.
this commit will make sure that element should be present in the target
before triggering the event.
[1]: odoo@5846a05
closesodoo/odoo#125083
Closes: odoo#118803
X-original-commit: 4fba98dbe9a82cf0fec9080bea147f5d4d088b53
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the seen indicator in squashed messages was
not centered. This is especially noticeable in comparison to
shorten date when hovering on this squashed message in chat window.
This commit centers the sidebar in squashed messages.
closesodoo/odoo#125082
X-original-commit: 1c342c1c5c14add563bba07fe5e5b6e6fbe9fdb3
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, when posting a message in discuss with some
urls, the url was not linkified.
Example of such linkify not working:
```
https://www.45017478-master-all.runbot134.odoo.com/web
```
The url regexp was changed with [1]
to make punctuation mark the end of url to linkify. The 1st dot
removed in diff was a mistake. This commit reverts this part, so
that url above is correctly linkified while fixing the problem
of [1].
[1] https://github.com/odoo/odoo/pull/122621closesodoo/odoo#125081
X-original-commit: bbbc85865b45615937a22ed08b6e560a0aa898a0
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce the problem:
- Drop a popup snippet in a page.
- On another language, click on translate.
- Problem -> It is impossible to translate the popup.
To resolve this problem, the function `_updateInvisibleDOM` is called
even in translation mode. Thanks to this function, the invisible
snippets are now filled in the edit bar and the user has the opportunity
to display them or to hide them.
task-3098517
opw-3268592
opw-3283140
closesodoo/odoo#125078
X-original-commit: c76ff023b84da65d90b7967c91adde4bd777265b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds arabic in the list of iap languages so that we can test
that the industries are correctly translated in arabic.
related to task-3343616
closesodoo/odoo#125005
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce
- Create Manufacturing Orders and confirm it.
- Validate the done quantities.
- Click on valuation button. It will raise trackback
Error caused by commit: a080337closesodoo/odoo#124956
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit ensure the expected tables are accessed when a page (not
only) is requested.
This is needed because without that, we can only check the query count
number which might be broken without being noticed:
- Commit 1 reduce queries by 2 (no need to access table X anymore)
- Commit 2 later reduce queries by 2 (less access on a table) but
without noticing it, it also now introduce back the access of table X.
At the end the query count is still fine, but the code is not: it broke
a previous improvement while it was not necessary.
Worst, it could even lower the query count despite still breaking a
previous improvement (-3 queries +2 queries back).
Also, since the query count of a page is not exactly the same inside a
test and in real use cases, an `EXTRA_REQUEST` param is used in those
tests to abstract that change and still use the "real use case" query
count in the test to fit the reality, be human readable and easier to
write/debug.
Indeed, in test mode there is more queries due to the test cursor
rollback and savepoint, but there is one less query (the cache one).
Some commit wrongly reduced that `EXTRA_REQUEST` param making it looks
like there was an improvement while there wasn't.
This commit will help preventing all of that, ensuring the correct
tables are accessed and only those, on top of checking the query count
number (we still need to check the query count in case there is a query
not catched in the SQL table logs).
Some of the PRs/commits where it happened:
- https://github.com/odoo/odoo/commit/aa1c1b0bcb5327894c7b00d0454eebae06eaa005
- https://github.com/odoo/odoo/pull/112000/files#r1160851862closesodoo/odoo#124939
X-original-commit: 26e1fc3abd54a1baa16cf1c99d75d501a8dc6906
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit introduced a way to log queried table on cursor without
having to be in `--log-sql` mode.
It will be used in next commit to add complete performances tests which
will ensure the correct tables are accessed when a page is requested.
This is useful as right now those performances tests are only doing a
check against the SQL query number without ensuring the queries are the
correct ones.
As a result, one could introduce an improvement which would reduce the
queries (-2) but break another previous improvement (-2) which would
add back those queries (+2). Since the query count would be the same
(-2+2), it would be undetected, instead of being fixed directly and
keep both improvements (-2-2).
See next commit for concrete example(s) and use of this improvement.
X-original-commit: 8ef6137a34aa35182399a2bd4b20dd57479ab2e7
Part-of: odoo/odoo#124939
Andrea Grazioso (agr-odoo)