Monday, January 13, 2025
41 changes · 18.0
Enhancements to existing features
This change updates the US check printing app to avoid issues in automated validation environments. It helps keep internal quality checks running smoothly without changing day-to-day business workflows.
Original PR description
Task 47452
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
This fix ensures automated website tour checks fully stop when they detect an uncertain or inconsistent step. It prevents leftover background monitoring from continuing after a failure, making test results cleaner and more reliable.
Original PR description
The function checkForUndeterminisms in the TourStepAutomatic class throws an error in the case where an indeterminism is found. However, in the TourAutomatic class, we used this.throwError which throws the error but does not stop the macro (Does not go through the stop method of the Macro class). As a result, the observable is not disconnected and the macro is not stopped properly. In this commit, we make sure that the macro is stopped properly. 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
Code cleanup and technical improvements
This change removes an unnecessary naming option from website tour setup, making the underlying tour system simpler to maintain. It should not change the user experience, aside from keeping the homepage tour behavior intact through a cleaner implementation.
Original PR description
In this commit, in order to simplify the tours API, we remove the saveAs attribute from the tour object definition. This attribute does not bring anything in the sense that it just allows not to create in the registry a tour that could already exist and to save it under another name to have access to it from tour_service. To avoid the error of creating a key that already exists in the registry, simply remove it before adding it again. This is only used in the website module for the homepage tour. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
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#193436 Forward-Port-Of: odoo/odoo#193257
Spreadsheet users now get auto-complete suggestions for the account group type field, making it easier to use account group formulas without needing technical knowledge. This reduces guesswork and helps users enter valid values faster.
Original PR description
Currently, there's no way to know what are the valid/expected values for the "type" argument of ODOO.ACCOUNT.GROUP. It makes it almost impossible to use if you are not technical and you can't go and check the code. The valid inputs are the *technical* value of the selection field `account_type`. I had to copy-paste and hard-code the selection field option. This is clearly not ideal (not a single source of truth), but the current auto-complete system is synchronous. I can't make a server call to fetch all the options. Besides, the UX is better if the auto-complete shows up instantly rather than having to wait for a network round-trip. Task: 4465573 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a visual issue in the Accounting dashboard where activity dates for Miscellaneous journals could wrap onto a new line. Keeping the date on the same line improves readability and keeps the dashboard layout consistent.
Original PR description
After commit odoo/odoo@6e4a036, the activity date component breaks onto a new line. This fix ensures that the activity date remains on the same line and no longer wraps. opw-4402682 **Description of…
After commit odoo/odoo@6e4a036, the activity date component breaks onto a new line. This fix ensures that the activity date remains on the same line and no longer wraps. opw-4402682 **Description of the issue/feature this PR addresses:** - In the Accounting dashboard, when an activity is set on an account journal of type `Miscellaneous`, the `date` component of the `activity` is not aligned properly. - The date component breaks into a new line, causing a misalignment in the display. - This fix aims to fix the display issue by ensuring the activity date remains properly aligned on the same line as the rest of the content. - It prevents the date component from wrapping onto the next line, thereby improving the visual consistency of the dashboard. **Current behavior before PR:** The `activity date` falls onto the next line.  **Desired behavior after PR is merged:** The `activity date` stays on the same line.  **Steps to reproduce activity date display issue :** - Install the Accounting module. - Navigate to the Accounting dashboard. - Create a new account journal of type `Miscellaneous` - Set an `activity` on that journal. - Return to the dashboard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes issues around displaying avatars in WhatsApp-related conversations and strengthens related test coverage. It helps ensure user images load correctly while keeping access behavior reliable and secure.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/187799
Text placeholders in the Documents app are now correctly included in translation files. This ensures users working in other languages see properly translated guidance instead of untranslated English text.
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)
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
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
opw-4409456 Forward-Port-Of: odoo/odoo#192863
Original PR description
opw-4409456 Forward-Port-Of: odoo/odoo#192863
Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve happens when 2 different commercial entities use the same paying partner (ie a partner that is not a subcontact) to pay their invoices. When an invoice is paid by the paying partner, Odoo will store the account number that was used for the transfer on account.bank.statement.line. When this statem
Original PR description
Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve…
Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve happens when 2 different commercial entities use the same paying partner (ie a partner that is not a subcontact) to pay their invoices. When an invoice is paid by the paying partner, Odoo will store the account number that was used for the transfer on account.bank.statement.line. When this statement line is reconciled with an invoice, if the bank account was not stored on the partner previously, a res.partner.bank will be created automatically. When another payment is coming from the same bank account, Odoo will then select the partner linked to the bank account that it did store previously, even if the payment was for an invoice linked to another partner, and it will not propose the proper invoice in the reconciliation widget, even if it uses an exact match on the payment reference number. Having a parameter allowing to skip creation of the bank account in Odoo will allow the reconciliation to be based striclty on the reference number. Current behavior before PR: Bank account is stored and wrong invoices are proposed by the reconciliation widget Desired behavior after PR is merged: Allow to avoid storing bank account and having wrong invoices are proposed by the reconciliation widget --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173546 Forward-Port-Of: odoo/odoo#168029
Steps to reproduce ================== - Install industry_fsm,web_studio - Go to Field Service - Switch to the calendar view - Open studio - Unset the color => fields[fieldMapping.color] is undefined Cause of the issue ================== We have a field that has the color attribute with a value of color. ```xml <field name="worksheet_template_id" attrs="{'invisible': [('worksheet_template_id', '=', False)]}" filters="1" color="color"/> ``` `shouldFetchColor` checks if th
Original PR description
Steps to reproduce
==================
- Install industry_fsm,web_studio
- Go to Field Service
- Switch to the calendar view
- Open studio
- Unset the color
=> fields[fieldMapping.color] is undefined
Cause of the issue
==================
We have a field that has the color attribute with a value of color.
```xml
<field name="worksheet_template_id" attrs="{'invisible': [('worksheet_template_id', '=', False)]}" filters="1" color="color"/>
```
`shouldFetchColor` checks if the filter color is the same one as the calendar record color.
Solution
========
Since it's possible to have a color filter without a record color, we should fetch the filter colors in that case.
opw-4443497
Forward-Port-Of: odoo/odoo#193018
Forward-Port-Of: odoo/odoo#192334The 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, validating a split bill that contains a combo product would result in a key error. opw-4416406 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192384
Original PR description
Before this commit, validating a split bill that contains a combo product would result in a key error. opw-4416406 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192384
Previously, settling a sale.order from the POS of a Belgian company would auto check the invoice option before paying. Steps to reproduce: ------------------- * Install `l10n_be_pos_cert` * Switch to the Beligian company * Crete a quotation in **Sale** app * Add any partner and any product, remove all taxes for the product line * Save * Open pos shop * Settle the order * Go to the payment screen > Observation: The invoice button is already selected. Why the fix: ------------ T
Original PR description
Previously, settling a sale.order from the POS of a Belgian company would auto check the invoice option before paying. Steps to reproduce: ------------------- * Install `l10n_be_pos_cert` * Switch to…
Previously, settling a sale.order from the POS of a Belgian company would auto check the invoice option before paying. Steps to reproduce: ------------------- * Install `l10n_be_pos_cert` * Switch to the Beligian company * Crete a quotation in **Sale** app * Add any partner and any product, remove all taxes for the product line * Save * Open pos shop * Settle the order * Go to the payment screen > Observation: The invoice button is already selected. Why the fix: ------------ This invoice option was auto selected since this commit: https://github.com/odoo/odoo/commit/c760fbb1bd2e7725b5e759198684a07060612033 The following commit https://github.com/odoo/odoo/commit/3a5e22218708b4b6c9aedfa965d9f3c279edbd46 updates the previous one as the invoice enforcement is only needed when we have intracom taxes on the SO. Thus when no intracom taxes apply we can still decide wether or not to invoice. We fallback on the default behavior which is to have the invoice button un-selected. opw-4334095 Forward-Port-Of: odoo/odoo#191290 Forward-Port-Of: odoo/odoo#188400
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-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#192483I 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#172881The label of the "Task" field in the wizard that opens when you "Add a line" to "My Timesheets" was not exportable for translation after [this commit] and thus never translated in the UI. This commit fixes that. <img width="851" alt="image" src="https://github.com/user-attachments/assets/5477ab35-7f84-402e-8d62-1dd8d8edd8ca" /> [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Fo
Original PR description
The label of the "Task" field in the wizard that opens when you "Add a line" to "My Timesheets" was not exportable for translation after [this commit] and thus never translated in the UI. This commit fixes that. <img width="851" alt="image" src="https://github.com/user-attachments/assets/5477ab35-7f84-402e-8d62-1dd8d8edd8ca" /> [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#193108
In the Tasks Analysis, the field `overtime` can be used as a measure in the graph and pivot views. However, the field name was set as not translatable and thus always showing in English after [this commit]. We make it translatable again here so it can be localized. [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#193058
Original PR description
In the Tasks Analysis, the field `overtime` can be used as a measure in the graph and pivot views. However, the field name was set as not translatable and thus always showing in English after [this commit]. We make it translatable again here so it can be localized. [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#193058
Before this commit, data stored in IndexedDB could fail to serialize correctly due to Proxy-wrapped objects, resulting in errors when saving data. opw-4367293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188967
Original PR description
Before this commit, data stored in IndexedDB could fail to serialize correctly due to Proxy-wrapped objects, resulting in errors when saving data. opw-4367293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188967
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
**Steps to reproduce:** - Install l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice with "Simplified Invoice Partner (ES)" as customer - Confirm the invoice - Process the invoice with "TicketBAI (ES)" service **Issue:** The generated XML has 2 regime keys (02 and 52) for <ClaveRegimenIvaOpTrascendencia> that are not compatible with each other. From the documentation, regime key "52" (for simplified invoices) can only be associated with regime key "51"
Original PR description
**Steps to reproduce:** - Install l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice with "Simplified Invoice Partner (ES)" as customer - Confirm the invoice - Process the invoice with "TicketBAI (ES)" service **Issue:** The generated XML has 2 regime keys (02 and 52) for <ClaveRegimenIvaOpTrascendencia> that are not compatible with each other. From the documentation, regime key "52" (for simplified invoices) can only be associated with regime key "51", which is not supported for the moment. **Solution:** If the "Simplified Invoice Partner" is used, only the regime key "52" is used. opw-4332052 opw-4355424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192687 Forward-Port-Of: odoo/odoo#192448
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:** - 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
Steps: === - Open a POS shop. - Create an order, select a customer, and validate it. Issue: === - The generated receipt did not include customer name and phone details. Cause: === - Customer details were not being passed correctly to the receipt template. Fix: === - Updated the function for setting customer details to correctly include in the receipt. Task- 4431623 Forward-Port-Of: odoo/odoo#193084 Forward-Port-Of: odoo/odoo#191972
Original PR description
Steps: === - Open a POS shop. - Create an order, select a customer, and validate it. Issue: === - The generated receipt did not include customer name and phone details. Cause: === - Customer details were not being passed correctly to the receipt template. Fix: === - Updated the function for setting customer details to correctly include in the receipt. Task- 4431623 Forward-Port-Of: odoo/odoo#193084 Forward-Port-Of: odoo/odoo#191972
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
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 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
Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish your team, that menu is visible or invisible as a public user. 3. Create a new menu for your website, with that same URL (/helpdesk/customer-care-1) 4. Check: that menu is always invisible as a public user. Even if you remove the first menu. Multiple mistakes were made with [1]: - Th
Original PR description
Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish…
Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish your team, that menu is visible or invisible as a public user. 3. Create a new menu for your website, with that same URL (/helpdesk/customer-care-1) 4. Check: that menu is always invisible as a public user. Even if you remove the first menu. Multiple mistakes were made with [1]: - The website menu visibility override code was added twice in two different files. - The override advertises that this is for "always showing the helpdesk team menus even if they are unpublished" but it is actually meant to be the exact opposite of that. - The implementation is based on the menu that are linked to the helpdesk teams, not on their URL **. - The implementation actually bypass the normal visibility computation for all menu URL that start with "/helpdesk", meaning a custom page "/helpdesk-hello" from the user is just broken, so as existing controllers not linked to an helpdesk team (such as /helpdesk/rating). **: actually this could mean that this feature is just not meant to be given the current state of the codebase: creating a menu with a team URL should just make it so it is forcefully linked to that team or should be prevented if it cannot (?). [1]: https://github.com/odoo/enterprise/commit/a888fb57ebd2458bc8479e187088cb2e96b811fa opw-3931376 Forward-Port-Of: odoo/enterprise#76384 Forward-Port-Of: odoo/enterprise#63105
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
Backport of a00faee178b94e455a670fb59a3c77c3827b3b49 Forward-Port-Of: odoo/enterprise#76769 Forward-Port-Of: odoo/enterprise#76541
Original PR description
Backport of a00faee178b94e455a670fb59a3c77c3827b3b49 Forward-Port-Of: odoo/enterprise#76769 Forward-Port-Of: odoo/enterprise#76541
…endar editor Steps to reproduce ================== - Install industry_fsm,web_studio - Go to Field Service - Switch to the calendar view - Open studio => The color value is empty, it should be "Color" Cause of the issue ================== We only keep many2one and selection fields, but in this case, it's an integer field. Solution ======== Here's a few example where integer field are used: [planning_view_calendar] and [project_task_view_calendar_fsm_worksheet]. => Kee
Original PR description
…endar editor Steps to reproduce ================== - Install industry_fsm,web_studio - Go to Field Service - Switch to the calendar view - Open studio => The color value is empty, it should be "Color" Cause of the issue ================== We only keep many2one and selection fields, but in this case, it's an integer field. Solution ======== Here's a few example where integer field are used: [planning_view_calendar] and [project_task_view_calendar_fsm_worksheet]. => Keep integer fields --- [planning_view_calendar]: https://github.com/odoo/enterprise/blob/c37ed1a684fd9b91e394b7b14f282b9ebabcb751/planning/views/planning_views.xml#L332 [project_task_view_calendar_fsm_worksheet]: https://github.com/odoo/enterprise/blob/3205a82c4616b969b87aa2f6d05a2da636688037/industry_fsm_report/views/project_views.xml#L29 opw-4443497 Forward-Port-Of: odoo/enterprise#76789 Forward-Port-Of: odoo/enterprise#76454
The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files. This commit re-exports all spreadsheet pot files again using the fixed code. Related to https://github.com/odoo/odoo/pull/190598 Forward-Port-Of: odoo/enterprise#75930 Forward-Port-Of: odoo/enterprise#75605
Original PR description
The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files. This commit re-exports all spreadsheet pot files again using the fixed code. Related to https://github.com/odoo/odoo/pull/190598 Forward-Port-Of: odoo/enterprise#75930 Forward-Port-Of: odoo/enterprise#75605
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
**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 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