Monday, January 13, 2025
23 changes · saas-17.2
Miscellaneous changes
Before this commit: When the user clicks on the studio icon just after opening any app before its view gets loaded, the traceback will occur because the `get_view` method has not yet loaded. After this commit: Traceback will not occur. Task-4348166 Forward-Port-Of: odoo/enterprise#75881
Original PR description
Before this commit: When the user clicks on the studio icon just after opening any app before its view gets loaded, the traceback will occur because the `get_view` method has not yet loaded. After this commit: Traceback will not occur. Task-4348166 Forward-Port-Of: odoo/enterprise#75881
Currently * "Fecha Expedición" = accounting date * "Fecha Operación" = invoice date (only set if different from accounting date) After this commit * "Fecha Expedición" = invoice date * "Fecha Operación" = delivery date (only set if different from invoice date) This is the same way the fields are handled in the spanish EDIs too (see related community PR). opw-4367470 Community PR: https://github.com/odoo/odoo/pull/192467 Forward-Port-Of: odoo/enterprise#76523
Original PR description
Currently * "Fecha Expedición" = accounting date * "Fecha Operación" = invoice date (only set if different from accounting date) After this commit * "Fecha Expedición" = invoice date * "Fecha Operación" = delivery date (only set if different from invoice date) This is the same way the fields are handled in the spanish EDIs too (see related community PR). opw-4367470 Community PR: https://github.com/odoo/odoo/pull/192467 Forward-Port-Of: odoo/enterprise#76523
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
When disabling the journals options of the journal reports, we have a traceback since the journals is not in the options anymore. opw-4342749 Forward-Port-Of: odoo/enterprise#76807 Forward-Port-Of: odoo/enterprise#76538
Original PR description
When disabling the journals options of the journal reports, we have a traceback since the journals is not in the options anymore. opw-4342749 Forward-Port-Of: odoo/enterprise#76807 Forward-Port-Of: odoo/enterprise#76538
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 Forward-Port-Of: odoo/enterprise#76522
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 Forward-Port-Of: odoo/enterprise#76522
Before this commit, when editing a default value for a field, it was always setting th default on the company of the user (as set on the user), not on the current company the user is logged into. This was largely misleading. After this commit, we get and set the default on the current company. Some work need to be done in master to improve those flows. opw-4427384 Forward-Port-Of: odoo/enterprise#76819
Original PR description
Before this commit, when editing a default value for a field, it was always setting th default on the company of the user (as set on the user), not on the current company the user is logged into. This was largely misleading. After this commit, we get and set the default on the current company. Some work need to be done in master to improve those flows. opw-4427384 Forward-Port-Of: odoo/enterprise#76819
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#75180
**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
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