Daily updates from Odoo
Navigate
Branch
Monday, January 13, 2025
48 changes
14 changes
Miscellaneous changes
Currently below error occurs when creating a time-off type. Error: `ValueError: invalid literal for int() with base 10: '84,000'` Steps to reproduce :- - Open 'Time Off' >> Go to 'Configuration' >> Click 'Time off Types' >> Click 'New' . - Give 'Time off Type' a name >> Enable 'Allow Negative Cap' >> Set 'Maximum Excess Amount' >> Hit 'Save'. - The error appears in the log. This commit solves the above issue by removing the `widget`. sentry-6184334906 Forward-Port-Of: odoo/odoo#1
Original PR description
Currently below error occurs when creating a time-off type. Error: `ValueError: invalid literal for int() with base 10: '84,000'` Steps to reproduce :- - Open 'Time Off' >> Go to 'Configuration' >> Click 'Time off Types' >> Click 'New' . - Give 'Time off Type' a name >> Enable 'Allow Negative Cap' >> Set 'Maximum Excess Amount' >> Hit 'Save'. - The error appears in the log. This commit solves the above issue by removing the `widget`. sentry-6184334906 Forward-Port-Of: odoo/odoo#191978
**Steps to Reproduce:** - Install data_recycle module. - Navigate to Configuration → Rules and create any rule for the data_recycle. **Issue:** - The selected option for the notify_frequency_period field is not displayed correctly due to a fixed width class (w-25) assigned to its parent div element.  **Solution:** - Updated the width class from w-25 to w-50 to ensure proper display of the select
Original PR description
**Steps to Reproduce:** - Install data_recycle module. - Navigate to Configuration → Rules and create any rule for the data_recycle. **Issue:** - The selected option for the notify_frequency_period field is not displayed correctly due to a fixed width class (w-25) assigned to its parent div element.  **Solution:** - Updated the width class from w-25 to w-50 to ensure proper display of the selected option.  opw-4414071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192851 Forward-Port-Of: odoo/odoo#191639
If discount was appplied to sale order line and user applied global discount, it would have been calculated based on unsdicounted amount resulting in too high global discount as global discount should be calculated based on price after line discount. opw-4349320 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-
Original PR description
If discount was appplied to sale order line and user applied global discount, it would have been calculated based on unsdicounted amount resulting in too high global discount as global discount should be calculated based on price after line discount. opw-4349320 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#191211
In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192463
Original PR description
In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192463
I encountered an error when upgrading the database. This error is because the `fname` does not exist in `self._fields` after the field has been removed in the code. Here is all the traceback : ``` Traceback (most recent call last): File "/home/do/my_projects/odoo-17/odoo17/odoo/service/server.py", line 1313, in preload_registries registry = Registry.new(dbname, update_module=update_module) File "<decorator-gen-16>", line 2, in new File "/home/do/my_projects/odoo-17/odoo17/odo
Original PR description
I encountered an error when upgrading the database. This error is because the `fname` does not exist in `self._fields` after the field has been removed in the code. Here is all the traceback : ```…
I encountered an error when upgrading the database.
This error is because the `fname` does not exist in `self._fields` after the field has been removed in the code.
Here is all the traceback :
```
Traceback (most recent call last):
File "/home/do/my_projects/odoo-17/odoo17/odoo/service/server.py", line 1313, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/do/my_projects/odoo-17/odoo17/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/do/my_projects/odoo-17/odoo17/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/do/my_projects/odoo-17/odoo17/odoo/modules/loading.py", line 536, in load_modules
env['ir.model.data']._process_end(processed_modules)
File "/home/do/my_projects/odoo-17/OpenUpgrade/openupgrade_framework/odoo_patch/odoo/addons/base/models/ir_model.py", line 77, in _process_end
return IrModelData._process_end._original_method(self, modules)
File "/home/do/my_projects/odoo-17/odoo17/odoo/addons/base/models/ir_model.py", line 2558, in _process_end
self._process_end_unlink_record(record)
File "/home/do/my_projects/odoo-17/odoo17/odoo/addons/base/models/ir_model.py", line 2487, in _process_end_unlink_record
record.unlink()
File "/home/do/my_projects/odoo-17/odoo17/addons/mail/models/ir_model_fields.py", line 52, in unlink
'sequence': self.env[field.model_id.model]._mail_track_get_field_sequence(field.name),
File "/home/do/my_projects/odoo-17/odoo17/addons/mail/models/models.py", line 181, in _mail_track_get_field_sequence
if isinstance(fname, IrModelFields):
KeyError: 'date_process'
```
close: https://github.com/odoo/odoo/issues/172891
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#172881Scenario: create a server action that updates a properties Result: traceback error is raised Issue: server action does not handle updating record properties Fix: ignore the error in _stringify_path method, so the more legible ValidationError from _traverse_path is raised instead. Note: without the fix, the added test failed with "KeyError: 'discussion_color_code'", with the fix it doesn't fail (and there is a "ValidationError: 'The path to the field to update contains a non-relation
Original PR description
Scenario: create a server action that updates a properties
Result: traceback error is raised
Issue: server action does not handle updating record properties Fix: ignore the error in _stringify_path method, so the more legible
ValidationError from _traverse_path is raised instead.
Note: without the fix, the added test failed with "KeyError: 'discussion_color_code'", with the fix it doesn't fail (and there is a "ValidationError: 'The path to the field to update contains a non-relational field (attributes) that is not the last field in …'").
opw-4339633
Forward-Port-Of: odoo/odoo#192483An error can occur when the EDI proxy is not Peppol, because the mocked request does not exist in the mocked dictionary. Steps to reproduce: - Install l10n_it_edi and account_peppol - Set up production for Italian Electronic Invoicing - Set up demo mode for Peppol - Create a new invoice and click on Send & Print - Check the "Send To Tax Agency" box An error will occur: ``` File "/home/odoo/src/odoo/saas-17.4/addons/account_peppol/tools/demo_utils.py", line 74, in _mock_make_reques
Original PR description
An error can occur when the EDI proxy is not Peppol, because the mocked request does not exist in the mocked dictionary.
Steps to reproduce:
- Install l10n_it_edi and account_peppol
- Set up production for Italian Electronic Invoicing
- Set up demo mode for Peppol
- Create a new invoice and click on Send & Print
- Check the "Send To Tax Agency" box
An error will occur:
```
File
"/home/odoo/src/odoo/saas-17.4/addons/account_peppol/tools/demo_utils.py",
line 74, in _mock_make_request
return {
KeyError: 'SdiRiceviFile'
```
This error arises because the EDI proxy is not Peppol, and thus the request should not be mocked. This fix ensures that the EDI proxy is Peppol before mocking the request.
opw-4438740
Forward-Port-Of: odoo/odoo#193188The demo data for `mass_mailing_crm` is currently not viewable nor editable before being sent. Steps to reproduce ----- 1. Open Email Marketing > Select the campaign titled "We want to hear from you !" 2. In the form view, a template picker is displayed instead of the existing contents Cause ----- The demo data is using `body_html` instead of `body_arch`, the latter of which is displayed in the form view before the campaign is sent. Since `body_arch = False`, the template picker is di
Original PR description
The demo data for `mass_mailing_crm` is currently not viewable nor editable before being sent. Steps to reproduce ----- 1. Open Email Marketing > Select the campaign titled "We want to hear from you !" 2. In the form view, a template picker is displayed instead of the existing contents Cause ----- The demo data is using `body_html` instead of `body_arch`, the latter of which is displayed in the form view before the campaign is sent. Since `body_arch = False`, the template picker is displayed instead. Solution ----- Use the `body_arch` field instead, `body_html` will be rendered when running the Test or Send actions. opw-4440786 Forward-Port-Of: odoo/odoo#193274
Before this commit, when the user is on mobile and try to edit/create a new todo, the user cannot edit a tag or users because those fields are displayed in actions dropdown and that dropdown is closed each time the user clicks on one of those fields. This commit prevents to close the dropdown in todo form view since that dropdown contains fields and not buttons to let the user to edit those fields. Forward-Port-Of: odoo/odoo#193177
Original PR description
Before this commit, when the user is on mobile and try to edit/create a new todo, the user cannot edit a tag or users because those fields are displayed in actions dropdown and that dropdown is closed each time the user clicks on one of those fields. This commit prevents to close the dropdown in todo form view since that dropdown contains fields and not buttons to let the user to edit those fields. Forward-Port-Of: odoo/odoo#193177
The issue: When a vendor has multiple prices for two companies (A and B), and the purchase order's company is set to B (while the user's main company is A), the price incorrectly defaults to the main company A's price. How to reproduce the issue: 1) Create a new product with 2 vendor pricelist records that have different "Unit Prices" under the "Purchase" tab of the product -> each pricelist record should belong to a different company 2) Create an RFQ for this product with both of these
Original PR description
The issue: When a vendor has multiple prices for two companies (A and B), and the purchase order's company is set to B (while the user's main company is A), the price incorrectly defaults to the main…
The issue: When a vendor has multiple prices for two companies (A and B), and the purchase order's company is set to B (while the user's main company is A), the price incorrectly defaults to the main company A's price. How to reproduce the issue: 1) Create a new product with 2 vendor pricelist records that have different "Unit Prices" under the "Purchase" tab of the product -> each pricelist record should belong to a different company 2) Create an RFQ for this product with both of these companies active 3) Change the "Company" on the PO under the "Other Information" tab to the company that is NOT shown in the top right-hand corner, but is still selected 4) Add the product to the RFQ order line - The "Unit Price" will be pulled from the main company shown in the top-right hand corner, thereby ignoring the "Company" selected for the PO. After this commit, the price from the purchase order's company (B) is prioritized over the main company (A). opw-4347134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189272
Steps to reproduce ================== - Use a mobile viewport - Go to Inventory > Delivery Orders - Open any record - Click on a product - Click on add => TypeError: ml.data.quant_id is undefined Cause of the issue ================== On mobile, the quant_id field is not present in the view opw-4288556 Forward-Port-Of: odoo/odoo#192732
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Go to Inventory > Delivery Orders - Open any record - Click on a product - Click on add => TypeError: ml.data.quant_id is undefined Cause of the issue ================== On mobile, the quant_id field is not present in the view opw-4288556 Forward-Port-Of: odoo/odoo#192732
Currently the folllowing fields are not set / given in the SII / FaturaE XMLs respectively: * `FechaOperacion` (l10n_es_edi_sii) * `OperationDate` (l10n_es_edi_facturae) After this commit they will give the delivery date in case the delivery date is different from the invoice date. This is basically the same as it was done for TicketBat (l10n_es_edi_tbai) in commit 1451f589895f0867cd40add66e5e6bcbb5ba4a6e already. opw-4367470 Enterprise PR: https://github.com/odoo/enterprise/pu
Original PR description
Currently the folllowing fields are not set / given in the SII / FaturaE XMLs respectively: * `FechaOperacion` (l10n_es_edi_sii) * `OperationDate` (l10n_es_edi_facturae) After this commit they will give the delivery date in case the delivery date is different from the invoice date. This is basically the same as it was done for TicketBat (l10n_es_edi_tbai) in commit 1451f589895f0867cd40add66e5e6bcbb5ba4a6e already. opw-4367470 Enterprise PR: https://github.com/odoo/enterprise/pull/76523 Forward-Port-Of: odoo/odoo#192467
iOS push notifications do not work on Safari: they only work in apps. The notifications are managed by the apps, whether with native mobile app or PWA. With PWA, it should normally rely on `Notification.permission`, but somehow it doesn't work and always has value "default". Its showing has been limited to the PWA, but it keeps showing a persistent notification. Clicking on it the 1st time displays a prompt to either accept or deny the permissions. Afterwards, further clicks on the "odoobot h
Original PR description
iOS push notifications do not work on Safari: they only work in apps. The notifications are managed by the apps, whether with native mobile app or PWA. With PWA, it should normally rely on…
iOS push notifications do not work on Safari: they only work in apps. The notifications are managed by the apps, whether with native mobile app or PWA. With PWA, it should normally rely on `Notification.permission`, but somehow it doesn't work and always has value "default". Its showing has been limited to the PWA, but it keeps showing a persistent notification. Clicking on it the 1st time displays a prompt to either accept or deny the permissions. Afterwards, further clicks on the "odoobot has a request" automatically display "granted" or "denied" based on user initial choice. iOS push permissions seem to necessarily rely on `serviceWorker.getRegistration().pushManager`, which works only on HTTPS, hence why iOS push notifications do not work on HTTP. Also actual push permission state are correct there whereas on Notification.permission they are wrong. This commit fixes the issue by computing the push notification permisssion state correctly on iOS, using `serviceWorker.getRegistration().pushManager`. opw-4391766 Backport of https://github.com/odoo/odoo/pull/178057 https://github.com/odoo/odoo/pull/187038 https://github.com/odoo/odoo/pull/188258 Forward-Port-Of: odoo/odoo#193257
Versions -------- - 16.0+ Steps ----- 1. Have a payment provider like Demo published; 2. create a discount program that expired yesterday; 3. change time of PC to yesterday; 4. go to eCommerce, add product to cart, go to checkout; 5. follow steps until you get to the "Pay Now" button; 6. change time of PC to today; 7. finalize payment. Issue ----- The payment transaction proceeds, but doesn't cover the entire amount, as the promotion was removed afterwards. Cause ----- Whe
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a payment provider like Demo published; 2. create a discount program that expired yesterday; 3. change time of PC to yesterday; 4. go to eCommerce, add product to cart, go to checkout; 5. follow steps until you get to the "Pay Now" button; 6. change time of PC to today; 7. finalize payment. Issue ----- The payment transaction proceeds, but doesn't cover the entire amount, as the promotion was removed afterwards. Cause ----- When initiating payment, there's check on whether the applied rewards are still valid. Solution -------- Add an override for `_validate_transaction_for_order`, which compares the order amount before and after updating programs & rewards. If they don't match, raise a `ValidationError`, forcing the user reload the order without expired programs & rewards. opw-4304241 Forward-Port-Of: odoo/odoo#193090 Forward-Port-Of: odoo/odoo#191256
26 changes
Enhancements to existing features
This update simplifies how automated tests enter a special test mode, making the test code easier to maintain. It affects several accounting, reporting, localization, and WhatsApp test areas, with no expected change for everyday users.
Original PR description
Use the context-manager to simplify test code. odoo/odoo#193348
The quick search menu in the search bar now opens using a more robust dropdown behavior, helping it appear correctly even when users work inside pop-ups or overlays. This improves day-to-day usability and reduces cases where search options are hidden or difficult to access.
Original PR description
This commit makes it so the search_bar quick search uses the Dropdown component, this fixes issues where the menu would sometimes be under overlays such as modals. See community PR: https://github.com/odoo/odoo/pull/190352
Shop floor teams can now choose whether the final work order closes the manufacturing order directly. This reduces extra clicks for teams that usually close orders right away, while letting others keep a manual closing step to match their process.
Original PR description
Currently, in the shop floor, when marking the last WO of an MO as done, there is the option to also close the MO. This requires users who want to close the MO to press two buttons in different places. For users who don't want to close the MO, this can also lead to confusion whether they marked the WO as done or not. To improve the user experience, we introduce a new option: 'Close Manufacturing Order' which allows the desired shop floor WO close behavior to be set in the operation type settings. When enabled (default), the mark as done button on the last WO of an MO in the shop floor will have a 'Close Production' button directly instead of a 'Mark as Done' button. When disabled, the MO needs to be closed manually after marking the last workorder as done, as we now no longer show the Close production button on the workorder after marking it as done. task-4367540
Scanning a packaging barcode from the barcode app homepage now works like scanning the product barcode, making it easier to find items without opening packaging. Inventory counting behavior is unchanged, so packaging scans during inventory still add the correct packaged quantity.
Original PR description
Normally, scanning the barcode of a product packaging has no effect on the barcode module homepage. For the convenience of not having to open the packaging in order to scan the barcode of the product it contains just to locate it, the barcode on the packaging itself is now treated the same way as the barcode on the product itself when scanned on the module homepage. The behaviour with inventory taking (ie adding the product as many times as the packaging contains) remains unchanged. Task ID: [4284938](https://www.odoo.com/odoo/project/966/tasks/4284938)
Resolved issues and error corrections
Odoo Studio now shows helpful placeholder text when configuring supported field widget options in the sidebar. This makes it easier for users to understand what to enter and reduces setup mistakes.
Code cleanup and technical improvements
Odoo now avoids automatically adding every message recipient as a follower, so records should keep cleaner and more relevant follower lists. Customer-facing documents still keep the right customer access where needed, while notifications are handled more consistently across apps like appointments, helpdesk, payroll, and follow-up.
Original PR description
Autollow (adding explicit recipients, aka 'partner_ids) as followers when posting a message should be used only in some specific flows. It is notably done to ensure customer of portal-enabled…
Autollow (adding explicit recipients, aka 'partner_ids) as followers when posting a message should be used only in some specific flows. It is notably done to ensure customer of portal-enabled documents (SO, PO, ...) are able to access it, as ACLs are notably based on followers. Currently python code does not activate it by default, as it would create a log of useless followers. JS does it once the composer is opened, mainly for historical reasons. Autofollow is now always turned off. Purpose is to have only relevant followers, and mainly internal users once email-like flow is completely implemented. Some manual autofollow are also removed. SO and PO expect customer to be follower of documents, notably for ACL purpose. We therefore set the new '_mail_thread_customer' class attribute introduced in this change. It does the same as 'mail_post_autofollow', but for the document customer only. Task-4273479: [mail] Stop autofollow madness ! Prepares Task-4422660: [mail] Use external suggested recipients Prepares Task-4273479: [mail] Email-like recipients
This update adjusts WhatsApp-related field selector usage to match a recent naming cleanup in the underlying platform. It keeps the Enterprise code aligned with the main Odoo framework and reduces maintenance risk without changing business workflows.
Original PR description
*: whatsapp: widget usages adaptations Since [1], DynamicModelFieldSelectorChar field widget was introduced. The related community commit renames it amongst other things. This commit adapts its usages in the enterprise repository. [1]: https://github.com/odoo/odoo/commit/fe62bfeacb38e03cb94010f1f75ae301951ac9d1 task-4388736
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#76595
Original PR description
Forward-Port-Of: odoo/enterprise#76595
Issue: in the current version is not posible to add bills or remove them when the asset is already running or closed, and the current error message shown to the user is "It is not possible to delete an item that is linked to a posted entry." Solution: Since this behavior will be upgraded in master we show a more specific error message to the user for stable versions. opw-3369633 Forward-Port-Of: odoo/enterprise#76765 Forward-Port-Of: odoo/enterprise#71561
Original PR description
Issue: in the current version is not posible to add bills or remove them when the asset is already running or closed, and the current error message shown to the user is "It is not possible to delete an item that is linked to a posted entry." Solution: Since this behavior will be upgraded in master we show a more specific error message to the user for stable versions. opw-3369633 Forward-Port-Of: odoo/enterprise#76765 Forward-Port-Of: odoo/enterprise#71561
This commit ensures the asynchronous fetching cron is activated or deactivated only when necessary. Previously, the cron was executed every 5 minutes to check for online accounts to fetch transactions, even when none were present, leading to useless call to the cron. With this update, a toggle function is introduced, which is triggered whenever a journal or an online account is created, modified, or removed. Before deactivating the cron, the function verifies that no journals with an online
Original PR description
This commit ensures the asynchronous fetching cron is activated or deactivated only when necessary. Previously, the cron was executed every 5 minutes to check for online accounts to fetch transactions, even when none were present, leading to useless call to the cron. With this update, a toggle function is introduced, which is triggered whenever a journal or an online account is created, modified, or removed. Before deactivating the cron, the function verifies that no journals with an online account are currently in the fetching process, preventing unnecessary execution. no task id Forward-Port-Of: odoo/enterprise#76992 Forward-Port-Of: odoo/enterprise#76843
This commit fixes an issue with an icon in dark mode and some UX on mobile. The `All changes saved` icon inside the topbar wasn't really visible in dark mode. To fix this, an invert filter is applied to the img when Odoo is in dark mode. This way instead of black the icon is white. In mobile, there is no possibility to create articles below a specific route, because the buttons are invisible. To fix, this we rendered the buttons always visible when the user is on mobile. task-4377610 Forw
Original PR description
This commit fixes an issue with an icon in dark mode and some UX on mobile. The `All changes saved` icon inside the topbar wasn't really visible in dark mode. To fix this, an invert filter is applied to the img when Odoo is in dark mode. This way instead of black the icon is white. In mobile, there is no possibility to create articles below a specific route, because the buttons are invisible. To fix, this we rendered the buttons always visible when the user is on mobile. task-4377610 Forward-Port-Of: odoo/enterprise#76946 Forward-Port-Of: odoo/enterprise#75180
*: pos_restaurant_preparation_display Point of sale: - Adding margin left on preset time on product screen. - Replacing ActionPad button "action" by 3 vertical dots - Allow to reprint the last prepration ticket - Adding number of orders by pages on ticket screen. - Removing seconds on the time of the order. - Resizing search bar on ticket screen. Preparation display: - Adding zoom parameter on the navbar - Removing waiter name. - Adding order floating name. - Adding preset name a
Original PR description
*: pos_restaurant_preparation_display Point of sale: - Adding margin left on preset time on product screen. - Replacing ActionPad button "action" by 3 vertical dots - Allow to reprint the last prepration ticket - Adding number of orders by pages on ticket screen. - Removing seconds on the time of the order. - Resizing search bar on ticket screen. Preparation display: - Adding zoom parameter on the navbar - Removing waiter name. - Adding order floating name. - Adding preset name and time on orders. taskId: 4398826 Forward-Port-Of: odoo/enterprise#75873
Steps to reproduce: 1. remove the owner of a document. 2. add tags to that document. 3. hovering on it will move other documents slightly. Technical Reason: Before hover, the elements are set to display: 'none', which triggers layout recalculations and reflows in the browser when the elements are added or removed from the rendering tree on hover. After this commit: No layout shifting to documents on hover. Task-4442559 Forward-Port-Of: odoo/enterprise#76507
Original PR description
Steps to reproduce: 1. remove the owner of a document. 2. add tags to that document. 3. hovering on it will move other documents slightly. Technical Reason: Before hover, the elements are set to display: 'none', which triggers layout recalculations and reflows in the browser when the elements are added or removed from the rendering tree on hover. After this commit: No layout shifting to documents on hover. Task-4442559 Forward-Port-Of: odoo/enterprise#76507
Before this commit, when the user starts a new timer on the grid view and a timesheet is created, the timer is not marked as running on the row contained the project. Same issue when a timer is running and the user refreshes the page. This commit adds the needed data to make sure the grid view finds which row has the timer running. Forward-Port-Of: odoo/enterprise#76855 Forward-Port-Of: odoo/enterprise#76717
Original PR description
Before this commit, when the user starts a new timer on the grid view and a timesheet is created, the timer is not marked as running on the row contained the project. Same issue when a timer is running and the user refreshes the page. This commit adds the needed data to make sure the grid view finds which row has the timer running. Forward-Port-Of: odoo/enterprise#76855 Forward-Port-Of: odoo/enterprise#76717
This allows to customize the ability to generate a task and/or project per sale.order.line instead of per order only. Forward-Port-Of: odoo/enterprise#75643
Original PR description
This allows to customize the ability to generate a task and/or project per sale.order.line instead of per order only. Forward-Port-Of: odoo/enterprise#75643
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transaction
Original PR description
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery…
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transactions" to start and handle all the invoices & payments created by "_create_recurring_invoice". The 2 CRON were then likely to create SerializationFailure due to a concurrent update. With this commit, each batch creates its own deliveries before triggering the next batch. If the delivery creations do fail: - The error is caught as to not prevent the next batch from being triggered. - An exception activity is created on the subscription to notify the customer about the error. - A contextual action is available to manually trigger the delivery. OPW-4319019 --- When the delivery creation failed, you can easily spot it on the list view thanks to the activity warning:  --- ## Example log ``` 2024-11-14 07:48:53,757 96554 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (30.353s). 2024-11-14 07:58:26,142 96886 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 07:58:57,145 96886 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (31.003s). 2024-11-14 08:05:51,910 97204 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:06:46,734 97204 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (54.823s). 2024-11-14 08:06:53,143 97262 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:07:46,207 97262 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (53.064s). 2024-11-14 08:07:55,496 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:08:30,928 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:08:44,957 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (49.461s). 2024-11-14 08:08:50,945 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:09:18,543 97300 ERROR customer-database odoo.addons.base.models.ir_cron: Call from cron Sale Subscription: generate recurring invoices and payments for server action #705 failed in Job #10 2024-11-14 08:15:52,854 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (441.926s). 2024-11-14 08:18:31,161 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:21:16,823 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (165.662s). 2024-11-14 08:28:31,865 99066 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. ``` - At the beginning: `payment: post-process transactions` take ~30 secs - Then, `Sale Subscription: generate recurring invoices and payments` runs a few times (as expected). - `payment: post-process transactions` re-runs, and it takes 441.926. During this time, `Sale Subscription: generate recurring invoices and payments` starts and failed. --- ## A few points of information/discussion: - The SerializationFailure is systematic on the customer database, who has ~200 subscriptions invoiced each day. - The added action "Subscription: Generate delivery" is optional, I am amenable to remove it from this PR, but we would just block the customer with undelivered stock. - In master, it would be better to automatically detect the deliveries not done and re-generate each day. However, I was unable to find a proper way to do it without adding a field or changing the behavior of an existing one. - I originally wanted to create to add a button to the form view like "Create Delivery", however, like above I was unable to properly detect undelivered subscriptions. - The exception activity does not directly notify the users via discuss, do you think I should add the option? - I did not (yet) created tests for this error. To properly do so, I would need to reproduce a SerializationFailure which I'm unsure of how to do without doing commits. I could simply fake it by overwriting the `_action_launch_stock_rule` to raise an Error... TBD Forward-Port-Of: odoo/enterprise#76857 Forward-Port-Of: odoo/enterprise#73911
Forward-Port-Of: odoo/enterprise#76990 Forward-Port-Of: odoo/enterprise#75397
Original PR description
Forward-Port-Of: odoo/enterprise#76990 Forward-Port-Of: odoo/enterprise#75397
Currently our translation extraction mechanism for Javascript does not support `_t()` calls that are inside template strings. Because of that a bunch of placeholders were not exported for translation. This commit fixed that by rewriting the code without nesting `_t()` calls in template strings. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#76829
Original PR description
Currently our translation extraction mechanism for Javascript does not support `_t()` calls that are inside template strings. Because of that a bunch of placeholders were not exported for translation. This commit fixed that by rewriting the code without nesting `_t()` calls in template strings. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#76829
Before this commit, it could happen that the partner associated to the current company was not automatically loaded at the start of the POS session. Since this parter is required for proper operation of l10n_it_pos, it could lead to unexpected errors. After this commit, the partner is explicitly force-loaded at the start of the POS session to ensure proper operation. opw-4394672 Linked community PR: https://github.com/odoo/odoo/pull/193123 Forward-Port-Of: odoo/enterprise#76894 Forwar
Original PR description
Before this commit, it could happen that the partner associated to the current company was not automatically loaded at the start of the POS session. Since this parter is required for proper operation of l10n_it_pos, it could lead to unexpected errors. After this commit, the partner is explicitly force-loaded at the start of the POS session to ensure proper operation. opw-4394672 Linked community PR: https://github.com/odoo/odoo/pull/193123 Forward-Port-Of: odoo/enterprise#76894 Forward-Port-Of: odoo/enterprise#76517
To reproduce the issue: 1) Create a vendor bill for 100€, with a tax of 15% 2) In the grouped generic tax reports, the base will be 100 and the tax 15 3) Create an expense of 200€, with the same tax, paid by the company. Fully validate it and post the entry. ====> The grouped generic tax reports now should display 300 of base, and 45 of tax. It does only show 200 of base, though. This happens because when post-processing the results of the query ran by the report, we do this https://github
Original PR description
To reproduce the issue: 1) Create a vendor bill for 100€, with a tax of 15% 2) In the grouped generic tax reports, the base will be 100 and the tax 15 3) Create an expense of 200€, with the same tax,…
To reproduce the issue: 1) Create a vendor bill for 100€, with a tax of 15% 2) In the grouped generic tax reports, the base will be 100 and the tax 15 3) Create an expense of 200€, with the same tax, paid by the company. Fully validate it and post the entry. ====> The grouped generic tax reports now should display 300 of base, and 45 of tax. It does only show 200 of base, though. This happens because when post-processing the results of the query ran by the report, we do this https://github.com/odoo/enterprise/blame/16.0/account_reports/models/account_generic_tax_report.py#L406 , so we essentially don't add the base amounts of the tax lines whose identification key has already been treated. This is important for taxes with multiple tax repartition lines. In our case, a line is generated by the query for both the invoice and the expense entry. This is because the query groups on display_type: the expense line has display_type = 'product', while the invoice has 'tax'. This grouping was introduced here https://github.com/odoo/enterprise/commit/67f841ee36cb5a8ef95ae3dd3859239a4d10b99d to avoid counting the base amounts of the cash rounding lines as additional base amounts. We fix this by slightly tweaking the query, in order for rounding lines to be considered as having a base amount of 0. opw-3890736 Forward-Port-Of: odoo/enterprise#76929 Forward-Port-Of: odoo/enterprise#76536
…nsaction list view Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that the module account_bank_statement_extract forces the recomputation of the name when the statement's date changes which happens at the creation (and triggers our bug) but also when the OCR fil> So to fix that, * the de
Original PR description
…nsaction list view Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that the module account_bank_statement_extract forces the recomputation of the name when the statement's date changes which happens at the creation (and triggers our bug) but also when the OCR fil> So to fix that, * the default name of the statement line now check if the statement date is falsy, to avoid having a default name as 'BNK1 Statement False', and fallback on the create_date. Same for the journal_code since journal_id isn't required. * when filling the OCR values, we assume it wasn't manually changed (why whould it be?) and we replace the default name since we now know the real date ticket-4424021 Forward-Port-Of: odoo/enterprise#76656
Steps to reproduce ================== - Create multiple companies - In the current user settings, select a default company that is not the first one - Use another company - logout - login => The previously used company is kept Cause of the issue ================== The cids cookie was not invalidated because super was not called opw-4426742 Forward-Port-Of: odoo/enterprise#76800 Forward-Port-Of: odoo/enterprise#76716
Original PR description
Steps to reproduce ================== - Create multiple companies - In the current user settings, select a default company that is not the first one - Use another company - logout - login => The previously used company is kept Cause of the issue ================== The cids cookie was not invalidated because super was not called opw-4426742 Forward-Port-Of: odoo/enterprise#76800 Forward-Port-Of: odoo/enterprise#76716
Issue 1: Reproduce: 1. Create a shortcut for a folder. 2. Move the shortcut to the trash. 3. Go to the trash and try deleting the shortcut. 4. You get a 'Missing Record' message. Issue 2: While in the trash you cannot open folders, if you had a non-archived shortcut to an archived folder you were able to view its (archived) target content there. Issue 3: Reproduce: 1. Create a shortcut in your drive for a document in "Share with me" 2. Click on the shortcut and from
Original PR description
Issue 1: Reproduce: 1. Create a shortcut for a folder. 2. Move the shortcut to the trash. 3. Go to the trash and try deleting the shortcut. 4. You get a 'Missing Record' message. Issue 2: While in…
Issue 1: Reproduce: 1. Create a shortcut for a folder. 2. Move the shortcut to the trash. 3. Go to the trash and try deleting the shortcut. 4. You get a 'Missing Record' message. Issue 2: While in the trash you cannot open folders, if you had a non-archived shortcut to an archived folder you were able to view its (archived) target content there. Issue 3: Reproduce: 1. Create a shortcut in your drive for a document in "Share with me" 2. Click on the shortcut and from the details panel click on the button allowing to jump to the original document (target or source) 3. There is your traceback In fact, the same applies for documents in "My Drive" and "Company" Issue 4: Reproduce: 1. Select a document you are allowed to "Move to trash" 2. Copy its url 3. Send it to the trash 4. Go to the URL 5. You are not getting to the record even though you are allowed to access it. Task-4433373 Forward-Port-Of: odoo/enterprise#76998 Forward-Port-Of: odoo/enterprise#76220
**Steps to Reproduce:** - Install data_cleaning and data_merge modules. - Navigate to Configuration → Rules and create any rule for the above models. **Issue:** - The selected option for the notify_frequency_period field is not displayed correctly due to a fixed width class (w-25) assigned to its parent div element.  **Solution:** - Updated the width class from w-25 to w-50 to ensure proper disp
Original PR description
**Steps to Reproduce:** - Install data_cleaning and data_merge modules. - Navigate to Configuration → Rules and create any rule for the above models. **Issue:** - The selected option for the notify_frequency_period field is not displayed correctly due to a fixed width class (w-25) assigned to its parent div element.  **Solution:** - Updated the width class from w-25 to w-50 to ensure proper display of the selected option.  opw-4414071 Forward-Port-Of: odoo/enterprise#76684 Forward-Port-Of: odoo/enterprise#76122
Currently, a traceback occurs if the user installs an inventory module, When the accounting module was installed, there was no state_id in the company. To reproduce this issue: 1) Install `Accounting` and remove the state from the company 2) Update a Fiscal Position record with Foreign Tax and Federal State 3) Now install the inventory module Error:- ``` TypeError: sequence item 0: expected str instance, bool found ``` Here, State_id is not a required field in the company, So,
Original PR description
Currently, a traceback occurs if the user installs an inventory module, When the accounting module was installed, there was no state_id in the company. To reproduce this issue: 1) Install…
Currently, a traceback occurs if the user installs an inventory module, When the accounting module was installed, there was no state_id in the company. To reproduce this issue: 1) Install `Accounting` and remove the state from the company 2) Update a Fiscal Position record with Foreign Tax and Federal State 3) Now install the inventory module Error:- ``` TypeError: sequence item 0: expected str instance, bool found ``` Here, State_id is not a required field in the company, So, the user can remove it. When there is no `state_id` and a fiscal position record has a Foreign Tax. We get a traceback from the below lines. https://github.com/odoo/enterprise/blob/1c6f0273e76b6dfb89ef65eb359e620b9c4c5759/account_reports/models/res_company.py#L216-L219 This is because we have a `vat_fpos_with_state_count` value due to foreign vat in fiscal position, but we don't have a state_id in the company. So the `state_codes` value will be a list of bool, which leads to the above traceback. We can resolve this issue by making the code more robust. sentry-6203209197 Forward-Port-Of: odoo/enterprise#76784
Before this commit, when a component uses service "mail.store", it has to wrap in a `useState()` to make sure any change to store is observed. This is the behaviour that essentially all `useService("mail.store")` want. If they omit it, it can fail to re-render store changed, which is painful to debug. This commit improves by automatically wrapping `useState()` on services that are stateful. Stateful services return a reactive. Using stateful services becomes the same as non-stateful one: just
Original PR description
Before this commit, when a component uses service "mail.store", it has to wrap in a `useState()` to make sure any change to store is observed. This is the behaviour that essentially all `useService("mail.store")` want. If they omit it, it can fail to re-render store changed, which is painful to debug.
This commit improves by automatically wrapping `useState()` on services that are stateful. Stateful services return a reactive. Using stateful services becomes the same as non-stateful one: just put `useService(serviceName)`.
https://github.com/odoo/odoo/pull/191511
Forward-Port-Of: odoo/enterprise#760587 changes
Enhancements to existing features
Subscription sales orders that require customer payment but do not have a saved payment method now show a clear status indicator. This helps teams quickly identify orders waiting for customer action before invoices can be created automatically.
Original PR description
When a subscription has the require_payment payment flag and no payment token, we will send a reminder to pay by mail. No automatic invoice will be created. Before this commit, when the SO is in this situation, no visual aid will help. taskid: 4367794
Resolved issues and error corrections
Canceling a payment terminal transaction now returns the payment method button to its normal state, preventing staff from seeing a stuck in-progress status. The payment status message is also easier to see on mobile screens, improving checkout clarity for smaller devices.
Original PR description
Steps to reproduce: -------------------------- - Install the point_of_sale module. - Set up any payment terminal. - Attempt payment using the terminal. - Cancel the transaction request. Issue: -------- - Payment method button remains in progress mode after canceling the transaction. - In mobile view, the payment status message lacks a visible background. Cause: --------- - Transaction progress state is not reset after a successful cancellation. - Missing responsive classes for mobile view. Fix: ---- - Reset the payment method progress state after a successful cancellation. - Add appropriate classes to ensure the payment status background is visible across all views. Task: 4427387
This fixes Czech accounting behavior so bank and cash transactions created for a past date are no longer overwritten with the current date when no taxable supply date is entered. It helps businesses issue backdated documents correctly while staying aligned with Czech VAT date rules.
Original PR description
Current behavior before PR: Actual change in Odoo 18.0 breaks logic for documents without taxable supply date on form. This cause issues with issuing documents to the past for example bank or cash.…
Current behavior before PR: Actual change in Odoo 18.0 breaks logic for documents without taxable supply date on form. This cause issues with issuing documents to the past for example bank or cash. If you are trying issue document to past it's overwritten to actual date. Desired behavior after PR is merged: I can create bank or cash transaction in the past. Description of the issue/feature this PR addresses: According to the Czech VAT Act (Act No. 235/2004 Coll., on VAT), the difference between the date of issuance of an invoice (date) and the date of taxable supply (taxable_supply_date) is regulated as follows: Taxable Supply Date (taxable_supply_date): This is the day on which the taxable supply (delivery of goods or provision of services) actually took place, unless specified otherwise. Date of Issuance of the Invoice (date): The invoice must be issued no later than 15 calendar days from the taxable_supply_date. This means that the gap between the taxable_supply_date and the date cannot exceed 15 calendar days. Example: Taxable_supply_date: January 1, 2025 Date: Must be no later than January 16, 2025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a visual issue in Documents where hovering over a document could slightly move nearby items when the document had no owner and included tags. This keeps the document view stable and makes browsing documents feel smoother and more polished.
Original PR description
Steps to reproduce: 1. remove the owner of a document. 2. add tags to that document. 3. hovering on it will move other documents slightly. Technical Reason: Before hover, the elements are set to display: 'none', which triggers layout recalculations and reflows in the browser when the elements are added or removed from the rendering tree on hover. After this commit: No layout shifting to documents on hover. Task-4442559
Miscellaneous changes
Before this commit, when the user is on mobile and try to edit/create a new todo, the user cannot edit a tag or users because those fields are displayed in actions dropdown and that dropdown is closed each time the user clicks on one of those fields. This commit prevents to close the dropdown in todo form view since that dropdown contains fields and not buttons to let the user to edit those fields. Forward-Port-Of: odoo/odoo#193177
Original PR description
Before this commit, when the user is on mobile and try to edit/create a new todo, the user cannot edit a tag or users because those fields are displayed in actions dropdown and that dropdown is closed each time the user clicks on one of those fields. This commit prevents to close the dropdown in todo form view since that dropdown contains fields and not buttons to let the user to edit those fields. Forward-Port-Of: odoo/odoo#193177
Two lines that were missing from the "REAGYP - Agricultura" Fiscal Position Tax Mapping have been added. task-4342206 Forward-Port-Of: odoo/odoo#192930 Forward-Port-Of: odoo/odoo#192359
Original PR description
Two lines that were missing from the "REAGYP - Agricultura" Fiscal Position Tax Mapping have been added. task-4342206 Forward-Port-Of: odoo/odoo#192930 Forward-Port-Of: odoo/odoo#192359
Currently, the extractor looking for terms to translate in spreadsheet files was specifically looking for files ending in "_spreadsheet.json". However, since this version there were new spreadsheets added that ended in "_spreadsheet.osheet.json". The translation extractor couldn't find these and the terms were never extracted, resulting in missing translations. This commit searches for both filename patterns to export the terms. We also make sure that file references are only extracted onc
Original PR description
Currently, the extractor looking for terms to translate in spreadsheet files was specifically looking for files ending in "_spreadsheet.json". However, since this version there were new spreadsheets added that ended in "_spreadsheet.osheet.json". The translation extractor couldn't find these and the terms were never extracted, resulting in missing translations. This commit searches for both filename patterns to export the terms. We also make sure that file references are only extracted once per term per file. Related to https://github.com/odoo/enterprise/pull/75605 Forward-Port-Of: odoo/odoo#191274 Forward-Port-Of: odoo/odoo#190598
1 change
Resolved issues and error corrections
This update resolves an issue where the kiosk URL was incorrectly using the main website domain. The fix ensures the kiosk URL always uses the correct base URL, providing a consistent and reliable experience for users accessing the system in kiosk mode. This improves the overall functionality and stability of the Frontdesk module.
Original PR description
issue: when website is active and have a domain then the kiosk_url take the webiste domain as base_url - override `get_base_url` to return the `'web.base.url'` Task: 3903743