Thursday, April 25, 2024
34 changes · saas-17.2
Resolved issues and error corrections
This fix prevents website event tests from failing when optional sample or public user data is not installed. It helps keep automated checks stable across leaner setups, reducing false failures for teams validating releases.
Original PR description
Demo / Portal / Public do not necessarily exist. Followup of odoo/odoo#129052 Runbot-60656 Runbot-60655
This update fixes Knowledge app test reliability by using existing test users instead of optional demo or portal users. It helps keep automated validation stable across environments where demo data may not be installed.
Original PR description
Runbot-56122
This update adjusts an internal appointment performance test so it works correctly when demo data is not installed. It helps avoid false failures in automated checks, keeping validation results reliable without changing user-facing appointment behavior.
Original PR description
There is an additional query in no-demo mode; let us avoid useless red runbots. Runbot-62073
This fix updates an internal spreadsheet document test so it simulates a real button click more accurately. It helps keep automated checks stable and reduces false test failures without changing customer-facing features.
Original PR description
Before this commit, the test was not correctly simulating a click on the link chart button. This was due to the fact that the only event that was triggered was the pointerdown event, which is not enough to trigger the click event. For an unknown reason, only triggering the pointerdown event has a side effect during the test to trigger an event handled in the Leatlef library, would lead to an error in the library, and thus in the test suite. This commit fixes the issue by using the click helper function from the web client test helpers. Runbot: 59203
Code cleanup and technical improvements
This change reorganizes an internal test helper used by the web search area, placing it in a more appropriate shared test location while keeping existing access points available. It has no direct effect on end users, but it helps developers maintain and reuse search-related tests more consistently.
Original PR description
This commit moves the test helper `mountWithSearch` to the file `_framework/search_test_helpers` and re-exports it from the file `web_test_helpers`
Miscellaneous changes
Steps to reproduce: - Activate "Analytic Accounting" in Accounting settings - Switch to a mobile view - Go to any view where there is the analytic distribution widget (e.g. expense form) - Try to configure the analytic distribution Issue: When an analytic account is selected, it is not taken into account. Cause: In mobile view, a modal is opened with a kanban view to select the analytic account. Any click on this modal is closing the analytic distribution widget. opw-3734050
Original PR description
Steps to reproduce: - Activate "Analytic Accounting" in Accounting settings - Switch to a mobile view - Go to any view where there is the analytic distribution widget (e.g. expense form) - Try to configure the analytic distribution Issue: When an analytic account is selected, it is not taken into account. Cause: In mobile view, a modal is opened with a kanban view to select the analytic account. Any click on this modal is closing the analytic distribution widget. opw-3734050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162092
Steps to reproduce: - Create a product with 2 vendors - Click replenish on the product page and select the second vendor - The PO is created for the first vendor Bug: the replenishment will create a move which will create/edit a PO the selected supplier is discarded Fix: set the partner on the procurement group to keep track of it note: 'supplierinfo_name' no longer used, will be removed in master related test ("test_procure_not_default_partner") is now irrelevant opw-3776680
Original PR description
Steps to reproduce:
- Create a product with 2 vendors
- Click replenish on the product page and select the second vendor
- The PO is created for the first vendor
Bug:
the replenishment will create a move which will create/edit a PO the selected supplier is discarded
Fix:
set the partner on the procurement group to keep track of it
note:
'supplierinfo_name' no longer used, will be removed in master related test ("test_procure_not_default_partner") is now irrelevant
opw-3776680
Forward-Port-Of: odoo/odoo#161974**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the va
Original PR description
**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the value will be the amount in the currency used in the bill **Desired behavior after PR is merged:** We now create the fleet service using the value in debit not the unit price or the price subtotal. opw-3734743 Forward-Port-Of: odoo/odoo#155632
This traceback arises when the user tries to remove the `start date` Steps to produce 1. Install `resource` 2. Open `Settings/Technical/resource/Resource Time Off` 3. Create a new record and remove the `start date` Error: ```AttributeError: 'bool' object has no attribute 'tzinfo' File "odoo/http.py", line 2251, in __call__ response = request._serve_db() File "odoo/http.py", line 1826, in _serve_db return self._transactioning(_serve_ir_http, readonly=ro) File "odoo
Original PR description
This traceback arises when the user tries to remove the `start date` Steps to produce 1. Install `resource` 2. Open `Settings/Technical/resource/Resource Time Off` 3. Create a new record and remove…
This traceback arises when the user tries to remove the `start date`
Steps to produce
1. Install `resource`
2. Open `Settings/Technical/resource/Resource Time Off`
3. Create a new record and remove the `start date`
Error:
```AttributeError: 'bool' object has no attribute 'tzinfo'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1073, in onchange
todo = [
File "addons/web/models/models.py", line 1076, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1189, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6664, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4982, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/resource/models/resource_calendar_leaves.py", line 58, in _compute_date_to
date_to_tz = user_tz.localize(leave.date_from) + relativedelta(hour=23, minute=59, second=59)
File "pytz/tzinfo.py", line 317, in localize
if dt.tzinfo is not None:
```
when the user tries to remove the start date, an error will be produced because _compute_date_to seems to be computing the date_to based on the date_from field. when removing the `date_from` from calculations on empty or none
which leads to traceback from here
https://github.com/odoo/odoo/blob/322e7ea19b7c069fdb92d3b86e5615c55489ca21/addons/resource/models/resource_calendar_leaves.py#L54-L59
This PR solves the above issue by computing `date_to` for records that have
`date_from`. Apart from that, this PR also removes `# -*- coding: utf-8 -*-`
from the first line of the modified file.
sentry-4983497879
Forward-Port-Of: odoo/odoo#163136
Forward-Port-Of: odoo/odoo#154555Use an ir.config_parameters to set the period for the stock quantity report to ease customization. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163017
Original PR description
Use an ir.config_parameters to set the period for the stock quantity report to ease customization. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163017
The `test_update_workcenter_adapt_finish_date` test was not consistent when the db was installed without demo data. The test was failing because the working hours were not the same and so the duration was different. To fix this we adjust the starting time of the work order so that it last exactly 30 minutes, and is not impacted by the working hours. runbot error : https://runbot.odoo.com/web#id=61595&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=form --- I confirm I hav
Original PR description
The `test_update_workcenter_adapt_finish_date` test was not consistent when the db was installed without demo data. The test was failing because the working hours were not the same and so the duration was different. To fix this we adjust the starting time of the work order so that it last exactly 30 minutes, and is not impacted by the working hours. runbot error : https://runbot.odoo.com/web#id=61595&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=form --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162074
Current behavior: When trying to print a receipt offline, the image will not be loaded and you get a traceback. Now the receipt is printed, and an error is logged in the console if the images couldn't be loaded Steps to reproduce: - Add a logo to the company - Launch PoS - In the browser devtools network tab turn the connection down - Do an order, and try to print the receipt - You get a traceback and the receipt is not printed opw-3811663 --- I confirm I have signed the CLA and
Original PR description
Current behavior: When trying to print a receipt offline, the image will not be loaded and you get a traceback. Now the receipt is printed, and an error is logged in the console if the images couldn't be loaded Steps to reproduce: - Add a logo to the company - Launch PoS - In the browser devtools network tab turn the connection down - Do an order, and try to print the receipt - You get a traceback and the receipt is not printed opw-3811663 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163042 Forward-Port-Of: odoo/odoo#162451
Current behavior: If you make a sale of a product that use a taxe not included in the price. Then go in order analysis in PoS, the total price of the product will not include the taxes. Steps to reproduce: - Create a tax of 15% that is not included in price - Create a product with 10$ price and add this tax to it. (Total price including tax should be 11.5$) - Sell it in the PoS and close the session - Go in PoS > Reporting > Order. Open the pivot view and check the total price for the pr
Original PR description
Current behavior: If you make a sale of a product that use a taxe not included in the price. Then go in order analysis in PoS, the total price of the product will not include the taxes. Steps to reproduce: - Create a tax of 15% that is not included in price - Create a product with 10$ price and add this tax to it. (Total price including tax should be 11.5$) - Sell it in the PoS and close the session - Go in PoS > Reporting > Order. Open the pivot view and check the total price for the product - The total is 10$ instad of 11.5$ opw-3817535 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162984 Forward-Port-Of: odoo/odoo#162883
Some people want to manage the subcontractor stock the same way than a classic stock. It will then impact the on hand value but it's the behavior they want. I keep the constraint on internal location since it will impact valuation. 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 Forward-Port-Of: odoo/odoo#163177
Original PR description
Some people want to manage the subcontractor stock the same way than a classic stock. It will then impact the on hand value but it's the behavior they want. I keep the constraint on internal location since it will impact valuation. 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 Forward-Port-Of: odoo/odoo#163177
When a DB is duplicated, it's going through the neutralize process which is helpful to clean stuff that will be messing around with the duplicated DB. The CDN should actually be part of that. Since a CDN url is bound to a domain, when you copy the database (and most likely run it on its own different domain), it just won't properly work. Indeed, if you setup a CDN X for domain A and then copy a DB to domain B, this will happen: - You access website B - You try to load an img, which is us
Original PR description
When a DB is duplicated, it's going through the neutralize process which is helpful to clean stuff that will be messing around with the duplicated DB. The CDN should actually be part of that. Since a…
When a DB is duplicated, it's going through the neutralize process which is helpful to clean stuff that will be messing around with the duplicated DB. The CDN should actually be part of that. Since a CDN url is bound to a domain, when you copy the database (and most likely run it on its own different domain), it just won't properly work. Indeed, if you setup a CDN X for domain A and then copy a DB to domain B, this will happen: - You access website B - You try to load an img, which is using CDN X URL - CDN X URL is fetching the ressource on DB A instead of DB B, which might or might not exist (an image will likely share the same path so it might work, but for assets url it might not if the bundle url has changed) In the event of the assets having changed, they will never be loaded and the duplicated DB won't be loading properly. The only workaround in this case is to switch to debug mode to bypass the post processing and so the CDN url transform. Useful commits: - Introduction of neutralize https://github.com/odoo/odoo/pull/67825 - Conversion of neutralize from ORM calls to raw SQL https://github.com/odoo/odoo/commit/e5dbded9bb363351feff7ca8a56c7f8a6860f492 opw-3880102 Forward-Port-Of: odoo/odoo#163109
### Adjust disabled input colors (*1) 1. Maintain border consistency of frontend inputs : Prior to this PR, `form-select` borders overlapped the background color, which is not the case with `form-control`. This is because `form-control` uses the `background-clip` property. As we're using a semi-transparent border on frontend inputs, this creates a color issue: when a `form-select` input is disabled, the border color is darker than that of the `form-control`. This PR adapts the `background-c
Original PR description
### Adjust disabled input colors (*1) 1. Maintain border consistency of frontend inputs : Prior to this PR, `form-select` borders overlapped the background color, which is not the case with…
### Adjust disabled input colors (*1) 1. Maintain border consistency of frontend inputs : Prior to this PR, `form-select` borders overlapped the background color, which is not the case with `form-control`. This is because `form-control` uses the `background-clip` property. As we're using a semi-transparent border on frontend inputs, this creates a color issue: when a `form-select` input is disabled, the border color is darker than that of the `form-control`. This PR adapts the `background-clip` on `form-select` input to maintain color consistency between inputs. 2. Make disabled inputs more recognizable : Prior to this PR, disabled inputs were not sufficiently distinct from regular inputs, especially `website_sale` inputs which had a gray background. **Steps to reproduce:** - Make sure your instance has`website_sale_renting` installed. - Go to the Shop page. - Look for a product with a rental period (eg. Printer). - Click on Add to cart, this will disable the rental period input. - -> The gray search bar and the disabled input have almost the same style This PR adapts the style of disabled inputs in the frontend to make them more recognizable. --- ### Adjust dropdown caret color (*2) Prior to this PR, dropdown inputs had a color issue in frontend: the caret color of `form-select` was dark regardless of the input's background and didn't provide enough contrast when we defined a dark background on the page. **Steps to reproduce:** - Go to the Contact page. - Click on Edit. - Click on Theme tab. - Replace the fourth color with a dark one (ex. black). - Click on the form in the page. - Add a field. - Select the new field and choose the "Selection" type. - Click on Save. - -> The dropdown caret is not enough visible. --- ### Adjust `form-check-input` colors (*3) This PR adjusts the caret color to make sure that this will be always visible. Prior to this PR, checkboxes, radios and switch inputs had a color issue in frontend: as the inner element (eg. check mark) was always white if the user changed the primary color to a bright one, the inputs were no longer readable. **Steps to reproduce:** - Go to the Contact page. - Click on Edit. - Click on Theme tab. - Replace the primary color with a bright one (ex. light gray). - Click on the form in the page. - Add a field. - Select the new field and choose the "Radio Buttons" or " Checkbox" type. - Click on Save. - Check the checkbox or the radio button. - -> The check mark or the dot is not visible enough. This PR adjusts the colors to ensure that these inputs will always be visible. --- ### Adjust `form-range` track color (*4) Prior to this PR, the `form-range` track color used the light color. This created a color inconsistency with the rest of the UI when we changed the third color. **Steps to reproduce:** - Go to the Shop page. - Click on Edit. - Click on the page and make sure "Price Filter" is active in the Web Editor. - Go to Theme tab. - Change color-3 (light) to another one (eg. red). This PR adjusts the color to maintain consistency with the rest of UI elements --- ### Adjust custom dropdown caret (*5) Prior to this PR, the custom dropdown caret in the `website_sale` sidebar didn't handle the "multiple" attribute, unlike the default dropdown. If we decided to add a "multiple" attribute to this element, the caret remained displayed, which created a design issue. This PR adapts the caret of this dropdown so that it works correctly when this attribute is defined. --- task-3702675 --- | (*1) | Before | After | | -- | - | - | | Portal |  |  | | Website (light bg) |  |  | | Website (dark bg) |  |  | | (*2) | Before | After | | -- | - | - | | Adjust dropdown caret color |  |  | | (*3) | Before | After | | -- | - | - | | Adjust `form-check-input` colors |  |  | | (*4) | Before | After | | -- | - | - | | Adjust `form-range` track color |  |  | | (*5) | Before | After | | -- | - | - | | Adjust custom dropdown caret |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150886
Steps to reproduce: - - Create an SO with an SOL and save the record. **The `qty_delivered` of that SOL will be null in the DB.** Cause of the issue: - Since the `qty_delivered` field is computed, the default value is set in the DB comes from the `_compute_qty_delivered` method at record creation. However, no default value is set here when the `qty_delivered_method` is not `'analytic'`. ### Note: In 15.0, a default value was set because of these lines: https://github.com/odoo/od
Original PR description
Steps to reproduce: - - Create an SO with an SOL and save the record. **The `qty_delivered` of that SOL will be null in the DB.** Cause of the issue: - Since the `qty_delivered` field is computed, the default value is set in the DB comes from the `_compute_qty_delivered` method at record creation. However, no default value is set here when the `qty_delivered_method` is not `'analytic'`. ### Note: In 15.0, a default value was set because of these lines: https://github.com/odoo/odoo/blob/313418804ae5cb6a786488ffc174b8eebffb796e/addons/sale/models/sale_order_line.py#L350-L353 These were removed by this commit de4911a. opw-3771589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156917
This PR fixes 2 reasons for toolbar flickering: - when hovering over the colorpicker if the selection was made from right to left, because the selection would be reset by `_processAndApplyColor` to a left to right direction, which caused the toolbar position to be recalculated. - when hovering over the colorpicker's "reset" button, regardless of the selection direction, if the selection still contained font elements after the call to the "applyColor" commmand with a falsy `color` param
Original PR description
This PR fixes 2 reasons for toolbar flickering: - when hovering over the colorpicker if the selection was made from right to left, because the selection would be reset by `_processAndApplyColor` to a left to right direction, which caused the toolbar position to be recalculated. - when hovering over the colorpicker's "reset" button, regardless of the selection direction, if the selection still contained font elements after the call to the "applyColor" commmand with a falsy `color` parameter. This can happen, for example, when hovering over the Background Color colorpicker's "reset" button while having a selection containing a font element for foreground color. This would make the selection to be set around the remaining font element, leading to a toolbar repositioning. task-3700731 Forward-Port-Of: odoo/odoo#150841
Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund. Steps to reproduce: ------------------- * Setup a rounding method with
Original PR description
Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the…
Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund. Steps to reproduce: ------------------- * Setup a rounding method with a precision of 5.0 * Create a product with a price of 138.0 * Open the POS and add the product to the order * Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80. * Validate the order * Go in the backend and refund the order * The refund will be rounded to 135.0 Why the fix: ------------ The new behavior after this fix: * When refunding the entire original order, the amount to refund should be equal to what the customer paid on the original order (thus taking into account the rounding). * When doing a partial refund, the amount that should be refunded correspond to the base price of the article(s) selected. The issue was about the fact that refunds differed in prices compared to the original order. With this fix, there could still be a difference in the prices if a customer comes multiple times to do a partial refund and end up refunding the total order. This difference exists only if the original order was paid with rounding and will be maximum the rounding defined. Since this is a rare event, we consider this difference to be acceptable. Post-fixup: ----------- The function `_get_rounded_amount()` was modified as we are not computing cash rounding when refunding anymore. opw-3701574 Forward-Port-Of: odoo/odoo#162441 Forward-Port-Of: odoo/odoo#161564
Usecase to reproduce: - Product wiht a real time valuation - Product with invoice on delivered quantity - Create a SO for 5 units and 1000$ each - Do a full downpayment of 100% of quotation - Deliver 3 out of 5 units and create a backorder - Create an invoice - Validate the invoice Expected behavior: The cogs entries are there Current behavior: No cogs It only happens with partial downpayment. When the downpayment amount equals the quotation amount. An invoice is created instea
Original PR description
Usecase to reproduce: - Product wiht a real time valuation - Product with invoice on delivered quantity - Create a SO for 5 units and 1000$ each - Do a full downpayment of 100% of quotation - Deliver…
Usecase to reproduce: - Product wiht a real time valuation - Product with invoice on delivered quantity - Create a SO for 5 units and 1000$ each - Do a full downpayment of 100% of quotation - Deliver 3 out of 5 units and create a backorder - Create an invoice - Validate the invoice Expected behavior: The cogs entries are there Current behavior: No cogs It only happens with partial downpayment. When the downpayment amount equals the quotation amount. An invoice is created instead of a credit note and the process works correctly. It happens because it creates a credit note with a negative quantity to invoice so the system doesn't understand it has to create the cogs at that point. 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 Forward-Port-Of: odoo/odoo#161768 Forward-Port-Of: odoo/odoo#161098
### Steps to reproduce: - Install **POS** app. - Go to **POS** settings and enable: - Is a Bar/Restaurant - Tips > Add tip after payment - Open a POS session -if first time, add a floor and a table- - Add a product - Click on **payment** - Choose a payment method - Click on **Close Tab** - The print popup is shown twice in a row with an empty receipt. ### Investigation: Investigation: - Inside the `TipReceipt` template, the `total` is not shown as the class lacks a gette
Original PR description
### Steps to reproduce:
- Install **POS** app.
- Go to **POS** settings and enable:
- Is a Bar/Restaurant
- Tips > Add tip after payment
- Open a POS session -if first time, add a floor and a table-
- Add a product
- Click on **payment**
- Choose a payment method
- Click on **Close Tab**
- The print popup is shown twice in a row with an empty receipt.
### Investigation:
Investigation:
- Inside the `TipReceipt` template, the `total` is not shown as the class lacks a getter for it https://github.com/odoo/odoo/blob/1d49034782e3ff0e4384bad4e927a895e2a97839/addons/pos_restaurant/static/src/app/tip_receipt/tip_receipt.xml#L13-L16
- Also when there is no printer, we won't fallback to the web printer as it's annoying to the cashier.
opw-3836549
Forward-Port-Of: odoo/odoo#161056Single value graph were not shown in cumulated graph. This is due to unshift happening before the accumulator, leading to `undefined + X = NaN` for the value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162247
Original PR description
Single value graph were not shown in cumulated graph. This is due to unshift happening before the accumulator, leading to `undefined + X = NaN` for the value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162247
build-error: 55926 Forward-Port-Of: odoo/odoo#163107
Original PR description
build-error: 55926 Forward-Port-Of: odoo/odoo#163107
issue generated during upgrade. when it's try to find journal with journal_data['code'] and translated_code, wil get two journal, and that will raise exception as signtone error there are two journal with 1. INV code 2. FAC code as translated code so will get two journal and got traceback ``` select name,id, code from account_journal where id in (12,13); name | id | code ------------------------------------------------
Original PR description
issue generated during upgrade. when it's try to find journal with journal_data['code'] and translated_code, wil get two journal, and that will raise exception as signtone error there are two journal…
issue generated during upgrade.
when it's try to find journal with journal_data['code'] and translated_code, wil get two journal,
and that will raise exception as signtone error
there are two journal with 1. INV code
2. FAC code as translated code so will get two journal and got traceback
```
select name,id, code from account_journal where id in (12,13);
name | id | code
----------------------------------------------------------------------+----+------
{"en_US": "Factures clients", "fr_BE": "Factures clients"} | 12 | FAC
{"en_US": "Factures fournisseurs", "fr_BE": "Factures fournisseurs"} | 13 | INV
(2 rows)
File "/tmp/tmpwqzy2fx8/migrations/account/saas~16.2.1.2/end-migrate.py", line 50, in migrate
ChartTemplate._pre_reload_data(company, template_data, data)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 264, in _pre_reload_data
self.env['ir.model.data']._update_xmlids([{
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2270, in _update_xmlids
rows.add((prefix, suffix, record._name, record.id, noupdate))
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 5142, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.journal(12, 13)
```
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
Forward-Port-Of: odoo/odoo#163022
Forward-Port-Of: odoo/odoo#162388**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the va
Original PR description
**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the value will be the amount in the currency used in the bill **Desired behavior after PR is merged:** We now create the fleet service using the value in debit not the unit price or the price subtotal. opw-3734743 Forward-Port-Of: odoo/enterprise#57639
Purpose: -------- Add a button in the front end view that allows users to end the current booking (to make the room appear as free), as the only way to do it for now is to delete the booking, which is not suitable if one would like to track the bookings in the backend view. The "book now" button is reworded to "start now" and the "schedule booking" button to "Add a booking" because it was observed that users were sometimes confused with these two buttons. The "booked room" icon has be
Original PR description
Purpose: -------- Add a button in the front end view that allows users to end the current booking (to make the room appear as free), as the only way to do it for now is to delete the booking, which is not suitable if one would like to track the bookings in the backend view. The "book now" button is reworded to "start now" and the "schedule booking" button to "Add a booking" because it was observed that users were sometimes confused with these two buttons. The "booked room" icon has been changed to not use the same as in the new "end booking "button. Colors of the buttons have been updated. The remaining time is now centered vertically in all display formats (it was not always the case). Task-3792497 Forward-Port-Of: odoo/enterprise#61300
Steps to Reproduce: - Install Timesheets app - Navigate to All timesheets from the header menu - Click on kanban view Issue: - Timer is present in the All timesheets Kanban view Causes: - Timer is present in the All timesheet kanban view because this view is inherited in my time sheets. Solution: - Using the context that is only used in MyTimeSheet Action window to hide the timer header (my_timesheet_display_timer) task-3741260 Forward-Port-Of: odoo/enterprise#61349 Fo
Original PR description
Steps to Reproduce: - Install Timesheets app - Navigate to All timesheets from the header menu - Click on kanban view Issue: - Timer is present in the All timesheets Kanban view Causes: - Timer is present in the All timesheet kanban view because this view is inherited in my time sheets. Solution: - Using the context that is only used in MyTimeSheet Action window to hide the timer header (my_timesheet_display_timer) task-3741260 Forward-Port-Of: odoo/enterprise#61349 Forward-Port-Of: odoo/enterprise#56581
To reproduce: - Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance" - Create another report, containing a single line with code line_2_1. Give it two expressions: - One aggregation, with formula="14.0" (hardcoded fixed value), and subformula "if_other_expr_above(line_2_1.dudu, EUR(0))" - Another expression of any engine labelled 'dudu' ==> Try opening the first report; it loads forever. This i
Original PR description
To reproduce: - Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance" - Create another report, containing a single…
To reproduce:
- Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance"
- Create another report, containing a single line with code line_2_1. Give it two expressions: - One aggregation, with formula="14.0" (hardcoded fixed value), and subformula "if_other_expr_above(line_2_1.dudu, EUR(0))"
- Another expression of any engine labelled 'dudu'
==> Try opening the first report; it loads forever.
This is because the bound expression is only searched in the expressions of the active report ; not in the expressions loaded from other reports. In our case, the aggregation needing the bound is from the second report, so the bound belongs to its report as well. The looping occurs because that value, since it's not present in the first report's evaluated data, is considered as not yet computed, and the computation is continuously delayed at the end of the treatment queue, causing it to never become empty.
Forward-Port-Of: odoo/enterprise#61334
Forward-Port-Of: odoo/enterprise#58339Steps to reproduce: 1. Configure Sendcloud shipping with pick-up location 2. Go to website, use the shipping method and select a pick-up location 3. Go to the backend, confirm the sale order and validate the delivery 4. Get Error from Sendcloud that the `house_number` is required If we check the delivery address, we see that the house number is not taken into account when creating a new partner, and the address is incomplete. This commit adds the house number to the `street` field of t
Original PR description
Steps to reproduce: 1. Configure Sendcloud shipping with pick-up location 2. Go to website, use the shipping method and select a pick-up location 3. Go to the backend, confirm the sale order and validate the delivery 4. Get Error from Sendcloud that the `house_number` is required If we check the delivery address, we see that the house number is not taken into account when creating a new partner, and the address is incomplete. This commit adds the house number to the `street` field of the address to have a complete address. opw-3864382 Forward-Port-Of: odoo/enterprise#61290
Since the wrong module set on the maintenance worksheets, this would lead to issues when trying to uninstall the maintenance module, as it wouldn't find every models to uninstall. This ended up leaving some entries in the database after the module was removed. runbot-57422 Forward-Port-Of: odoo/enterprise#61355
Original PR description
Since the wrong module set on the maintenance worksheets, this would lead to issues when trying to uninstall the maintenance module, as it wouldn't find every models to uninstall. This ended up leaving some entries in the database after the module was removed. runbot-57422 Forward-Port-Of: odoo/enterprise#61355
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the account_partial_reconcile table. Currently, the entire account_partial_reconcile table is being iterated in the report generation, only to be filtered out later on in the query. This superfluous computation is extremely inefficient and it could be easily avoided by correctly using LATERAL JOIN s
Original PR description
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the…
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the account_partial_reconcile table. Currently, the entire account_partial_reconcile table is being iterated in the report generation, only to be filtered out later on in the query. This superfluous computation is extremely inefficient and it could be easily avoided by correctly using LATERAL JOIN syntax to make use of the filters applied later on.  # Fix: Use the correct condition inside the lateral join to filter on account_move_lines that are already filtered later on. # Benchmark: ### Report loading time | # account partial reconcile lines | # account move lines | Company size | Before | After | | --- | ------ | ------ | ------| ----- | | 588503 | 2339215 | Large | 15m+ (timeout) | ~14.02s | | 5761 | 27635 | Medium | 15m+ (timeout) | ~3s | | 11 | 1513 | Small | 7.69 | ~1.6s | #### Total number of account partial reconcile: 3279438 #### Total number of account move lines: 10688953 # Related ticket: opw-3819017 Forward-Port-Of: odoo/enterprise#61036
Sources: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/intermediates#bonus-a-l-emploi-plafonds-apres-l-augmentation-du-rmmmg-et-la-scission-du-calcul-29-03-2024 https://www.ucm.be/actualites/le-bonus-lemploi-renforce-au-1er-avril-2024#:~:text=Qu'est-ce%20que%20le,salaire%20net%20effectif%20est%20augment%C3%A9 Forward-Port-Of: odoo/enterprise#61358
Original PR description
Sources: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/intermediates#bonus-a-l-emploi-plafonds-apres-l-augmentation-du-rmmmg-et-la-scission-du-calcul-29-03-2024 https://www.ucm.be/actualites/le-bonus-lemploi-renforce-au-1er-avril-2024#:~:text=Qu'est-ce%20que%20le,salaire%20net%20effectif%20est%20augment%C3%A9 Forward-Port-Of: odoo/enterprise#61358
https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/special_contributions/other_specialcontributions/asbestosfunds.html Forward-Port-Of: odoo/enterprise#61135
Original PR description
https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/special_contributions/other_specialcontributions/asbestosfunds.html Forward-Port-Of: odoo/enterprise#61135
Steps to reproduce: ------------------- - create an appraisal for an employee; - be the manager of the appraisal; Issue: ------ It is not possible to edit feedback before saving it. Cause: ------ The `accessible_employee_feedback` and `accessible_manager_feedback` fields are read only if `can_see_employee_publish` and `can_see_manager_publish` are equal to `False`. These two fields depend on the `_compute_buttons_display` method, which will test whether the employees linked to the
Original PR description
Steps to reproduce: ------------------- - create an appraisal for an employee; - be the manager of the appraisal; Issue: ------ It is not possible to edit feedback before saving it. Cause: ------ The `accessible_employee_feedback` and `accessible_manager_feedback` fields are read only if `can_see_employee_publish` and `can_see_manager_publish` are equal to `False`. These two fields depend on the `_compute_buttons_display` method, which will test whether the employees linked to the user are in the appraisal managers. The following condition will never be true if the appraisal has not yet been saved: ```py user_employees in appraisal.manager_ids ``` This is because manager_ids will be a `NewId` recordset. Solution: --------- It is necessary to compare ids and not records directly because Model does not support equality between existed records in database and virtual records. opw-3869446 Forward-Port-Of: odoo/enterprise#61221