Saturday, November 25, 2023
26 changes · 17.0
Resolved issues and error corrections
This fixes a crash in the Accounting invoice analysis pivot report when users collapse a column group and then expand it by month. The report now uses the correct date grouping, so business users can analyze invoices by month without interruption.
Original PR description
Accounting > Reporting > Invoice Analysis Open Pivot View Collapse column group, expand by Date>Month StopInteration traceback will raise line: column = self._read_group_postprocess_aggregate(spec, next(column_iterator)) The error is caused by a missing interval attribute on the group by pivot view default search. This will make the view call `read_group` with a wrong groupby list ['invoice_date', 'invoice_date:month'], that will cause the error raise opw-3603433 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
Fixes an issue where module loading errors could make the web test suite appear blank instead of showing the problem. This helps teams diagnose test failures faster and keeps automated quality checks clearer.
Original PR description
Since the module loader rewrite, it now reports errors directly in the DOM. The error alert also has the class "modal" so that in case a tour comes accross a page with module loading errors, it will only look for elements inside it and fail. But in the QUnit test suite, modals are invisible by default, causing the page to be blank in those cases. This commit adds a css rule to make sure that this error alert is shown, and updates the code that was previously used to report these errors in the qunit suite to instead simply check for errors reported by the module loader.
Downloading a preview of an invoice that has not yet been confirmed no longer triggers an error. The system now only allows PDF download handling when the invoice is posted, improving reliability for users working with draft invoices.
Original PR description
Steps to reproduce: ------------------- - create an invoice without confirm it; - go to the preview and download it; Issue: ------ A traceback appears. Cause: ------ We try to get `ids` field of a non "record" object (not the root cause). The root cause is that we don't create an attachment if the invoice is not posted. And to post an invoice, we must add line before confirm it. Solution: --------- Make sure you are in the case of an invoice that is `posted` to download a pdf. sentry-4612532780
This fix prevents event website pages from showing an error when a visitor's browser does not support service workers. It keeps the experience stable for affected visitors instead of displaying a technical crash dialog.
Original PR description
PR [1] removed the legacy error handler that swallowed promise rejection errors with anything else than an error (namely, the "legacyRejectPromiseHandler"). As a consequence, promise rejections done as "control flow" now lead to error dialogs being displayed. In particular, it happened on the website (with website_event_track installed), if the browser doesn't support service workers. This commit simply leaves the promise pending if the feature is unavailable. [1] https://github.com/odoo/odoo/pull/137702 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
This fix ensures datetime range fields correctly understand when they are required. It prevents unnecessary extra date inputs from appearing and avoids validation issues in debug mode, improving form reliability for users.
Original PR description
Previously, the datetime field read the value for required directly in the attrs when extracting its props when available. This resulted in 2 separate bugs: - in debug mode, props validation of the…
Previously, the datetime field read the value for required directly in the attrs when extracting its props when available. This resulted in 2 separate bugs: - in debug mode, props validation of the datetime picker would fail, as it expects to receive a boolean for the `range` prop. This was caused by the fact that required was the raw attribute (a string) instead of the boolean and ended up being propagated to the `range` prop - outside of debug mode, the value for required did not cause a crash but any value for required that was not empty would be interpreted as truthy, causing the field to always be display itself as though it is required. In non-range mode, this is invisible, but in range mode, it would always show the second datetime input and the arrow between the beginning and end date, even with required being 0/False, or a python expression that may evaluate to false This commit fixes that by instead reading the value for required from the dynamic infos provided to `extractProps`, which will always be a boolean and contain the value of the evaluated expression when appropriate.
This update fixes a technical issue in the Planning module where an outdated translation function was replaced with the current standard. This ensures the module continues to work properly with the latest system updates and maintains compatibility with the current codebase.
Original PR description
In this commit we fix _lt with _t. Let's see more informations on https://github.com/odoo/odoo/pull/124157
Fixed a visual bug in the timesheet timer where selecting a project or task caused unwanted extra height to appear on mobile devices. The issue was caused by an oversized arrow button (1.3em) that was pushing content down. The fix reduces the button size through a new stylesheet to maintain consistent layout when making selections.
Original PR description
**Steps:** - Open timesheet - Switch to mobile view - Start the timer - Select a Project / Task from dropdown - (Appears in all the views) **Issue:** - When a project/task is selected, extra height appears beneath it **Cause:** - The extra height is caused due to the arrow button which has a size of 1.3em **Fix:** - Making a new scss file for this instead of changing in base files and adding style to reduce the size of the button. **Task:** 3387850 Forward-Port-Of: odoo/enterprise#43428
This update corrects how fuel type information is stored and displayed for company vehicles in the Belgian payroll system. The fix ensures that fuel type selections are handled properly without storing unnecessary data in the database, maintaining compliance with system policies while preserving the ability to show fuel types for new vehicles.
Original PR description
https://github.com/odoo/enterprise/pull/47717 fixed the display of the fuel type for a new car, as it was not being shown. However, the change from that PR was not respecting stable policy. This commit fixes this by changing the selection values from a static list to a lambda function that returns that list This makes the selection values not be stored in the database. Forward-Port-Of: odoo/enterprise#51297
Miscellaneous changes
The unit prices should always be positives in the Peppol Bis 3 xml, otherwise, a validator will raise "[BR-27]-The Item net price (BT-146) shall NOT be negative.". Add a constraint in the code to ensure this. task-3607341 Forward-Port-Of: odoo/odoo#143531 Forward-Port-Of: odoo/odoo#143161
Original PR description
The unit prices should always be positives in the Peppol Bis 3 xml, otherwise, a validator will raise "[BR-27]-The Item net price (BT-146) shall NOT be negative.". Add a constraint in the code to ensure this. task-3607341 Forward-Port-Of: odoo/odoo#143531 Forward-Port-Of: odoo/odoo#143161
The following situation happened with module `industry_fsm`, when trying to delete a cancelled sales order corresponding to a task. When doing so, the server crashes with error "Could not find all values of X to flush them", which means that a dirty field (pending update) has lost its value from cache. The issue is related to recursive computed fields. Before deleting a record, method `unlink()` invokes `modified()`, which determines all the fields that depend on the record to be deleted,
Original PR description
The following situation happened with module `industry_fsm`, when trying to delete a cancelled sales order corresponding to a task. When doing so, the server crashes with error "Could not find all…
The following situation happened with module `industry_fsm`, when trying to delete a cancelled sales order corresponding to a task. When doing so, the server crashes with error "Could not find all values of X to flush them", which means that a dirty field (pending update) has lost its value from cache. The issue is related to recursive computed fields. Before deleting a record, method `unlink()` invokes `modified()`, which determines all the fields that depend on the record to be deleted, and marks them to recompute. Those fields should be recomputed after the record is deleted, and not before. We found out that the recursive call to `modified()` made for recursive fields can force the recomputation of the recursive field itself before the record is deleted, which causes `unlink()` to crash. The fix consists in marking the fields for recomputation at the very end of method `modified()`, after all the fields to recompute have been determined. This ensures that the processing of recursive fields always uses the current value of the field instead of its recomputed value. Forward-Port-Of: odoo/odoo#143267 Forward-Port-Of: odoo/odoo#142712
Since odoo/odoo@b3a2fb51bc48b83, it is not possible to use partial points rewards. However this commit only fixes the behavior for loyalty cards, where it should be applied to many other program types. Forward-Port-Of: odoo/odoo#143334
Original PR description
Since odoo/odoo@b3a2fb51bc48b83, it is not possible to use partial points rewards. However this commit only fixes the behavior for loyalty cards, where it should be applied to many other program types. Forward-Port-Of: odoo/odoo#143334
*product_configurator, comparison, stock Before this commit, the option "Prevent Sale of Zero Price Product" would still allow some free products to be added to the cart (accessory, optional and alternative products). This commit makes sure no free product can be added to cart if this option is activated. task-2983615 Forward-Port-Of: odoo/odoo#143563 Forward-Port-Of: odoo/odoo#137298
Original PR description
*product_configurator, comparison, stock Before this commit, the option "Prevent Sale of Zero Price Product" would still allow some free products to be added to the cart (accessory, optional and alternative products). This commit makes sure no free product can be added to cart if this option is activated. task-2983615 Forward-Port-Of: odoo/odoo#143563 Forward-Port-Of: odoo/odoo#137298
During upgrade, it try to create picking type if not exist like pos type and everytime will create new sequence too for that picking type. during the creation of picking type there is python constraints that raised if same sequence name with same company exist. so to avoid that will check before creating new sequence if already same company sequence exist then update the sequence name with id. Description of the issue/feature this PR addresses: Current behavior before PR: Desired beha
Original PR description
During upgrade, it try to create picking type if not exist like pos type and everytime will create new sequence too for that picking type. during the creation of picking type there is python constraints that raised if same sequence name with same company exist. so to avoid that will check before creating new sequence if already same company sequence exist then update the sequence name with id. 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#139277
Issue: ====== When we have a product as a free product reward in cart and we want to add the same product from the shop nothing will happen and the cart stays the same. Steps to reproduce the issue: ============================= - Create a loyalty program with the following options: type: pormotions rule: minimum quantity :1 , gran 1, minimum purchase 0, per order, product: select anyone reward: type : free product , quantity rewarded : 1, product : select any other product - Go to we
Original PR description
Issue: ====== When we have a product as a free product reward in cart and we want to add the same product from the shop nothing will happen and the cart stays the same. Steps to reproduce the issue: ============================= - Create a loyalty program with the following options: type: pormotions rule: minimum quantity :1 , gran 1, minimum purchase 0, per order, product: select anyone reward: type : free product , quantity rewarded : 1, product : select any other product - Go to website and add the product from the rule to cart - Go to cart and claim reward - Go back to shop and add the product from the reward to cart - Go to cart - The cart stays the same Issue: ====== When searching for the `line` it doesn't consider if the line is a reward or not. Solution: ========= We filter the reward lines if `line_id=False` opw-3550585 Forward-Port-Of: odoo/odoo#143464 Forward-Port-Of: odoo/odoo#142827
All the stock widgets are exported except for StockReschedulingPopover. Export it so that it can be used elsewhere. Additionally, fix the name of the class to correct a typo. Forward-Port-Of: odoo/odoo#135971
Original PR description
All the stock widgets are exported except for StockReschedulingPopover. Export it so that it can be used elsewhere. Additionally, fix the name of the class to correct a typo. Forward-Port-Of: odoo/odoo#135971
## [FIX] account_peppol: shorten cron interval Update participant status every 6 hours instead of once a day. Once a day is too slow for users and it looks as if something went wrong. ## [FIX] account_peppol: disable peppol for certain edi formats If the format set on a partner does not work for our peppol implementation, `enable_peppol` should be `False` and the checkbox should be hidden. This commit checks invalid partners when computing `enable_peppol` on account_move_send wizard. Sinc
Original PR description
## [FIX] account_peppol: shorten cron interval Update participant status every 6 hours instead of once a day. Once a day is too slow for users and it looks as if something went wrong. ## [FIX] account_peppol: disable peppol for certain edi formats If the format set on a partner does not work for our peppol implementation, `enable_peppol` should be `False` and the checkbox should be hidden. This commit checks invalid partners when computing `enable_peppol` on account_move_send wizard. Since we hide the checkbox in this case, we don't need to show the peppol warning when opening send&print to such partners. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142166
Issue: ====== When we settle an order that has a product with uom not pos_groupable and quantity isn't an integer for example 3.5 it will add 4 lines each with quantity = 1 which is not correct. Steps to reproduce the issue: ============================= - Create a product with a not pos_groupable uom (kg for example) - Create a sale order with that prouct and add a not integer quantity - Go to pos and settle the order - You will have 4 lines added each with quantity = 1 Origin of t
Original PR description
Issue: ====== When we settle an order that has a product with uom not pos_groupable and quantity isn't an integer for example 3.5 it will add 4 lines each with quantity = 1 which is not correct. Steps to reproduce the issue: ============================= - Create a product with a not pos_groupable uom (kg for example) - Create a sale order with that prouct and add a not integer quantity - Go to pos and settle the order - You will have 4 lines added each with quantity = 1 Origin of the issue: ==================== The quantity was hardcoded = 1 Solution: ========= I addeed order lines equal to the integer part of quantity and one last order line that have the rest quantity. opw-3579225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143390 Forward-Port-Of: odoo/odoo#141233
The additional lines originating from the product configurator are sometimes not well handled by the framework. With this additional steps in the test, we ensure the line remains after selecting it without editing anything, a case that was broken several times already. Forward-Port-Of: odoo/odoo#143484 Forward-Port-Of: odoo/odoo#143374
Original PR description
The additional lines originating from the product configurator are sometimes not well handled by the framework. With this additional steps in the test, we ensure the line remains after selecting it without editing anything, a case that was broken several times already. Forward-Port-Of: odoo/odoo#143484 Forward-Port-Of: odoo/odoo#143374
**Description of the issue/feature this PR addresses:** Before this commit when you unlink a sale.order.line the field carrier_id of sale.order is set False for each line. This commit prevent also serialisation failure on ecommerce. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143335 Forward-Port-Of: odoo/odoo#141649
Original PR description
**Description of the issue/feature this PR addresses:** Before this commit when you unlink a sale.order.line the field carrier_id of sale.order is set False for each line. This commit prevent also serialisation failure on ecommerce. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143335 Forward-Port-Of: odoo/odoo#141649
Task Adhoc: 29838 Task latam: 1076 **Description of the issue/feature this PR addresses:** -It is needed to improve the filters and and "Group By" from the search view of own checks and third party checks. * In "Accounting/Vendors/Own Checks" it is needed to: 1) Remove the filter "Checks on hand". 2) Remove from "Group By" the group "Third party check Current Journal". * In "Accounting/Customers/Third Party Checks" it is needed to: 1) Add the filter "Checks on hand". 2) Ad
Original PR description
Task Adhoc: 29838 Task latam: 1076 **Description of the issue/feature this PR addresses:** -It is needed to improve the filters and and "Group By" from the search view of own checks and third party…
Task Adhoc: 29838 Task latam: 1076 **Description of the issue/feature this PR addresses:** -It is needed to improve the filters and and "Group By" from the search view of own checks and third party checks. * In "Accounting/Vendors/Own Checks" it is needed to: 1) Remove the filter "Checks on hand". 2) Remove from "Group By" the group "Third party check Current Journal". * In "Accounting/Customers/Third Party Checks" it is needed to: 1) Add the filter "Checks on hand". 2) Add in "Group By" the group "Third party check Current Journal". 3) Remove the filter "No Bank Matching". 4) Rename filter "Third party check Current Journal" to "Current Journal". - When a payment is created is needed show the updated search view "Accounting/Customers/Third Party Checks" when searching more checks if "Existing Third Party Checks" payment method is selected.  - Change spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view from "Actual Diario de Cheques de Terceros" to "Diario de Pago". **Current behavior before PR:** * In "Accounting/Vendors/Own Checks" in the search view: Exists the filter "Checks on hand" and exists the group "Third party check Current Journal" in the "Group by". * In "Accounting/Customers/Third Party Checks" in the search view: Don`t exist the filter "Checks on hand". Don`t exist the group "Third party check Current Journal" in the "Group by". Exists the filter "No Bank Matching". There is a filter named "Third party check Current Journal". * When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected then is showing the same search view as "Accounting/Customers/Third Party Checks". * Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Actual Diario de Cheques de Terceros". **Desired behavior after PR is merged:** * In "Accounting/Vendors/Own Checks" in the search view: Not exists the filter "Checks on hand" and not exists the group "Third party check Current Journal" in the "Group by". * In "Accounting/Customers/Third Party Checks" in the search view: Exists the filter "Checks on hand". Exists the group "Third party check Current Journal" (renamed to "Original Journal") in the "Group by". Not exists the filter "No Bank Matching". There is not existing a filter named "Third party check Current Journal". * When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected them is showing the updated search view as "Accounting/Customers/Third Party Checks". * Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Diario de Pago". Video: https://drive.google.com/file/d/1H1ng4mPsN0sf1NwW_JMOmZrhe8TrrBlk/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#132770
Description of the issue/feature this PR addresses: It was not possible to obtain suggestions by entering a GST in the Tax ID field when creating a contact. Current behavior before PR: When a GST number is entered in the Tax ID field of the contact creation form, nothing happens. Desired behavior after PR is merged: Suggestions can now be accessed by entering a GST number in the Tax ID field of the contact form. Also, add the option of allowing completion even with an 'insufficient cr
Original PR description
Description of the issue/feature this PR addresses: It was not possible to obtain suggestions by entering a GST in the Tax ID field when creating a contact. Current behavior before PR: When a GST number is entered in the Tax ID field of the contact creation form, nothing happens. Desired behavior after PR is merged: Suggestions can now be accessed by entering a GST number in the Tax ID field of the contact form. Also, add the option of allowing completion even with an 'insufficient credit' error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143370
During an onchange, fields read from database are validated again. This causes an infinite loop with HTML fields since Odoo 16 because we're revalidating a value we're reading from the database, which triggers a sanitize check, which fetches the original value, etc etc. Even if the functional bug only appears in 16.0 and above, the root cause is also present in 15.0 so this commit targets 15.0 steps to reproduce (in 16 or next versions): - Change Marc Demos's access rights Website = Res
Original PR description
During an onchange, fields read from database are validated again. This causes an infinite loop with HTML fields since Odoo 16 because we're revalidating a value we're reading from the database,…
During an onchange, fields read from database are validated again. This causes an infinite loop with HTML fields since Odoo 16 because we're revalidating a value we're reading from the database, which triggers a sanitize check, which fetches the original value, etc etc.
Even if the functional bug only appears in 16.0 and above, the root cause is also present in 15.0 so this commit targets 15.0
steps to reproduce (in 16 or next versions):
- Change Marc Demos's access rights Website = Restricted Editor
- Bypass HTML Field Sanitize = Off
- Inventory / Products / Product Variants
- Studio on the Sales tab and add website_description under Website Sequence
- Go to product [E-COM07] Large Cabinet and fill in the newly added website description
- Log out and log in as marc demo
- Navigate back to [E-COM07] Large Cabinet product variant and try to re-order the vendors on the purchase tab
- Error
before this commit:
Error (infinite loop) during onchange
```
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 6489, in onchange
record[parent_name]._update_cache({name: record[name]})
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5310, in _update_cache
value = field.convert_to_cache(value, self, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5897, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1198, in __get__
value = self.convert_to_cache(record._origin[self.name], record)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
...
```
after this commit:
no error
opw-3575865
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#143268
Forward-Port-Of: odoo/odoo#142045There's currently no way to move a dashboard from a section to another You have to start again from a blank dashboard in the other group. Task: 3592986 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#142893
Original PR description
There's currently no way to move a dashboard from a section to another You have to start again from a blank dashboard in the other group. Task: 3592986 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#142893
The language was added at dccc8f39d0 but we need a flag to display in the language switcher. (even if [Flags are not languages](https://www.flagsarenotlanguages.com)) (open to suggestions for a better flag) Forward-Port-Of: odoo/odoo#142499
Original PR description
The language was added at dccc8f39d0 but we need a flag to display in the language switcher. (even if [Flags are not languages](https://www.flagsarenotlanguages.com)) (open to suggestions for a better flag) Forward-Port-Of: odoo/odoo#142499
When performing a manual stock revaluation, the value difference is distributed equally among the available stock. This method breaks down however in case of a devaluation where some items in stock are already valued less than the unit cost difference: this results in a negative value. This commit will prevent such devaluations by raising a `UserError` whenever the remaining value of a stock.valuation.layer becomes negative. Additionally, after a revaluation, the `standard_price` field will n
Original PR description
When performing a manual stock revaluation, the value difference is distributed equally among the available stock. This method breaks down however in case of a devaluation where some items in stock are already valued less than the unit cost difference: this results in a negative value. This commit will prevent such devaluations by raising a `UserError` whenever the remaining value of a stock.valuation.layer becomes negative. Additionally, after a revaluation, the `standard_price` field will now also be updated for fifo valued products. opw-3340298 Forward-Port-Of: odoo/odoo#136934 Forward-Port-Of: odoo/odoo#126157
- Open a record with the chatter (a task for instance); - Zoom your browser until the chatter is inline with the task (as it is the case on mobile) - Write a big message. Before this commit, the composer takes all the allowed place on the screen, and we cannot see or scroll-down to the older messages. Now, the behavior is the same as is done in mobile, the composer stays sticky, but it will not take all the allowed place, and leave place to see and scroll-down the older messages. opw-
Original PR description
- Open a record with the chatter (a task for instance); - Zoom your browser until the chatter is inline with the task (as it is the case on mobile) - Write a big message. Before this commit, the composer takes all the allowed place on the screen, and we cannot see or scroll-down to the older messages. Now, the behavior is the same as is done in mobile, the composer stays sticky, but it will not take all the allowed place, and leave place to see and scroll-down the older messages. opw-3593032 Forward-Port-Of: odoo/odoo#143295