`waitForCondition` is written in a rather old style with a recursive `setTimeout` to handle the delay / debounce between checks. The code is rather hard to follow, and unnecessarily so: the code can be rewritten as an iterative async function which is a lot simpler.
Important change: `waitForCondition` now immediately checks for the condition instead of waiting `interval` milliseconds before doing so.
This is because the conventional usage is for it to be preceded by an `await triggerClick`, which includes an `await
waitForNextAnimationFrame()`. As a result there are good odds the click has already been processed by the time `waitForCondition` runs.
closesodoo/odoo#133645
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since the bank reconciliation report was removed, users no longer have a view of the journal items that impact the bank account without having a related transaction (account.bank.statement.line)
Since these cause a difference between the GL balance and the balance displayed on the journal dashboard, it is useful to display a link and the total of these journal items.
Only lines dated after the fiscal closing date, or the last statement date are included.
Task-3431843
closesodoo/odoo#129569
Signed-off-by: William André (wan) <wan@odoo.com>
Since a recent change at [1], a race condition seems to occur in the
gray colors palette test. Indeed, the change removed some delay in the
hackish code that is meant to wait for CSS reload.
Instead of restoring that otherwise-useless delay, this commit actually
fixes an extra_trigger that was incorrectly made in this test when it
was introduced at [2].
In any case, we should develop a more consistent and uniformed way to
wait for a CSS reload during edition test tours. It is currently done
different ways in different tests.
Note: this targets 16.0 to fix the wrong extra_trigger at the source,
even though [1] was only made in later versions.
[1]: https://github.com/odoo/odoo/commit/c6f8f781150902f585e16087f4a3868a855f3bd8#diff-795af7752739f5f510f74e5ee9b5b04d18a851062a1a6b7350cbe406e30a409dL18
[2]: https://github.com/odoo/odoo/commit/ddf2e74b4cf503ba651174bc7f280bf2f31a215e
runbot-24371
closesodoo/odoo#133889
X-original-commit: 6f32c27d52f877bde18628eb06475f56bdd95432
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
After the commit 60f41b1f83 scanning a product packaging at the
point of sale would not add the quantity to the order.
The getAddProductOptions function was updated to return a 'quantity'
variable, but the code was still using the old 'weight' variable for
the product packaging.
opw-3479699
closesodoo/odoo#133813
X-original-commit: 34dcfe24c93083c657d1a29806576f5fdcea4554
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
* = calendar, hr, im_livechat, mrp, project_todo, sms, snailmail,
test_mail
The parameter is too often specified with its default value to be worth
being a positional parameter.
Part-of: odoo/odoo#133717
* = calendar, im_livechat, project_todo, sms, snailmail, test_mail,
website_slides
The choice was made to have "trimmed text" check rather than "contains"
to have more robust tests, at the cost of slightly more effort to write
complete and unique asserts.
There is no direct speed improvement from this one, but it is one step
closer to removing jQuery.
Moreover, it will fix infinite loops in some situations, because jQuery
selectors would write attributes on the body, which would trigger the
mutation observer, which itself will call the selector again.
Part-of: odoo/odoo#133717
In this commit, current date is added in control panel breadcrums for calendar
week and calendar month views and this only for mobile screens.
If a week straddles two months then the two months are included in the wording
but in shortcuts (Aug-Sep 2023). In all other cases, the entire month and year
are included in the label (August 2023).
Task-3439201
closesodoo/odoo#133633
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
After the introduction of bootstrap, the floorplan edition style
changed. In this PR we want to make the floorplan edition look like
it was in saas-16.4.
closesodoo/odoo#133592
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Before this commit:
carry over field was two times one in radio and another in dropdown
After this commit:
dropdown carry over field is deleted from view
task-3481879
closesodoo/odoo#133327
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
When a product is purchased and received, valuation layers are created.
if we created a bill for the PO and change the product price, when the
account move is posted, `_apply_price_difference` creates new SVLs to
correct the product value.
Before this commit, the above scenario did not work with subcontracted
products, mainly because the valuation layer is linked to the finished
product move of the MO and not the incoming move of the PO.
This is fixed in `_get_valued_in_moves` where if the move is_subcontract
the orig move is the one linked to the valuation layer.
Now that we have the valuation layer, another issue arises, in the aml
`_generate_price_difference_vals` when the difference is calculated.
the `unit_valuation_difference` is not properly calculated because the
value in the layer includes the components value, so its incorrect to compare
it to the AML price, so we use `_get_layer_price_unit` to get the layer_price_unit
relevant to the AML, which in this case is the price of subcontracting (price on the PO)
Also for automated inventory valuation, when the inventory correction entry is
created it must credit the stock input account since the value of the
subcontracted product is corrected.
closesodoo/odoo#131565
Taskid: 3449931
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When the customer tries to move the video to the first position of the product
image. at that time, the error would be generated.
step to reproduce:
-Install the website_sale
-open Invoicing > vendors > Products > open any Product
-open sales Notepage
-click on add a Media
-past any video url > save it
-click on Go To website from the state button
-click on Edit button > again double click on the image
-then click on a right side position of re-order
error- Key Error:'video_url'
After applying our commit, if the customer got a validation error when
the customer attempted to swap the video into the product images at
the first position. There is a controller named
`/shop/product/resequence-image` which called, when the customer
changes the position of the video.
https://github.com/odoo/odoo/blob/3ce90ddf33f59a80de34cbafd05679d0817d0076/addons/website_sale/controllers/main.py#L582-L587
The `image res_model` will then receive the `product.image` model when a
customer moves a video from the third to the second position, and that model
locates the field known as `video_url`. However, when a customer moves a
video from the second to the first position, `image res_model` will then
receive the `product.product` model, and that model finds the same field but
does not have that field in it.
sentry-4393257638
closesodoo/odoo#133878
X-original-commit: 8a6a5a10befb98bfe21e5beaf60c9a303304486a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Versions:
---------
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- saas-16.4
Steps to reproduce:
-------------------
1. install the purchase and account_accountant modules
2. create a purchase order using a non-default currency;
3. create bill;
4. switch to a journal without set currency.
Issue:
------
Currency of bill automatically changes from the one used
by the order to the company default.
Cause:
------
The `account.move` model only looks at bank statements, journal,
and the company default when computing currency, ignoring any
value that might already be present in the invoice:
```
def _compute_currency_id(self):
for invoice in self:
currency = (
invoice.statement_line_id.foreign_currency_id
or invoice.journal_id.currency_id
or invoice.journal_id.company_id.currency_id
)
invoice.currency_id = currency
```
Solution:
---------
Try to retrieve currency from `invoice.currency_id` before
falling back on the company default.
opw-3434518
closesodoo/odoo#133867
X-original-commit: 114f328575000fd31f117c46381441d7ec0bca05
Signed-off-by: Levi Siuzdak (sile) <sile@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Apparently `lxml.html.document_fromstring` (and possibly other
`lxml.html` loaders) parses byte-strings as latin1 regardless of their
actual encoding, maybe because python2, maybe because there's a super
legacy html4 parser underlying it.
Either way that means ever since loading
`static/description/index.html` files was added 10 years
ago (4bf6a7ea4c) `_get_desc` has been
loading these files in latin1 rather than the utf8 most people would
expect.
Add an explicit decoding phase to try and load html description files
in UTF8. Fall back to latin1 in case there are description files which
are genuinely in latin1, or even just some random-ass broken stuff
which very much isn't utf8 (the extended-ascii encodings -- of which
latin1 is one -- will happily accept and mangle any input as every
byte value is valid, utf8 is a lot more structured).
Closes#127846closesodoo/odoo#133859
X-original-commit: 4dbc3b00e587f3d64cfd964a685f2bddd1b499ad
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- Enable different shipment methods (eg. Fedex US, USPS, DHLS US).
- Enable the 'Wire transfer' payment provider.
- Go to website, choose a storable product and checkout.
- On the last step of checkout, just click on 'Pay'
Issue:
The delivery method and cost is not the that was initially selected on the checkout page.
Reason:
On the start of the ``websiteSaleDelivery`` widget, we try to initialize the shipping cost of
every shipping methods in the list. But the we make a call on ``/shop/update_carrier`` which not
only gives the shipping cost but also change the delivery method of the order. As the loop is async,
the last random carrier to be computed is the one on the sale order when validating. So if we don't click on
the shipping method we want(to update the carrier) it will that last one which will be used.
Solution:
Use the ``/shop/carrier_rate_shipment`` which only returns a result with the cost without touching the
sale order.
opw-3457396
closesodoo/odoo#133846
X-original-commit: 7e2682b903b7908f0e86f66603e34d0b6fe90e52
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Eteil Junior Djoumatchoua (etdj) <etdj@odoo.com>
Before this commit, message edition was available when
pressing the arrow up key. This was a mistake since the
message edition route is not available yet for livechat
visitors. This PR fixes this issue.
closesodoo/odoo#133815
X-original-commit: ab7e70e809b3c7fa5044139582bd09a9e94ee377
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
before this commit, In product page specification tags label is not vertially
align to it's value.
In this commit, fixes the alignment issue by centering the label in website
product page.
task-3451377
closesodoo/odoo#133812
X-original-commit: 8be036367c9a78fb93ae8e48a3d13f110a3a09bd
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
a translation issue that only appears on Odoo.sh. On the
other systems and locally, everything works fine.
The problem seems to have its source in odoo.tools.translate
Here is the problem:
On the basis of staging (brutus), in the LIMS application, menu Report / Test reports:
* take report 000022. The client is in French.
* click on the button "preview PDF"
-> the values of the "state" column are not translated.
Locally (same sources, same database), these values are well translated.
This field is defined as follows:
```py
state = fields.Selection('get_state_value', string='State', copy=True, required=True)
def get_state_value(self):
return [
('init', _('Init')), ('conform', _('Conform')), ('not_conform', _('Not Conform')),
('unconclusive', _('Inconclusive'))
]
```
Here's what happens:
When the '_' method is called, another method ("_get_translation") is called.
It tries to determine which module is used. To do so, it is based
on the path (path) and use the "get_resource_from_path" method:
https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L474
This method iterates over all defined addon paths. On Odoo.sh, these are:
```
'/home/odoo/src/odoo/odoo/addons',
'/home/odoo/.local/share/Odoo/addons/16.0',
'/home/odoo/src/odoo/addons',
'/home/odoo/data/addons/16.0',
'/home/odoo/src/user',
'/home/odoo/src/user/Logicasoft/base',
'/home/odoo/src/user/Logicasoft/lims',
'/home/odoo/src/user/Logicasoft/mail',
'/home/odoo/src/user/Logicasoft/web',
'/home/odoo/src/enterprise',
'/home/odoo/src/themes',
```
The path variable is equivalent to "/home/odoo/src/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"
As soon as the 'path' variable has a common prefix with one of the paths in the
mentioned list, Odoo considers that it has succeeded in finding the path that contains the module in question.
Locally, the path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"
And the found path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/"
But on Odoo.sh, the path found is: "/home/odoo/src/user/"
because Odoo finds that there is a common prefix. This is the case, but another path also has a common prefix: "/home/odoo/src/user/Logicasoft/lims" and this one is the correct one.
The result is that the module found is not the correct one:
- module='Logicasoft' on Odoo.sh
- module = 'lims_base' on other systems
Since the module is not the correct one on odoo.sh, the translation is not found.
Solution
========
when we have a module present in parent and child path we want to take the child path,
which is the long one, so we sort the list of paths by length which ensures that children
have priority on parents.
opw-3374757
closesodoo/odoo#133862
X-original-commit: 6ef7e188963b65a31589f8f15107ce698cd3dc74
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Steps to reproduce:
-------------------
- create a cart;
- select an other shipping method than the default;
- apply a coupon code;
Issue:
------
The shipping method is modified.
Cause:
------
In the `_check_carrier_quotation`, we try to update
the carrier id with the partner's preferred carrier.
This behavior can be changed using `force_carrier_id`
and `keep_carrier` params.
When we call this route with a `GET` method, these parameters don't exist.
We will update the `carrier_id` according to:
```py
if not force_carrier_id and self.partner_shipping_id.property_delivery_carrier_id and not keep_carrier:
force_carrier_id = self.partner_shipping_id.property_delivery_carrier_id.id
```
This will have the effect of modifying the `carrier_id`
that we have previously modified.
Solution:
---------
Perform this logic only during a `POST` method.
When we call the route with a `GET` method,
we only want the information, without modifying it.
opw-3457243
closesodoo/odoo#133819
X-original-commit: 94ed203404b3b2121122697f5ebfe09cc21e3630
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
During 'l10n_eg_eta' server connection when the
'request_response' is not in proper json format then
while decoding 'request_response', the user will face the
'JSONDecodeError Expecting value: line 1 column 1 (char 0)'.
We are keeping the 'blocking_level' as 'error' because the
occurence of this error will prevent the succession of ongoing
operation.
Applying the changes will resolve the issue.
sentry-4220714667
closesodoo/odoo#133866
X-original-commit: 2cf76a9815af31a8d1eb8337d8807506569c9e43
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
Steps to reproduce:
-------------------
- create and pay with ewallet a cart with a ticket;
- create and pay with ewallet an other cart with a ticket;
Remark:
Don't clear element in the session like 'sale_order_id', etc.
For example, by moving the mouse over the cart or by making a payment process.
Issue:
------
An error is raised with the message:
"It is forbidden to modify a sales order which is not in draft status.".
Cause:
------
We apply an update to the cart on a sale order which is not in draft.
Solution:
---------
Make sure we are working on a sale order in draft
when applying a registration post.
If not, clear session elements.
opw-3465937
closesodoo/odoo#133825
X-original-commit: 22f652ddb85de065208371aa21fed8c674687063
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Improves on #119813 (595aa24843): the
commit splits the ORM cache into several, and adds a log entry when
invalidating caches (both individual and all).
To keep tests isolated and coherent (and also make performance tests
usable), the test framework has to clear all caches between tests to
ensure they don't affect one another. This adds a line of log
to *every* test, pointing into the guts of the test framework.
Since the clearing is willful, unconditional, and not bypassable, the
log line has essentially no value, it just adds tremendous amounts of
noise to the logs.
Fix by muting the registry logger specifically when clearing the cache
in the test suite (there is currently no dedicated cache logger, if
there ever is mute that instead).
closesodoo/odoo#133811
X-original-commit: 52371bac7d4fadbeab139e4cd044cdc6b1005299
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When we changed the display of the form in v16, we forgot to adapt the
python framework default form view layout (used when the form view of
the model isn't defined). This provided a weird layout in these case on
Odoo 16.+.
To fix this bad behavior, we adapt the algorithm used to build the
default view form.
Steps to reproduce:
Create a model without a form view and edit it (like we do when you
follow the rd training).
closesodoo/odoo#133837
X-original-commit: 93e95274939abce5f3facde6c8cd29b922d15251
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
The inherited field of a custom field cannot be deleted
Steps to reproduce:
1. Install Contacts and Studio
2. Go to Contacts and open any contact
3. Toggle Studio
4. Add a field of any type in the view, remove it and close Studio
5. Go to Settings > Technical > Database Structure > Fields and search
for `x_studio`
Solution:
Mark the inherited field as manual if its parent field is manual and
allow the deletion of inherited custom field if we also delete its
dependency
Problem:
The inherited field was not marked as custom so it was impossible to
delete it
opw-3093581
closesodoo/odoo#133820
X-original-commit: 526f3407c7c5b4cd014a4d091ca01b9617e6e938
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Steps to reproduce the bug.
- In website edit mode, add a form snippet to a page.
- Add a "number" field within this form.
- Modify the label of this field in the options and name it "Field 1".
- Add a "text" field to the form.
- In the options of the "Text" field, select "Visible only if" for the
"visibility" option.
- Then, choose "Field 1" and "Is greater than" in the two dropdowns that
follow.
- Enter "10" in the input below.
- Save the page.
- Enter "2" in the "Field 1" input.
- Bug: The text field is displayed, even though it should only be
visible if "Field 1" is greater than 10.
This bug exists since the "conditionally show form fields" feature was
added to Website (in this commit [1]). The bug happened because we were
comparing strings instead of numbers.
[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce
opw-3449900
closesodoo/odoo#133838
X-original-commit: e4d64c9f4470874ca853bd871064bb8374c8b5cc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Create [TAX] as 21% included in price tax
Create a Sale Order with the lines:
- Product A, qty 1, unit price 900$, tax [TAX]
- Product B, qty 2, unit price 90$, tax [TAX]
- Product C, qty 4, unit price 49$, tax [TAX]
Confirm order
Create a downpayment with fixed amount of 550$
Go to the downpayment invoice
Issue 1: price total on the downpayment line is 549.99
when we make the downpayment we convert the fixed amount in percentage
and then compute the downpayment amounts.
This result in some rounding issues that are only partially corrected
The price total on the product line was not corrected
Confirm the downpayment invoice
Go back to SO
Hit create invoice again
Issue 2: 'Already invoiced' amount will be 549.99
When the make invoice wizard is created we operate on virtual records of
SO and invoices.
In particular, when the amount_to_invoice is recomputed, instead of using
the value saved in DB the system recompute the total of the downpayment
invoice from the lines, introducing a rounding error which is
manually corrected only when creating the downpayment
opw-3466409
closesodoo/odoo#133836
X-original-commit: e1c85283736deac7dd523f115e6ba9033b656ade
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
This was bothersome to export/import the registry and manually add
the model, by providing the model name and the model class.
```js
// before
modelRegistry.add(Model.name, Model);
// after
Model.register();
```
closesodoo/odoo#133658
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In preparation to improvements in models.
Some implementation techniques will want to `new Model()`
without any side-effects.
Part-of: odoo/odoo#133658
__Current behavior before commit:__
`_get_own_attribute_exclusions()` returns the product template attribute
value (ptav) even when `ptav_active` is **false**. This makes the
frontend crash when we add a product that has such ptav to a sale
order.
__Description of the fix:__
Prevent ptavs with `ptav_active = false` to be in the result of
`_get_own_attribute_exclusions()`.
__To reproduce:__
1. Create new Product template
1. Add 2 attributes with at least 2 values each
1. Click on the Configure button next to the first attribute line
1. Click on the first attribute value
1. Add an exclusion line for the newly created product template and one
of the value from the other attribute
1. Put `ptav_active` of the ptav to `false` (not sure how to do it
except from the ORM but one customer managed to do it)
1. Try to add the product to a sale order line
1. `TypeError: Cannot set properties of undefined (setting 'excluded')`
opw-3466451
closesodoo/odoo#133808
X-original-commit: cf58369310f13377cd70794bf777f4e9198f643a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In Saudi Arabia, the InvoiceLine/ID should not be greater than 6 digits.
Using the move.line_id, this limit can be exceeded.
Simply count the invoice line ids starting from 1 instead.
In master, add a parameter `line_id` to `_get_invoice_line_vals`.
closesodoo/odoo#133794
X-original-commit: 3ce90ddf33f59a80de34cbafd05679d0817d0076
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
When the JS client cannot retrieve the online payment data from the server for an order that has no online payment line, and that has been previously saved on the server (and has its server_id defined in JS), an error is thrown if the user confirms that there is no online payment for this order.
This commit fixes this issue.
closesodoo/odoo#133787
Task-id: 3484441
X-original-commit: 129bc21b609d6d3310d038e631f82bae56c14e74
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Crop widget is implemented as div block that is supposed to be displayed on top
of other elements. However, it's not the case for dialogs, because they want to
be on top as well (z-index of dialog is 1050 bootstrap [1])
STEPS:
* Go to Sales Order
* SO
* Schedule an activity
* Use '/' command
* select image
* click image
* crop image
BEFORE: image crop toolbar is hidden behind 'Schedule activity' Pop-up
Fix it by increasing z-index for the crop widget
[1]: https://github.com/odoo/odoo/blob/9102df15cce455205a19fb7b9a0c36186cc51e3a/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L5524
opw-3391583
closesodoo/odoo#133781
X-original-commit: 36c9b2b7916fbbdcfc912d652695699e50043edb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
This commit improves the mail `onChange` method by adding
the support for multiple keys. This will make the code shorter
and easier to read.
closesodoo/odoo#133778
Signed-off-by: Didier Debondt (did) <did@odoo.com>
* mondialrelay, stock
Overrides of `shop_payment_transaction` were retrieving the sale order
from a different way from the parent method, which should be prevented.
The logic is moved to a method on the sale order instead of the
controllers.
Part-of: odoo/odoo#117379
1. In mrp settings, check workorder by default
2. Remove stock for Table leg in demo data
closesodoo/odoo#133758
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Xavier Morel