Friday, January 27, 2023
52 changes · master
Enhancements to existing features
The Uruguayan localization content has been rewritten in English and paired with Spanish translation files. This aligns the module with Odoo localization standards, making it easier to maintain while preserving Spanish language support for users in Uruguay.
Original PR description
All the localisation should be written in english and then translated to the native language of the country. In this case, the Uruguayan localisation was written is Spanish, this PR translate the module in english and add the corresponding PO file in spanish. Task-id: 3126154 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The live messaging service can now be extended to handle more types of real-time events. This makes it easier to add future custom behavior without changing the core websocket entry point.
Original PR description
PURPOSE: Currently `_serve_ir_websocket` can handle only two events. You can't add custom events to this method. Make this method extensible to handle more events for `Websocket` bus service. SPECIFICATION: Moved `_serve_ir_websocket` method to `IrWebsocket` model. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Costa Rica localization content has been standardized so its source text is in English, with Spanish provided through translations. This improves consistency with Odoo localization practices and makes future translation maintenance easier.
Original PR description
Before this PR, all this localisation was written in spanish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that. Task-id: 3149070 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Finnish localization module now uses English source text with Finnish translations maintained separately. This improves translation consistency and makes future updates easier for multilingual deployments.
Original PR description
Before this PR, all this localisation was written in Finnish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that. Task-id: 3151267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Dutch localization content has been converted to English as the source language, with Dutch translations added separately. This improves consistency with Odoo localization standards and makes future maintenance and translation updates easier.
Original PR description
All the localisation should be written in english and then translated to the native language of the country. In this case, the Dutch localisation was written is Dutch, this PR translate all the module in english and add the corresponding PO file in Dutch. Task-id: 3115909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The accounting interface now makes debit note actions less prominent, reflecting that these documents are rarely used in many markets. This helps keep critical accounting screens focused on the most common workflows while still preserving debit note functionality for localizations that need it.
Original PR description
Debit Notes are a type of financial documents that is not very often used. Even though it's an official document type, in many countries their usage is not Odoo does not come with a preinstalled Debit Note management, but it can be added by installing the module account_debit_note. The module as mostly been developped following localisation requirements, and while it's a corner case, it appears all the time in one of our most critical screen. Let's make it a bit more discrete. task-3125955 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
The follow-up report now explains more clearly what the assigned responsible person means. This helps users understand that the role applies specifically to manual follow-up activities, reducing confusion when managing customer follow-ups.
Original PR description
The tooltip for `followup_responsible_id` should specify what responsible of follow-up report means, an highlight it concerns the manual follow up activities. task-3145326
Data cleaning and data merge now use clearer notification settings where available instead of relying on hidden context values. This is a minor internal improvement that supports cleaner maintenance and more consistent communication behavior.
Original PR description
Just use a parameter instead of a context key when possible. See community PR for more details. Followup of odoo/odoo#99482 Task-2710804 (Mail: Clean MailThread API)
The Dutch reporting module now uses English as the source language and provides Dutch translations separately. This improves consistency across localizations and helps maintain accurate Dutch financial report labels for users.
Original PR description
All the localisation should be written in english and then translated to the native language of the country. In this case, the Dutch localisation was written is Dutch, this PR translate all the module in english and add the corresponding PO file in Dutch. Task-id: 3115909
The Finnish reporting module now keeps its report labels in English as the source language and provides Finnish through translations. This makes the localization easier to maintain consistently while preserving the Finnish user experience.
Original PR description
Before this PR, all this localisation was written in Finnish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that. Task-id: 3151267
Resolved issues and error corrections
This change fixes a randomly failing automated test in the web module by ensuring an autocomplete menu is ready before the test selects an item. It helps keep Odoo's quality checks stable and reduces false failures during development.
Original PR description
Before this commit, the changed test sometimes failed because the autocomplete dropdown wasn't opened yet when we tried to click on one of its items. Setting the autocomplete delay to 0 doesn't remove the setTimeout, but overriding the setTimeout method from browser like this commit does ensures the callback (i.e. the dropdown opening) is called directly. Fixes runbot error 15715 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 reorganizes how Odoo’s guided tours and related test flows are registered behind the scenes. It supports a more reliable technical foundation for future development without changing day-to-day user behavior.
Miscellaneous changes
Before this commit, the dbuuid was added to the session info in order to reset the last known notification id. This is not necessary since #103025. Indeed, if the last notification passed to the server is superior to the last one, the last notification default to 0. This commit removes this information from the session info. Forward-Port-Of: odoo/odoo#111102
Original PR description
Before this commit, the dbuuid was added to the session info in order to reset the last known notification id. This is not necessary since #103025. Indeed, if the last notification passed to the server is superior to the last one, the last notification default to 0. This commit removes this information from the session info. Forward-Port-Of: odoo/odoo#111102
The Panama localization content has been converted to English as the base language, with Spanish translations added separately. This improves consistency across Odoo localizations and makes future translation maintenance easier.
Original PR description
All the localisation should be written in english and then translated to the native language of the country. In this case, the Panama localisation was written is Spanish, this PR translate the module in english and add the corresponding PO file in spanish. Task-id: 3127385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where loyalty reward information was sent to the restaurant point of sale in the wrong format. The change helps prevent frontend errors so staff can process orders with loyalty rewards more reliably.
Original PR description
Previously, `reward_id` was an array of two elements containing the ID and name of the reward. But in the frontend, `reward_id` is supposed to be an int with the ID Adaptation of the `_prepare_order_line` function in the following modules: - `point_of_sale` - `pos_restaurant` - `pos_loyalty` Now the data is correctly sent to the frontend and the error is no longer present. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
This is a step closer to a goal of avoiding dependence on asynchronous modules. Starting from this commit, new tour definition should be registered to `registry.category("web_tour.tours")` registry.…
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change updates how automated product tours are collected across several Odoo apps, aligning them with a shared internal registry. It should not change day-to-day user workflows, but it improves maintainability and consistency of testing infrastructure.
Original PR description
Related to: https://github.com/odoo/odoo/pull/111103
The spreadsheet document tools now use Odoo’s standard menu selection component instead of a custom field widget. This keeps the user experience more consistent across Odoo and reduces maintenance risk for future updates.
Original PR description
This commit remove our custom widget do display a many2one field and replace it by the web Many2XAutocomplete component. Odoo task [3103695](https://www.odoo.com/web#id=3103695&menu_id=4720&cids=1&action=333&active_id=2328&model=project.task&view_type=form)
Currently, the `Send E-waybill` button show in all company no matter what company is installed. So In this commit, we check whether the invoice company country code is `IN` or not, based on that we hide/unhide the `Send E-waybill` button. Forward-Port-Of: odoo/odoo#110239
Original PR description
Currently, the `Send E-waybill` button show in all company no matter what company is installed. So In this commit, we check whether the invoice company country code is `IN` or not, based on that we hide/unhide the `Send E-waybill` button. Forward-Port-Of: odoo/odoo#110239
Steps to reproduce: - go to Time Off app. Issue: Dates in the dashboard do not respect the language format. Cause: We give a date format to the `format_date` function. This function applies this format and not the language format. opw-3138369 Forward-Port-Of: odoo/odoo#111038
Original PR description
Steps to reproduce: - go to Time Off app. Issue: Dates in the dashboard do not respect the language format. Cause: We give a date format to the `format_date` function. This function applies this format and not the language format. opw-3138369 Forward-Port-Of: odoo/odoo#111038
Steps to reproduce: - install Time Off and Attendances apps; - making sure an employee doesn't have extra hours; - create a time off type which is "Deduct Extra Hours" (A); - create a time off type which is not "Deduct Extra Hours" (B); - create a time off with the type (A); - save; - edit the time off with the type (B); - save. Issue: The time off is modified and it is possible to approve it. Solution: Check that the employee has enough extra hours if the type of time off used
Original PR description
Steps to reproduce: - install Time Off and Attendances apps; - making sure an employee doesn't have extra hours; - create a time off type which is "Deduct Extra Hours" (A); - create a time off type which is not "Deduct Extra Hours" (B); - create a time off with the type (A); - save; - edit the time off with the type (B); - save. Issue: The time off is modified and it is possible to approve it. Solution: Check that the employee has enough extra hours if the type of time off used is "Deduct Extra Hours". opw-3141108 Forward-Port-Of: odoo/odoo#111043
This commit fixes a function call that was trying to call on `this` while the function is imported and not assigned to the object. Forward-Port-Of: odoo/odoo#110868
Original PR description
This commit fixes a function call that was trying to call on `this` while the function is imported and not assigned to the object. Forward-Port-Of: odoo/odoo#110868
Before this commit, the creation date and last modification date in the metadata dialog (in debug, in any form view, click on the debug item, then View Metadata) were displayed in UTC, whereas they should be formatted in the user timezone. This commit fixes the issue. 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 Forwa
Original PR description
Before this commit, the creation date and last modification date in the metadata dialog (in debug, in any form view, click on the debug item, then View Metadata) were displayed in UTC, whereas they should be formatted in the user timezone. This commit fixes the issue. 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#111105
When opening a work order and the quantity_producing is set at 0 by default, and since it is not possible to record 0 as done, the user always gets an error message when trying to carry on without manually editing that quantity producing field. This is not very user friendly as a manual input there on any device is burdensome. This fix automatically sets qty_producing to be equal to qty_remaining in workorders for non-unique serial products when opening a workorder if the quantity is zero. ta
Original PR description
When opening a work order and the quantity_producing is set at 0 by default, and since it is not possible to record 0 as done, the user always gets an error message when trying to carry on without manually editing that quantity producing field. This is not very user friendly as a manual input there on any device is burdensome. This fix automatically sets qty_producing to be equal to qty_remaining in workorders for non-unique serial products when opening a workorder if the quantity is zero. task 3113153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#109725
If a field is present twice in a view, the field information stored in the relational model `activeFields` holds and consider only the latest xml node found. Therefore, a field is sometimes considered alwaysInvisible when it is visible and editable. This means that you might click on the 'Save' button and get a server error because a required field is not set when you should the required field should have been highlighted and requested before making a `create` rpc request. This commit mak
Original PR description
If a field is present twice in a view, the field information stored in the relational model `activeFields` holds and consider only the latest xml node found. Therefore, a field is sometimes considered alwaysInvisible when it is visible and editable. This means that you might click on the 'Save' button and get a server error because a required field is not set when you should the required field should have been highlighted and requested before making a `create` rpc request. This commit makes sure that for the alwaysInvisible logic, both nodes are considered. 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#110924
Steps to reproduce: - create an employee and fill in the email address; - duplicate this employee; - change the email address of the new employee. Issue: The email address is changed on both employees. Cause: When we duplicate an employee, we keep the same contact. By modifying the email address, we will modify the contact's email address. Then we "synchronise" all employees with their contact using the contact information. Solution: When an employee is duplicated, a new contact m
Original PR description
Steps to reproduce: - create an employee and fill in the email address; - duplicate this employee; - change the email address of the new employee. Issue: The email address is changed on both employees. Cause: When we duplicate an employee, we keep the same contact. By modifying the email address, we will modify the contact's email address. Then we "synchronise" all employees with their contact using the contact information. Solution: When an employee is duplicated, a new contact must be created. Therefore it is necessary to avoid copying the `work_contact_id` field. opw-3144129 Forward-Port-Of: odoo/odoo#111174
Commit [1] removed the last listener to the 'ready_to_save' event and commit [2] removed the trigger of that event once and for all afterwards ... but it kept local code related to awaiting the operations the event induced. This commit prepares the removal of that dead code. [1]: https://github.com/odoo/odoo/commit/00080f4b736c84eedd3f15e99004c1473cb78f37 [2]: https://github.com/odoo/odoo/commit/10af6e83bf318db7fe245038f0c66d68b9fa7957 Forward-Port-Of: odoo/odoo#111129
Original PR description
Commit [1] removed the last listener to the 'ready_to_save' event and commit [2] removed the trigger of that event once and for all afterwards ... but it kept local code related to awaiting the operations the event induced. This commit prepares the removal of that dead code. [1]: https://github.com/odoo/odoo/commit/00080f4b736c84eedd3f15e99004c1473cb78f37 [2]: https://github.com/odoo/odoo/commit/10af6e83bf318db7fe245038f0c66d68b9fa7957 Forward-Port-Of: odoo/odoo#111129
Have a product P configured with: * Product Type: Storable Product * Product category: * costing method: standard * Inventory Valuation Automated * Price Difference Account: "500000 Cost of Goods Sold" * Cost $100 Activate Multicurrency: * USD main currency, CZK foreign currency * On CZK set the rates * date1, Unit per USD: 30 * date2, Unit per USD: 25 (date2 > date1) * date3, Unit per USD: 26 (date3 > date2) Create a purchase order: * Date: date2 * Currency:
Original PR description
Have a product P configured with: * Product Type: Storable Product * Product category: * costing method: standard * Inventory Valuation Automated * Price Difference Account: "500000 Cost of Goods…
Have a product P configured with: * Product Type: Storable Product * Product category: * costing method: standard * Inventory Valuation Automated * Price Difference Account: "500000 Cost of Goods Sold" * Cost $100 Activate Multicurrency: * USD main currency, CZK foreign currency * On CZK set the rates * date1, Unit per USD: 30 * date2, Unit per USD: 25 (date2 > date1) * date3, Unit per USD: 26 (date3 > date2) Create a purchase order: * Date: date2 * Currency: CZK * Order line: * Product P * Quantity 10 * Unit price 3000 Confirm, receive product on date2 (svl needs to be in date2) Create the vendor bill with: * Bill date: date 1 * Accounting date: date 3 Confirm the bill Issue Check the bill journal items. Price difference account is debited with 4000 czk. This amount is not correct. The valuation layer price unit is 100$ At the receipt date the price unit should be 2500czk The price unit difference 3000-2500 = 500czk Price difference 500*10 = 5000czk The issue occur because the price difference unit is converted at bill accounting date, resulting in 4000czk opw-3063809 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#109022 Forward-Port-Of: odoo/odoo#108180
Update translation of `Sales Order` from `Aufträgen` to `Verkaufsauftrag`. opw-3052426 Forward-Port-Of: odoo/odoo#110719
Original PR description
Update translation of `Sales Order` from `Aufträgen` to `Verkaufsauftrag`. opw-3052426 Forward-Port-Of: odoo/odoo#110719
before this commit, when try to create a sale order without inputting pricelist field it was showing exception like "The operation cannot be completed: - Create/update: a mandatory field is not set." after this commit, user cannot save the record without filling pricelist field --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110647
Original PR description
before this commit, when try to create a sale order without inputting pricelist field it was showing exception like "The operation cannot be completed: - Create/update: a mandatory field is not set." after this commit, user cannot save the record without filling pricelist field --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110647
[IMP] base: support batch import for import_lang Before this commit: Importing multiple translations was failing due to concurrent update After this commit: 1. `translation_importer.save` is moved out of the `try except` to prevent `UserError` overriding `OperationalError`. So the service can retry the transaction. 2. batch import is supported to allow RPC to import multiple translations at once, which is faster and has lower chance to trigger OperationalError Forward-Port-Of: odoo/
Original PR description
[IMP] base: support batch import for import_lang Before this commit: Importing multiple translations was failing due to concurrent update After this commit: 1. `translation_importer.save` is moved out of the `try except` to prevent `UserError` overriding `OperationalError`. So the service can retry the transaction. 2. batch import is supported to allow RPC to import multiple translations at once, which is faster and has lower chance to trigger OperationalError Forward-Port-Of: odoo/odoo#110419
Since [1] when selecting item images, the 'Blocks' tab is displayed while the options are refreshed. This is visible because the image selection awaits an RPC which therefore allows the browser to render the 'Blocks' tab selected version of the display. This commit prevents the return to the 'Blocks' tab to be rendered by waiting for the image info to be obtained on start. Steps to reproduce: - Drop an "Items" block. - Click on an image. - Click on another image. => The options pan
Original PR description
Since [1] when selecting item images, the 'Blocks' tab is displayed while the options are refreshed. This is visible because the image selection awaits an RPC which therefore allows the browser to render the 'Blocks' tab selected version of the display. This commit prevents the return to the 'Blocks' tab to be rendered by waiting for the image info to be obtained on start. Steps to reproduce: - Drop an "Items" block. - Click on an image. - Click on another image. => The options panel flickers on the 'Blocks' tab before showing the second image's options. [1]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e task-2821398 Co-authored-by: Benoit Socias <bso@odoo.com> Forward-Port-Of: odoo/odoo#91929
Steps to reproduce: - In Time Off, select a day in Month or Year view - Save your time-off Issue: In the Week view, the time off starts at 7 and ends at 19 Cause: The default_get uses the default start and end given on JS side https://github.com/odoo/odoo/blob/d2f3275eee6d3a8a7f5e69ff938d36ceda771346/addons/web/static/src/legacy/js/views/calendar/calendar_model.js#L74-L75. Solution: Use something like https://github.com/odoo/odoo/blob/master/addons/hr_holidays/models/hr_leave.py#L1
Original PR description
Steps to reproduce: - In Time Off, select a day in Month or Year view - Save your time-off Issue: In the Week view, the time off starts at 7 and ends at 19 Cause: The default_get uses the default start and end given on JS side https://github.com/odoo/odoo/blob/d2f3275eee6d3a8a7f5e69ff938d36ceda771346/addons/web/static/src/legacy/js/views/calendar/calendar_model.js#L74-L75. Solution: Use something like https://github.com/odoo/odoo/blob/master/addons/hr_holidays/models/hr_leave.py#L104-L110 from this pr: https://github.com/odoo/odoo/pull/77036 For that to work I had to add also the function used in it. opw-3010846 Forward-Port-Of: odoo/odoo#110977 Forward-Port-Of: odoo/odoo#106781
The lack of a default `options` parameter for `toggleLinkTools` led to a trace when this method was called without parameters. This method was introduced by [1]. This commit fixes it by adding an empty object as default parameter. [1]: https://github.com/odoo/odoo/pull/106796/commits/862d93f9eef16ec45b0d27b246fae560f7feaf1e opw-3149496 opw-3151829 task-3151708 Forward-Port-Of: odoo/odoo#111104
Original PR description
The lack of a default `options` parameter for `toggleLinkTools` led to a trace when this method was called without parameters. This method was introduced by [1]. This commit fixes it by adding an empty object as default parameter. [1]: https://github.com/odoo/odoo/pull/106796/commits/862d93f9eef16ec45b0d27b246fae560f7feaf1e opw-3149496 opw-3151829 task-3151708 Forward-Port-Of: odoo/odoo#111104
Steps to reproduce: - increase price_precision in decimal accuracy (in debug mode) - create a product with multiple digits - create a PO with that product - unit price is rounded to 2 digits (currency pricision) Bug: in previous versions conversion was only done if currency was different Fix: do not round during conversion and round to the highest digits (alternatively we could revert to only converting if currecy is different and accept the loss of precission in that case) the wr
Original PR description
Steps to reproduce: - increase price_precision in decimal accuracy (in debug mode) - create a product with multiple digits - create a PO with that product - unit price is rounded to 2 digits (currency pricision) Bug: in previous versions conversion was only done if currency was different Fix: do not round during conversion and round to the highest digits (alternatively we could revert to only converting if currecy is different and accept the loss of precission in that case) the wrong currency was used also for the conversion opw-3050044 Forward-Port-Of: odoo/odoo#108970
With the new 16.0 feature that open any form in edit mode, the html editor was trying to connect in collaboration each time a record was opened in a form view that has a collaborative html field. The peer to peer connection could trigger a lot of rpc because of it's communication through the bus. This commit reduces the number of rpc by only trying to connect to the collaboration network when the user focus the html editor. task-3151577 --- I confirm I have signed the CLA and rea
Original PR description
With the new 16.0 feature that open any form in edit mode, the html editor was trying to connect in collaboration each time a record was opened in a form view that has a collaborative html field. The peer to peer connection could trigger a lot of rpc because of it's communication through the bus. This commit reduces the number of rpc by only trying to connect to the collaboration network when the user focus the html editor. task-3151577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#111109
To reproduce the issue: 1. Install [Accounting] on Apps 2. On [Settings], - [Users & Companies]>[Companies]: add a company with country Belgium - Set the company to the Belgian one - add French, set the language to it - [General Settings] - check the [Companies] section Desired behavior: Correction of VAT label Impacted versions: 14.0 up to master opw-3104416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#
Original PR description
To reproduce the issue: 1. Install [Accounting] on Apps 2. On [Settings], - [Users & Companies]>[Companies]: add a company with country Belgium - Set the company to the Belgian one - add French, set the language to it - [General Settings] - check the [Companies] section Desired behavior: Correction of VAT label Impacted versions: 14.0 up to master opw-3104416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110925
Before this commit, the default group by on task list view in Field Service app is stage as it is the case in Project app, this behavior is not wanted, the list view in Field Service app should have no group by by default. Also, the default group by in My tasks should be personal stages and no default group by should be in the list view of All Tasks menu. Finally, the parent task has been removed in the main list view instead of displaying in debug mode. This commit fixes the list view in Fie
Original PR description
Before this commit, the default group by on task list view in Field Service app is stage as it is the case in Project app, this behavior is not wanted, the list view in Field Service app should have no group by by default. Also, the default group by in My tasks should be personal stages and no default group by should be in the list view of All Tasks menu. Finally, the parent task has been removed in the main list view instead of displaying in debug mode. This commit fixes the list view in Field Service to avoid having any group by by default and also changes the default group by `My Tasks` and `All tasks` menu. It also adds the parent task field in the main list view of task and that field will be displayed if the "Sub-tasks" feature and the debug mode is enabled. X-original-commit: b77f60b155bf97a115aa209847dc791677b2e924 Forward-Port-Of: odoo/odoo#110368
The aim of this commit is to fix an issue where the settings fields for the Indonesian localization were visible in all companies of a database. Context: In a multi-company environment, a company may have its fiscal country set to Indonesia and have the Indonesian localization activated, but this should only affect the options shown in the accounting settings for that specific company. Previous to this commit: When a user activates the Indonesian localization, the settings fields for the
Original PR description
The aim of this commit is to fix an issue where the settings fields for the Indonesian localization were visible in all companies of a database. Context: In a multi-company environment, a company may have its fiscal country set to Indonesia and have the Indonesian localization activated, but this should only affect the options shown in the accounting settings for that specific company. Previous to this commit: When a user activates the Indonesian localization, the settings fields for the localization would be visible in the accounting settings for all companies of the database. After this commit: The settings fields for the Indonesian localization will now only be visible in the accounting settings for the specific companies located in Indonesia. task-id: 2854025 Forward-Port-Of: odoo/odoo#111227 Forward-Port-Of: odoo/odoo#111188
The default computation should be "Constant Periods" and not "No prorata" for most use cases. This commit updates the default value for `prorata_computation_type` task-3133652 Forward-Port-Of: odoo/enterprise#36314
Original PR description
The default computation should be "Constant Periods" and not "No prorata" for most use cases. This commit updates the default value for `prorata_computation_type` task-3133652 Forward-Port-Of: odoo/enterprise#36314
Before this commit, the `To invoice` is applied by default in `All tasks > To invoice` menu only when the user is in debug mode. This behavior should be there even if the user is not in debug mode. This commit fixes the filter in the search view to be able to apply the filter by default when the user is in debug mode or not. X-original-commit: ca4bbd7f52eab0348d754691b5143935cb83e31f Forward-Port-Of: odoo/enterprise#36013
Original PR description
Before this commit, the `To invoice` is applied by default in `All tasks > To invoice` menu only when the user is in debug mode. This behavior should be there even if the user is not in debug mode. This commit fixes the filter in the search view to be able to apply the filter by default when the user is in debug mode or not. X-original-commit: ca4bbd7f52eab0348d754691b5143935cb83e31f Forward-Port-Of: odoo/enterprise#36013
An appointment.type of category 'anytime' can only exist once for a given res.users. The code trying to detect and raise an error upon finding a duplicate record was not working and raised on invalid cases. Existing tests only worked because of side-effects. The code was fixed and extra use cases are now tested to ensure the behavior. Task-3159839 Forward-Port-Of: odoo/enterprise#36411
Original PR description
An appointment.type of category 'anytime' can only exist once for a given res.users. The code trying to detect and raise an error upon finding a duplicate record was not working and raised on invalid cases. Existing tests only worked because of side-effects. The code was fixed and extra use cases are now tested to ensure the behavior. Task-3159839 Forward-Port-Of: odoo/enterprise#36411
The tour changes the liquidity line amount, and then immediately the label. Both these fields have onchanges which should be triggered. Sometimes the second onchange does not execute, causing non-deterministic failures on runbot. To solve, the test is split into 2 steps. The balance update is verified before the label is changed, thus allowing some time for both onchanges. Forward-Port-Of: odoo/enterprise#36381
Original PR description
The tour changes the liquidity line amount, and then immediately the label. Both these fields have onchanges which should be triggered. Sometimes the second onchange does not execute, causing non-deterministic failures on runbot. To solve, the test is split into 2 steps. The balance update is verified before the label is changed, thus allowing some time for both onchanges. Forward-Port-Of: odoo/enterprise#36381
This PR disables INSERT IN SPREADSHEET button when users want to insert pivot table with duplicated groupbys in either rows or cols, or cols/rows have the same groupbys into spreadsheet. The tooltip shows the reason. Currently when the pivot table with duplicate groupbys only in cols/rows, or rows and cols have same groupbys, in spreadsheet the values are gone. Since these cases are meaningless in most of time, it is more economical to just ban this kind of insertion than fixing the bug, whi
Original PR description
This PR disables INSERT IN SPREADSHEET button when users want to insert pivot table with duplicated groupbys in either rows or cols, or cols/rows have the same groupbys into spreadsheet. The tooltip shows the reason. Currently when the pivot table with duplicate groupbys only in cols/rows, or rows and cols have same groupbys, in spreadsheet the values are gone. Since these cases are meaningless in most of time, it is more economical to just ban this kind of insertion than fixing the bug, which probably needs a big change in the way we get the pivot values. task [3068786](https://www.odoo.com/web#id=3068786&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#36398 Forward-Port-Of: odoo/enterprise#36279
On both these reports, when a large amount of data was to be displayed, unfold_all filter timed out. Indeed, all the partner lines were unfolded one by one, each generating a new SQL query. We optimize this by introducing the possibility for custom engines to use a custom_unfold_all_batch_data_generator (already used for this kind of situation on reports with dynamic lines), and using it on both reports. Note that when the report contains too many lines to display, the browser still might not
Original PR description
On both these reports, when a large amount of data was to be displayed, unfold_all filter timed out. Indeed, all the partner lines were unfolded one by one, each generating a new SQL query. We…
On both these reports, when a large amount of data was to be displayed, unfold_all filter timed out. Indeed, all the partner lines were unfolded one by one, each generating a new SQL query. We optimize this by introducing the possibility for custom engines to use a custom_unfold_all_batch_data_generator (already used for this kind of situation on reports with dynamic lines), and using it on both reports. Note that when the report contains too many lines to display, the browser still might not support displaying it (Chrome seems to perform quite poorly on that side). For this reason, since such huge reports will not be accessible fully unfolded from the UI as-is, we partially revert https://github.com/odoo/enterprise/commit/5787cd561028a8f5f0882c99316c429dfadfab10 in order to reintroduce the fact printing and Aged Payable or Aged Receivable report will by default unfold all the lines of the report. This way, printing the report to xlsx will directly provide all data required for an audit of the report, and the user won't have to enable the unfold_all filter manually in the UI. Forward-Port-Of: odoo/enterprise#36278
When importing a CODA file containing accented characters, they can show up as other characters. This has to do with the file encoding of the CODA file. e.g. the letter `é` in `UTF-8` is represented as `00C3 00A9` (using 2 bytes). When we first try parsing in `CP1252`, which uses 1 byte per letter, it will look like `Ã` (`00C3`) and `©` (`00A9`). These are both printable characters and so we don't complain when decoding the file. In this commit we change the order of encoding trials to
Original PR description
When importing a CODA file containing accented characters, they can show up as other characters. This has to do with the file encoding of the CODA file. e.g. the letter `é` in `UTF-8` is represented as `00C3 00A9` (using 2 bytes). When we first try parsing in `CP1252`, which uses 1 byte per letter, it will look like `Ã` (`00C3`) and `©` (`00A9`). These are both printable characters and so we don't complain when decoding the file. In this commit we change the order of encoding trials to first try UTF-8, which is a sensible default. Also, the `_check_coda` function did not work for `CP1140`, `UTF-16` and `UTF-32` encoded files. The regex was defined as a string and converted to bytes using the default ASCII encoding. This didn't match the bytes of the previous three encodings. In this commit we first try to decode the file and then do a string regex check on the decoded string. task-3147804 Forward-Port-Of: odoo/enterprise#36260
Pdf printing for partner ledger report is not good in arabic localization: some part of the table is cut. Fix it by saving some space from title column opw-2954295 Forward-Port-Of: odoo/enterprise#36206 Forward-Port-Of: odoo/enterprise#35025
Original PR description
Pdf printing for partner ledger report is not good in arabic localization: some part of the table is cut. Fix it by saving some space from title column opw-2954295 Forward-Port-Of: odoo/enterprise#36206 Forward-Port-Of: odoo/enterprise#35025
Fix the timezone for https://github.com/odoo/odoo/pull/106781 opw-3010846 Forward-Port-Of: odoo/enterprise#36275 Forward-Port-Of: odoo/enterprise#35891
Original PR description
Fix the timezone for https://github.com/odoo/odoo/pull/106781 opw-3010846 Forward-Port-Of: odoo/enterprise#36275 Forward-Port-Of: odoo/enterprise#35891
When a product is scanned alongside a quantity (eg. scanning a product packaging or a GS1 barcode with a product and a quantity) and an existing quant is found, the scanned quantity is lost and the inventory line is created with the default quantity (1). Steps to reproduce the issue: - Enable Product Packagings in settings - Create a product - Create a packaging for this product with a quantity (eg. 5) and a - barcode (eg. barcode007) - Go to Barcode -
Original PR description
When a product is scanned alongside a quantity (eg. scanning a product packaging or a GS1 barcode with a product and a quantity) and an existing quant is found, the scanned quantity is lost and the…
When a product is scanned alongside a quantity (eg. scanning a product
packaging or a GS1 barcode with a product and a quantity) and an
existing quant is found, the scanned quantity is lost and the inventory
line is created with the default quantity (1).
Steps to reproduce the issue:
- Enable Product Packagings in settings
- Create a product - Create a packaging for this product with a quantity (eg. 5) and a - barcode (eg. barcode007) - Go to Barcode -> Inventory Adjustments - Scan the packaging, and they will be counted well (5, 10, 15, ...) - Apply the changes - Re-enter inventory adjustment - Scan the same package, here is the issue, it's counted 1, 6, 11, ...
Solution:
When creating a new inventory line for the existing quant, take the
scanned quantity if we can.
opw-2954725
closes odoo/enterprise#31667
X-original-commit: d71979c0636a100039535c603034909c7f309cf3
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Forward-Port-Of: odoo/enterprise#36017Since the behavior is changed in community, the tests also need to be changed to reflect the fact that qty_producing is not set to zero anymore when starting a workorder. see https://github.com/odoo/odoo/pull/109725 Forward-Port-Of: odoo/enterprise#36012
Original PR description
Since the behavior is changed in community, the tests also need to be changed to reflect the fact that qty_producing is not set to zero anymore when starting a workorder. see https://github.com/odoo/odoo/pull/109725 Forward-Port-Of: odoo/enterprise#36012
Prior to this commit, the view would stay in sample mode after making a file request making it impossible to interact with the record itself until the view is reloaded. TaskId-3151649 Forward-Port-Of: odoo/enterprise#36332
Original PR description
Prior to this commit, the view would stay in sample mode after making a file request making it impossible to interact with the record itself until the view is reloaded. TaskId-3151649 Forward-Port-Of: odoo/enterprise#36332
Prior to this commit the kanban record would not re-render upon generating the pdf thumbnails because the inner records used for the rendering were not updated with the new values. TaskId-3151278 Forward-Port-Of: odoo/enterprise#36326
Original PR description
Prior to this commit the kanban record would not re-render upon generating the pdf thumbnails because the inner records used for the rendering were not updated with the new values. TaskId-3151278 Forward-Port-Of: odoo/enterprise#36326
The `account.generic.tax.report` was removed in reportalypse, and this instance was left over in the process. This fixes the issue by referencing the correct tax report. opw-3110477 Forward-Port-Of: odoo/enterprise#36345
Original PR description
The `account.generic.tax.report` was removed in reportalypse, and this instance was left over in the process. This fixes the issue by referencing the correct tax report. opw-3110477 Forward-Port-Of: odoo/enterprise#36345