Friday, December 1, 2023
13 changes · 17.0
Enhancements to existing features
This update gives businesses more control over automatic data predictions when importing electronic invoices (EDI). Instead of automatically overwriting imported values, companies can now opt-out of automatic predictions and customize how products, accounts, and taxes are predicted based on their specific needs. This is particularly useful for Italian invoice imports where different fields require different prediction rules.
Original PR description
Odoo may allow prediction to occur when importing an EDI. i.e. predicting the product, account and taxes of each line. By default, those predictions will overwrite the actual value. Though it may be…
Odoo may allow prediction to occur when importing an EDI. i.e. predicting the product, account and taxes of each line. By default, those predictions will overwrite the actual value. Though it may be helpful in some cases, there should be a way to opt-out of the this automatic overwrite and to have a more flexible way to do those predictions. Here is how this is now possible: 1. With `disable_onchange_name_predictive` one can indicate their desire to opt-out of the prediction overwrite (i.e. the default behavior). 2. They can then use the `_predict_product`, `_predict_account`, `_predict_taxes` methods to create their own way of prediction. Placeholders for those were created to allow their use even if the prediction module isn't present. NB: As the module in charge of predictions (`account_accountant`) is not always installed the `edi_prediction_enabled` context key is used to indicate whether the prediction methods can be used or not. In the case of this fix, the key is setup in the `l10n_it_reports` module, as this module is always installed if `account_accountant` and `l10n_it` are installed. This way of predicting is useful for cases demanding a less generic approach to prediction. e.g. For the Italian EDI module the account of a line can be predicted without any limitation as it is not a value imported by the EDI. Whereas, its product and taxes should be predicted only if none were imported. opw-3201391 opw-3172035 Community PR: https://github.com/odoo/odoo/pull/144437 Forward-Port-Of: odoo/enterprise#51835 Forward-Port-Of: odoo/enterprise#38079
Resolved issues and error corrections
This fix makes opening older chat or channel messages more predictable, especially when jumping to messages from the past and then loading newer messages. It reduces confusing scrolling behavior and helps ensure users see the intended message context without timing-related glitches.
Original PR description
The main issue is partially fixed by https://github.com/odoo/odoo/pull/144228 There is an extra issue where jump/load around in the past was not properly resetting the thread loaded state, and the "load newer" was not waiting for the jump to be completed before loading newer messages because the loaded state reset was not taken into account, and also a scroll restore to bottom was applied too early (there should be none, as the jumping already highlights the message). Technically the same thread component was re-used, but the visible hook and the loaded state should always be reset when there is a jump with gap (load around). Extra assertions are added to ensure the expected scenario is fully explicited and awaited in this test. runbot-46308
This fix prevents website theme upgrades from failing when certain theme configurator snippets are present only for setup purposes or when related module manifests are missing. It also avoids duplicate template creation, making upgrades safer and more reliable for websites using themes.
Original PR description
When shapes were extracted to configurator snippets in [1], some configurator-specific snippets were created that do not appear on pages of the specific theme. Because in [2] the call to…
When shapes were extracted to configurator snippets in [1], some configurator-specific snippets were created that do not appear on pages of the specific theme. Because in [2] the call to `_generate_primary_snippet_templates` is done on a full list of themes instead of only the installed ones, the problem was not noticed: if any theme defines a block, it's website-side configurator-specific template is generated. This is not the case during an upgrade: the templates are generated only for the installed themes. Because of this some "useless" configurator templates trigger an error when importing their XML definition because their parent template does not exist. This is fixed in design-themes by adding those templates in a pseudo page `_` in the `configurator_snippets` entry of each theme's manifest. This commit makes sure to not consider that `_` page name as an actual page name. In master, the templates will be removed instead. [1]: https://github.com/odoo/design-themes/commit/d206c119720d557c11320ebb3d7339890b8f9efa [2]: https://github.com/odoo/odoo/commit/928eeca714a161f6bc03343e4dc8af9b050b9841#diff-f49a1e9eda23df9f1d48121ba376a5fabafe70ea18b29d4eab23d737e5d4eeb6R446
The Point of Sale interface now brings back the large scrollbar option that some users rely on. This improves ease of navigation for users who need more visible or easier-to-use scrollbars during checkout operations.
Original PR description
The Large Scrollbars feature was removed after this commit: https://github.com/odoo/odoo/commit/c087603d0b2fb6f81cdfd3afc1b94f7acb6bd2bd. Some users need this feature. This commit adds the Large Scrollbars back. opw-3611148 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue that could cause an error when opening or using the color palette in the mass mailing editor. Users can now edit mailing designs more reliably without encountering a traceback related to the editor sidebar.
Original PR description
Since [1], the colorPalette component is mounted on a new App via the attachComponent compatibility util. The new App is subject to target validation, which fails in mass_mailing and raises a…
Since [1], the colorPalette component is mounted on a new App via the attachComponent compatibility util. The new App is subject to target validation, which fails in mass_mailing and raises a traceback. This happens because the element for mounting the color palette is created by the top window's document and later attached to the iframe's DOM tree. Unfortunately this holds true for the entire sidebar is mass_mailing. Commit [2] apparently added some flexibility to the attachComponent util, temporarily disabling target validation when about to mount an App. But, due to the asynchronous nature of mounting an App, this was not enough for the present case, as the original App.validateTarget function is restored before it gets called when mounting the ColorPalette. This commit fixes this localized issued, leaving a large-scale fix, in which the snippets menu elements are properly created by the correct document, for a future commit on master. This will have to take into consideration the fact that the code for the snippets menu is shared between mass_mailing and website, and that, in the latter, the snippets menu sits outside the iframe, thus, it is part of the top document tree. Alternatively, the snippets menu should be refactored and converted to owl. task-3605859 [1]: https://github.com/odoo/odoo/commit/36061a4ab017a463c1d5bf838334cb4c0fac25ee [2]: https://github.com/odoo/odoo/commit/6a30ab13536a2dc0a8f23df32962cd1ceec71a5d
This fixes an accounting dashboard warning that could remain visible even after users could no longer take action because of a lock date. The warning calculation is refreshed correctly and the message now includes a clearer tooltip, reducing confusion for accounting users.
Original PR description
Lacking a flush to database before the query used to compute the gap-in-sequence warning, the gap-in-sequence warning would stay active even when the all-users lock-date was set. Which is confusing for the user as they can't do anything about it. This - adds the required flushes - adds a tooltip explaining the warning in more details as it was deemed confusing - Adds all the moves that took a sequence number in the query Task-3613058 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could occur when product records from multiple companies use different currencies. Product cost currency is now calculated per product template, preventing failures during upgrades or multi-company operations.
Original PR description
will get multiple company with multiple currency record as it will try to calculate multiple template cost currency field value. we need to do iteration for template record then it will resolve the…
will get multiple company with multiple currency record as it will try to calculate multiple template
cost currency field value. we need to do iteration for template record then it will resolve the error. Error has been introduced during upgrade.
```
File "/home/odoo/src/odoo/saas-16.4/addons/product/models/product_template.py", line 189, in _compute_cost_currency_id
self.cost_currency_id = self.company_id.currency_id or self.env.company.currency_id.id
File "/home/odoo/src/odoo/saas-16.4/odoo/fields.py", line 1306, in __set__
self.write(protected_records, value)
File "/home/odoo/src/odoo/saas-16.4/odoo/fields.py", line 3087, in write
cache_value = self.convert_to_cache(value, records)
File "/home/odoo/src/odoo/saas-16.4/odoo/fields.py", line 3010, in convert_to_cache
raise ValueError("Wrong value for %s: %r" % (self, value))
ValueError: Wrong value for product.template.cost_currency_id: res.currency(2, 139)
```
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-prThis update corrects a previous fix that inadvertently broke file generation error handling when processing single records. The previous solution worked for multiple arguments but caused errors when handling single parameters with multiple records. This fix restores proper error handling across all scenarios.
Original PR description
The following commit https://github.com/odoo/enterprise/commit/1559549ba108ed7fbeaca42ddf1581f42411939f must be reverted as it did not fully correct the file generation error widget when calling function with multiple arguments. While it fixed the issue for multiple arguments, it does not work anymore in some cases with one argument. Indeed, some errors are raised when using a single parameter with multiple records. task-3610890
Fixed an issue where expanding account lines in the Cash Flow Statement report prevented users from adding notes or accessing detailed ledger information. Now when you unfold account details, all individual entries work the same way as other reports, allowing you to annotate entries and view the general ledger.
Original PR description
Unfolding the first or last line of the report allows viewing the detail of the content per account, generating one line for each entry. Those lines didn't use any caret option, so they were not annotable, and did not allow opening the general ledger from them, like on any other report. Forward-Port-Of: odoo/enterprise#51172
A required dependency on the website_appointment module was missing from the appointment payment module's configuration file. This fix adds the missing dependency declaration, ensuring the module functions correctly and prevents potential errors when the appointment payment features are used.
Original PR description
New PR https://github.com/odoo/enterprise/pull/51963 The module is dependant on `website_appointment`, but it is missing in the manifest. https://github.com/odoo/enterprise/blob/17.0/website_appointment_account_payment/views/appointment_templates_appointments.xml#L3
This fix corrects a display error in Mexican invoice PDFs where unit codes and discount values were appearing in the wrong columns. The columns are now properly aligned with their corresponding data values, ensuring invoices display correctly when exported to PDF.
Original PR description
When exporting a pdf file of the invoice, the unit and discount values are swapped. That's because the "Unit code" column is added after the Discount column, but the unit code column value is added before the discount code column value. This commit fixes the xpath position. opw-3597556 Forward-Port-Of: odoo/enterprise#51395
This fix resolves an issue where appointment booking slots with specific times (including seconds) would fail to load the preview page, showing a 404 error instead. The problem occurred because duration values in the booking link contained more decimal places than the system expected. The fix ensures duration values are consistently rounded to 2 decimal places when matching slots, allowing customers to successfully view and book appointment slots.
Original PR description
Steps to reproduce: - Install appointment module - Go to Calendar -> Configuration -> Appointment Invitations - Create a new Appointment Invitations and add a slot with: From: 12/XX/XXXX 10:10:00 To:…
Steps to reproduce: - Install appointment module - Go to Calendar -> Configuration -> Appointment Invitations - Create a new Appointment Invitations and add a slot with: From: 12/XX/XXXX 10:10:00 To: 12/XX/XXXX 12:12:00 - Save and go to preview - Click on the slot Issue: The page does not exist (404 as request status). Cause: When generating the link for each slot, the duration is added as floats in the URL (and therefore might have a number with more than 2 decimals, which is our case). When accessing the URL, the duration is used to match the slots with same duration, however, the duration field on slots are rounded to 2 decimals. https://github.com/odoo/enterprise/blob/c5cff900d8abdf6f469c6355cc6c745b0e8a3043/appointment/models/calendar_appointment_slot.py#L45 Solution: Round the duration to 2 decimals when comparing the URL duration param with slot duration field values. opw-3384499 Forward-Port-Of: odoo/enterprise#51889 Forward-Port-Of: odoo/enterprise#47311
This fix resolves a system crash that occurred when generating accounting reports for transactions without assigned partners, which commonly happens with Point of Sale (POS) transactions. The system now properly handles these cases by skipping partners that don't exist, ensuring reports generate successfully without errors.
Original PR description
[FIX] account_report: Solve a NoneType TB when looping through partners. The issue raises from lines that have no partner (coming from POS), my fix just skips those partners. opw-3599904 Forward-Port-Of: odoo/enterprise#51703 Forward-Port-Of: odoo/enterprise#51361