Daily updates from Odoo
Thursday, December 5, 2024
77 changes
4 changes
Miscellaneous changes
Currently, when using a language that translates the abbreviation of quarters (Q) to anything else, the formula `=filter.value(...)` would return the translated version, which then could not be used on other formulas like `=odoo.balance`, this can be observed by opening the Finance/accounting dashboard while in french and selecting a filter in quarter. After this fix, the formula filter.value will always return Q1 to Q4 for quarter names. Task: 4274741 --- I confirm I have signed
Original PR description
Currently, when using a language that translates the abbreviation of quarters (Q) to anything else, the formula `=filter.value(...)` would return the translated version, which then could not be used on other formulas like `=odoo.balance`, this can be observed by opening the Finance/accounting dashboard while in french and selecting a filter in quarter. After this fix, the formula filter.value will always return Q1 to Q4 for quarter names. Task: 4274741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187140 Forward-Port-Of: odoo/odoo#187043
Versions -------- - 16.0+ Steps ----- 1. Schedule the "Calendar: Event Reminder" to run once a day; 2. create an event that started 2 hours ago, and ended 1 hour ago; 3. run the event reminder cron. Issue ----- A reminder email is sent, event though the event has passed. Cause ----- The alarm manager doesn't check whether the reminders it sends are still relevant. Solution -------- When looking querying events to send reminders for, ensure their `stop` date is before the
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Schedule the "Calendar: Event Reminder" to run once a day; 2. create an event that started 2 hours ago, and ended 1 hour ago; 3. run the event reminder cron. Issue ----- A reminder email is sent, event though the event has passed. Cause ----- The alarm manager doesn't check whether the reminders it sends are still relevant. Solution -------- When looking querying events to send reminders for, ensure their `stop` date is before the current time. opw-4191612 Forward-Port-Of: odoo/odoo#189479 Forward-Port-Of: odoo/odoo#189340
Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "
Original PR description
Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "Navbar" option. - Click the "Mobile Preview" button. - Click the "Hamburger menu" button to open the mobile navbar. - Bug: The text color is not "red". [1]: https://github.com/odoo/odoo/commit/1e30600d9e0e12e43fcbca60760a64f2551e3c8f opw-4364765 Forward-Port-Of: odoo/odoo#189417
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189644 Forward-Port-Of: odoo/odoo#189467
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189644 Forward-Port-Of: odoo/odoo#189467
12 changes
Miscellaneous changes
Currently, when using a language that translates the abbreviation of quarters (Q) to anything else, the formula `=filter.value(...)` would return the translated version, which then could not be used on other formulas like `=odoo.balance`, this can be observed by opening the Finance/accounting dashboard while in french and selecting a filter in quarter. After this fix, the formula filter.value will always return Q1 to Q4 for quarter names. Task: 4274741 --- I confirm I have signed
Original PR description
Currently, when using a language that translates the abbreviation of quarters (Q) to anything else, the formula `=filter.value(...)` would return the translated version, which then could not be used on other formulas like `=odoo.balance`, this can be observed by opening the Finance/accounting dashboard while in french and selecting a filter in quarter. After this fix, the formula filter.value will always return Q1 to Q4 for quarter names. Task: 4274741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187043
In commit [1], we introduced a "data-forced-size" attribute on "image shapes" SVGs to adjust SVGs height to ensure the image fits properly within it (e.g. for "devices" shapes). However, the "image_shape" route was not updated to match this change, preventing the use of predefined building blocks containing an image shape with a "forced-size" attribute. This commit updates the "image_shape" route to support the "data-forced-size" attribute. [1]: https://github.com/odoo/odoo/commit/
Original PR description
In commit [1], we introduced a "data-forced-size" attribute on "image shapes" SVGs to adjust SVGs height to ensure the image fits properly within it (e.g. for "devices" shapes). However, the "image_shape" route was not updated to match this change, preventing the use of predefined building blocks containing an image shape with a "forced-size" attribute. This commit updates the "image_shape" route to support the "data-forced-size" attribute. [1]: https://github.com/odoo/odoo/commit/63cf8a693a5262600d465d70f0383229464d71e7 task-4094393 Forward-Port-Of: odoo/odoo#189156
Before this commit: - The `::before` pseudo-element had `width: -webkit-fill-available` and `width: -moz-available`, causing it to span the entire width of its container. - Its `z-index: 100` made it overlap with other elements, preventing interaction with underlying elements. After this commit: - `pointer-events: none` was applied to the pseudo-element. - This allows interactions with underlying elements while retaining the visual styling. task-4313526 --- I confirm I have sig
Original PR description
Before this commit: - The `::before` pseudo-element had `width: -webkit-fill-available` and `width: -moz-available`, causing it to span the entire width of its container. - Its `z-index: 100` made it overlap with other elements, preventing interaction with underlying elements. After this commit: - `pointer-events: none` was applied to the pseudo-element. - This allows interactions with underlying elements while retaining the visual styling. task-4313526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187915
Added base localization package for Lebanon 🇱🇧 , it includes the following: - Chart of Accounts - Taxes - Fiscal Positions Task: - 3927914 --- Forward-Port-Of: odoo/odoo#184602
Original PR description
Added base localization package for Lebanon 🇱🇧 , it includes the following: - Chart of Accounts - Taxes - Fiscal Positions Task: - 3927914 --- Forward-Port-Of: odoo/odoo#184602
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189467
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189467
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of concurrent.futures: exception calling callback for <Future at 0x7f212c073110 state=finished raised ChromeBrowserException> Traceback (most recent call last): File "concurrent/futures/_base.py", line 340, in _invoke_callbacks callback(self) File "odoo/odoo/tests/common.py", line 1532, in handler
Original PR description
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of concurrent.futures: exception calling…
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of
concurrent.futures: exception calling callback for <Future at 0x7f212c073110 state=finished raised ChromeBrowserException>
Traceback (most recent call last):
File "concurrent/futures/_base.py", line 340, in _invoke_callbacks
callback(self)
File "odoo/odoo/tests/common.py", line 1532, in handler
base_png = f.result(timeout=0)['data']
^^^^^^^^^^^^^^^^^^^
File "concurrent/futures/_base.py", line 449, in result
return self.__get_result()
^^^^^^^^^^^^^^^^^^^
File "concurrent/futures/_base.py", line 401, in __get_result
raise self._exception
odoo.tests.common.ChromeBrowserException: Internal error
As this is mostly unhelpful, handle the thing better, and lower the concern to `RUNBOT`: giving prominence to the screenshot failure is probably less relevant than the actual reason why we tried to take a screenshot in the first place?
Forward-Port-Of: odoo/odoo#189585With this commit, the useless scroll bar in refuse reason wizard is removed. task-4270277 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#184539
Original PR description
With this commit, the useless scroll bar in refuse reason wizard is removed. task-4270277 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#184539
**Description of the issue/feature this PR addresses:** To quote [the Odoo documentation](https://www.odoo.com/documentation/16.0/applications/websites/website/configuration/recaptcha.html?highlight=recaptcha): > All pages using the Form, Newsletter Block, Newsletter Popup snippets, and the eCommerce Extra Step During Checkout form are now protected by reCAPTCHA. However, it's still possible for a bot to register itself to free events, as it doesn't have to go through the checkout p
Original PR description
**Description of the issue/feature this PR addresses:**
To quote [the Odoo documentation](https://www.odoo.com/documentation/16.0/applications/websites/website/configuration/recaptcha.html?highlight=recaptcha):
> All pages using the Form, Newsletter Block, Newsletter Popup snippets, and the eCommerce Extra Step During Checkout form are now protected by reCAPTCHA.
However, it's still possible for a bot to register itself to free events, as it doesn't have to go through the checkout process.. and cause quite a mess.
This commits adds a recaptcha to the new registrations form.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#188597
Forward-Port-Of: odoo/odoo#186991Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "
Original PR description
Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "Navbar" option. - Click the "Mobile Preview" button. - Click the "Hamburger menu" button to open the mobile navbar. - Bug: The text color is not "red". [1]: https://github.com/odoo/odoo/commit/1e30600d9e0e12e43fcbca60760a64f2551e3c8f opw-4364765 Forward-Port-Of: odoo/odoo#189417
Versions -------- - 16.0+ Steps ----- 1. Schedule the "Calendar: Event Reminder" to run once a day; 2. create an event that started 2 hours ago, and ended 1 hour ago; 3. run the event reminder cron. Issue ----- A reminder email is sent, event though the event has passed. Cause ----- The alarm manager doesn't check whether the reminders it sends are still relevant. Solution -------- When looking querying events to send reminders for, ensure their `stop` date is before the
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Schedule the "Calendar: Event Reminder" to run once a day; 2. create an event that started 2 hours ago, and ended 1 hour ago; 3. run the event reminder cron. Issue ----- A reminder email is sent, event though the event has passed. Cause ----- The alarm manager doesn't check whether the reminders it sends are still relevant. Solution -------- When looking querying events to send reminders for, ensure their `stop` date is before the current time. opw-4191612 Forward-Port-Of: odoo/odoo#189479 Forward-Port-Of: odoo/odoo#189340
runbot task: 107888 and 109252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189473
Original PR description
runbot task: 107888 and 109252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189473
Steps to reproduce ================== - In 18, install documents,project - Open a project then a task - Switch to a mobile view and refresh the page - The lightning icon is smaller than the cog icon Cause of the issue ================== https://github.com/odoo/odoo/pull/188986 An overflow was applied on the entire oe_stat_button Solution ======== We can move the overflow to the `o_field_statinfo` This is better than before as now the ellipsis is visible. task-4377703
Original PR description
Steps to reproduce ================== - In 18, install documents,project - Open a project then a task - Switch to a mobile view and refresh the page - The lightning icon is smaller than the cog icon Cause of the issue ================== https://github.com/odoo/odoo/pull/188986 An overflow was applied on the entire oe_stat_button Solution ======== We can move the overflow to the `o_field_statinfo` This is better than before as now the ellipsis is visible. task-4377703 Forward-Port-Of: odoo/odoo#189780
23 changes
Enhancements to existing features
Users can now press Ctrl+S while editing a Knowledge article to save their changes directly. This prevents the browser's default page-save prompt and matches the familiar save shortcut used in common text editors.
Original PR description
When the user presses `Ctrl` + `s`, the browser prompts the user to select a directory to save the current page in. Today, most text editors use the `Ctrl` + `s` shortcut to save the current file. This PR will add a new event listener for `Ctrl` + `s` that will prevent the default browser behavior and save the user changes in db. task-4191390
Attendance officers now see only the actions and fields they are allowed to use. This prevents users from trying to edit or save attendance information that would later be blocked by permissions, making the workflow clearer and reducing errors.
Original PR description
Before this commit, when a user has the right office and not manager in attendance; he was able to see some buttons, modify some values but when he tried to access/save it i had a rightissue. To avoid that, these buttons wille be hidden and these fields will be readonly when the user doesn't have enough right. task-4044869
The terminology for International Commercial Terms has been standardized from “Incoterm” to “Incoterms” across affected Odoo business flows. This reduces confusion in labels, reports, data fields, and integrations while aligning the product with the correct international abbreviation.
Original PR description
According to international standars, the abbreviation of 'International Commercial Terms' is INCOTERMS. However, the use of INCOTERM is prevalent in our codebase. This commits fixes it, rewording all references to the correct one. This commit also updates the name of the fields in the models to avoid future confusion about the correct abbreviation. task: 3983531 COM-PR: https://github.com/odoo/odoo/pull/189030 UPG-PR: https://github.com/odoo/upgrade/pull/6847
Resolved issues and error corrections
The Social Demo module now reuses existing standard records instead of creating duplicate copies. This reduces test database inconsistencies and helps avoid unexpected issues when the demo module is installed accidentally or for testing.
Original PR description
Although `social_demo` is a strong independent module it's a bit odd that it partially duplicates a bunch of data from `base` and `product`, and if it gets installed (possibly by mistake) into a database for testing, some tests don't cope well with the issue. Remove the duplicated records and just reference the base ones. Leave `product_product_4d` as it's either novel to `social_demo` or was removed from `product` since it was initially duplicated.
The barcode scanning flow now shows a correctly spelled and grammatically improved error message when a scanned barcode is not found. This makes the receipt process clearer for users and reduces confusion during warehouse operations.
Original PR description
Barcode --> Operations --> Receipts --> NEW Scan a barcode that doesn't exist in the DB ie: "5449000000996" The current error message's spelling and grammar are off. opw-4307102
Code cleanup and technical improvements
This update reorganizes and renames files across several Odoo project, timesheet, planning, helpdesk, field service, and subscription-related apps. It is an internal cleanup intended to make the codebase easier to maintain, with no expected direct change to day-to-day user workflows.
Original PR description
* helpdesk_timesheet * industry_fsm_report * industry_fsm_sale_report * planning * project_account_asset * project_account_budget * project_forecast * project_helpdesk * project_holidays * project_hr_payroll_account * project_sale_subscription * project_timesheet_forecast * project_timesheet_forecast_sale * project_timesheet_forecast * sale_timesheet_enterprise * timesheet_grid task-4366769
This update reorganizes and renames internal Point of Sale code across several related modules to make it easier to maintain. It should not change day-to-day cashier or restaurant workflows, but it reduces future development risk and improves consistency across country-specific and device integrations.
Original PR description
### Commit 1: [REF] pos_urban_paper, pos_l10n_se: clean setup method of pos_store Correctly separe user UI state, service and technical state in the pos_store setup method. Also rename state variable in snake_case to camel_case. --- ### Commit 2: [REF] point_of_sale, pos_*: pos_store cleaning *: l10n_cl_edi_pos,l10n_de_pos_cert,l10n_ec_edi_pos,l10n_mx_edi_pos, pos_blackbox_be,pos_iot,pos_iot_six,pos_l10n_se,pos_restaurant_preparation_display, pos_self_order_iot,pos_settle_due,pos_urban_piper Rename methods in pos_store to respect camelCase rules
Miscellaneous changes
after this commit [1] the **Pagos** namespace was always removed from the schemaLocation attribute, this was causing error for Quarum pac. this commit fix the issue by filtering the schemaLocation attribute based what is present in namespace map. [1] https://github.com/odoo/enterprise/commit/dd18e0829810df7594730e14e09ac2174eedcc32 opw-4168509 Forward-Port-Of: odoo/enterprise#74937 Forward-Port-Of: odoo/enterprise#74809
Original PR description
after this commit [1] the **Pagos** namespace was always removed from the schemaLocation attribute, this was causing error for Quarum pac. this commit fix the issue by filtering the schemaLocation attribute based what is present in namespace map. [1] https://github.com/odoo/enterprise/commit/dd18e0829810df7594730e14e09ac2174eedcc32 opw-4168509 Forward-Port-Of: odoo/enterprise#74937 Forward-Port-Of: odoo/enterprise#74809
In this commit we add several models to the PRESET_MODELS_DEFAULTS list such that the exporter includes necessary models by default. Task-4205813 Forward-Port-Of: odoo/enterprise#70495
Original PR description
In this commit we add several models to the PRESET_MODELS_DEFAULTS list such that the exporter includes necessary models by default. Task-4205813 Forward-Port-Of: odoo/enterprise#70495
`position_plugin` does not share methods, but it offers features through resources that are pretty much essential for other plugins. In these cases, it makes sense to add them as a dependency. Prior to this PR, it was not possible to comment inside a list item (comment beacons were not allowed inside) in the new editor. It is not intended, and this commits allows it again. task-4331264 Forward-Port-Of: odoo/enterprise#73855
Original PR description
`position_plugin` does not share methods, but it offers features through resources that are pretty much essential for other plugins. In these cases, it makes sense to add them as a dependency. Prior to this PR, it was not possible to comment inside a list item (comment beacons were not allowed inside) in the new editor. It is not intended, and this commits allows it again. task-4331264 Forward-Port-Of: odoo/enterprise#73855
Steps to reproduce: - Insert a pivot from CRM - Create a global filter, with type date or text => The id field can be selected With this commit, field `id` is now available only on relational global filters. Task: 4348477 Forward-Port-Of: odoo/enterprise#75076 Forward-Port-Of: odoo/enterprise#74191
Original PR description
Steps to reproduce: - Insert a pivot from CRM - Create a global filter, with type date or text => The id field can be selected With this commit, field `id` is now available only on relational global filters. Task: 4348477 Forward-Port-Of: odoo/enterprise#75076 Forward-Port-Of: odoo/enterprise#74191
- Add .pot base translation file. - Replace potentially unsafe `const_eval()` with a `json.loads()`. - Use the built-in methods for setting filename for received files. Forward-Port-Of: odoo/enterprise#74691 Forward-Port-Of: odoo/enterprise#74347
Original PR description
- Add .pot base translation file. - Replace potentially unsafe `const_eval()` with a `json.loads()`. - Use the built-in methods for setting filename for received files. Forward-Port-Of: odoo/enterprise#74691 Forward-Port-Of: odoo/enterprise#74347
This is only a cosmetic change from a text button to an icon button. The main changes of the PR are done in https://github.com/odoo/odoo/pull/184308/. ----------------------- Community pr description: - changed the "start", "pause" and "done" button text to icons to be able to set the button column size at a fixed value - moved the unblock button in the dropdown - made the previous block button toggle between block and unblock - change the dropdown bullet to red when blocked This
Original PR description
This is only a cosmetic change from a text button to an icon button. The main changes of the PR are done in https://github.com/odoo/odoo/pull/184308/. ----------------------- Community pr description: - changed the "start", "pause" and "done" button text to icons to be able to set the button column size at a fixed value - moved the unblock button in the dropdown - made the previous block button toggle between block and unblock - change the dropdown bullet to red when blocked This commit also modifies the width of the json_popover as it was using the base column width which was too big for the icon. It also modifies the width of the mo_list_dropdown column to limit the empty space. This implies changes in the web module: in `column_width_hook.js`, the width of a widget is equal to it's `listViewWidth`, like the fields. However, unlike the fields, the widget class is missing a validation for that props. task-id: 4279789 Forward-Port-Of: odoo/enterprise#74396
This will add new rule parameter values for 2024 for the CP200 salary scales. Task: 4274766 Forward-Port-Of: odoo/enterprise#73080
Original PR description
This will add new rule parameter values for 2024 for the CP200 salary scales. Task: 4274766 Forward-Port-Of: odoo/enterprise#73080
Before this PR: In the Kanban view, when selecting request documents and opening the chatter, the activity button does not appear. Similarly, in the list view, when selecting any documents and opening the chatter, the activity button is not displayed. Technical: For request documents, we get an empty res_model, so a condition was added to handle this. In the documents_list_renderer, the 'res_model' cannot be retrieved, since active fields are calculated from the 'arch info'. Therefore, we
Original PR description
Before this PR: In the Kanban view, when selecting request documents and opening the chatter, the activity button does not appear. Similarly, in the list view, when selecting any documents and opening the chatter, the activity button is not displayed. Technical: For request documents, we get an empty res_model, so a condition was added to handle this. In the documents_list_renderer, the 'res_model' cannot be retrieved, since active fields are calculated from the 'arch info'. Therefore, we added the field in the list view. After this PR: The activity button will now be visible for all documents in both the Kanban and list views. Task-4341409 Forward-Port-Of: odoo/enterprise#74588
The position of the `iso20022_uetr` field was defined as being after the `partner_bank_id` field in the view. However multiple of these fields were defined in the view using if/else conditions, and the former field was put after the first occurrence of the latter. So depending on which `partner_bank_id` field was shown, the `iso20022_uetr` field would be either before or after it. This commit makes it consistent and puts it after the last occurrence of `partner_bank_id`. Forward-Port-Of: odo
Original PR description
The position of the `iso20022_uetr` field was defined as being after the `partner_bank_id` field in the view. However multiple of these fields were defined in the view using if/else conditions, and the former field was put after the first occurrence of the latter. So depending on which `partner_bank_id` field was shown, the `iso20022_uetr` field would be either before or after it. This commit makes it consistent and puts it after the last occurrence of `partner_bank_id`. Forward-Port-Of: odoo/enterprise#75064
Steps to reproduce: 1) Install l10n_in_hr_payroll module 2) open payslip of an Indian employee 3) click on the Create Report button and select the Payment Advice option 4) creating Pdf report prints an empty report Cause: Payment advice only refers to the batch's payslip Fix: Now the Payment advice can apply directly to the payslips Task-4220378 Forward-Port-Of: odoo/enterprise#71515
Original PR description
Steps to reproduce: 1) Install l10n_in_hr_payroll module 2) open payslip of an Indian employee 3) click on the Create Report button and select the Payment Advice option 4) creating Pdf report prints an empty report Cause: Payment advice only refers to the batch's payslip Fix: Now the Payment advice can apply directly to the payslips Task-4220378 Forward-Port-Of: odoo/enterprise#71515
Current Behaviour: - when grouping or filtering records in the planning kanban view, the daterange looks like displayed on two columns Expected Behaviour: - the daterange should be displayed as a single line Task-4273653 Forward-Port-Of: odoo/enterprise#72466
Original PR description
Current Behaviour: - when grouping or filtering records in the planning kanban view, the daterange looks like displayed on two columns Expected Behaviour: - the daterange should be displayed as a single line Task-4273653 Forward-Port-Of: odoo/enterprise#72466
Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version. This also correct two errors that were used in the generic SAF-T module: - The accounts codes should be used for AccountID instead of the account database ids - The ValueDate should be the accounting date and not the invoice date. Based on the info from: - Previous version SAF-T description: https://www.skatteetaten
Original PR description
Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version. This also correct two…
Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version. This also correct two errors that were used in the generic SAF-T module: - The accounts codes should be used for AccountID instead of the account database ids - The ValueDate should be the accounting date and not the invoice date. Based on the info from: - Previous version SAF-T description: https://www.skatteetaten.no/globalassets/bedrift-og-organisasjon/starte-og-drive/rutiner-regnskap-og-kassasystem/saf-t-regnskap/oppdateringer-desember-2020/norwegian-saf-t-financial-data---technical-description.pdf - New version: https://www.skatteetaten.no/globalassets/bedrift-og-organisasjon/starte-og-drive/rutiner-regnskap-og-kassasystem/saf-t-regnskap/oppdateringer-mars-2024/norwegian-saf-t-financial-data---technical-description.pdf task-3975794 Forward-Port-Of: odoo/enterprise#73249 Forward-Port-Of: odoo/enterprise#65221
At the moment, the SOAP call in `_l10n_ec_get_client_service_response` catches `ConnectionError`, but some exceptions raised by zeep (such as `Timeout`) are not caught and will cause a traceback for the user. We catch `RequestException` to make sure that these are caught. task-none Forward-Port-Of: odoo/enterprise#74266
Original PR description
At the moment, the SOAP call in `_l10n_ec_get_client_service_response` catches `ConnectionError`, but some exceptions raised by zeep (such as `Timeout`) are not caught and will cause a traceback for the user. We catch `RequestException` to make sure that these are caught. task-none Forward-Port-Of: odoo/enterprise#74266
At the moment, when `l10n_ke_edi_oscu_stock` is installed, the purchase order view is broken for users that don't belong to the `account.group_account_invoice` group, because they don't have access to the `l10n_ke_edi.customs.import` model. This commit restricts the `l10n_ke_customs_import_ids` field on the `purchase.order` view to the `account.group_account_invoice` so that this error no longer occurs. runbot-70725 Forward-Port-Of: odoo/enterprise#74893
Original PR description
At the moment, when `l10n_ke_edi_oscu_stock` is installed, the purchase order view is broken for users that don't belong to the `account.group_account_invoice` group, because they don't have access to the `l10n_ke_edi.customs.import` model. This commit restricts the `l10n_ke_customs_import_ids` field on the `purchase.order` view to the `account.group_account_invoice` so that this error no longer occurs. runbot-70725 Forward-Port-Of: odoo/enterprise#74893
Currently, when cancelling an order, the notification is not sent to the preparation display. Steps to reproduce: ------------------- * Open both restaurant and preparation display * In the restaurant place an order and send it to the kitchen * Select Action > Cancel order > Observation: The cancellation is not sent to the preparation display Note: If you send a new order or refresh the preparation display then you can see that the order has been cancelled. Why the fix: ----------
Original PR description
Currently, when cancelling an order, the notification is not sent to the preparation display. Steps to reproduce: ------------------- * Open both restaurant and preparation display * In the…
Currently, when cancelling an order, the notification is not sent to the preparation display.
Steps to reproduce:
-------------------
* Open both restaurant and preparation display
* In the restaurant place an order and send it to the kitchen
* Select Action > Cancel order
> Observation: The cancellation is not sent to the preparation display
Note: If you send a new order or refresh the preparation display then you can see that the order has been cancelled.
Why the fix:
------------
When cancelling order, data looks like this
`{'change': True, 'sound': False, 'category_ids': {}}`. Since `category_ids` is empty, `preparation_displays` will alsos be empty which explains why the preparation display does not receive the notification, it is simply not sent.
https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/pos_preparation_display/models/preparation_display_order.py#L29-L40
Since all lines are canceled, we include all the different categories they cover. Now `preparation_displays` is not empty and all the displays it covers will receive a notification.
opw-4322600
Forward-Port-Of: odoo/enterprise#74683### Steps to reproduce: - Create a new Loan at a date several months in the past - Add a "Skip until" date after the date of the loan but before the current date - Compute the draft lines - Confirm - The lines skipped are those after the "Skip until" date and not the ones before ### Cause: It seems there was a typo in how the "Skip until" option is handled. When we add a skip until date, we are actually doing the reverse behavior. We are skipping everything after the skip until and no
Original PR description
### Steps to reproduce: - Create a new Loan at a date several months in the past - Add a "Skip until" date after the date of the loan but before the current date - Compute the draft lines - Confirm - The lines skipped are those after the "Skip until" date and not the ones before ### Cause: It seems there was a typo in how the "Skip until" option is handled. When we add a skip until date, we are actually doing the reverse behavior. We are skipping everything after the skip until and not what's before. ### Solution: Correct the typo. opw-4342085 Forward-Port-Of: odoo/enterprise#74721
33 changes
Enhancements to existing features
The web tour recorder now saves the current recording progress in the browser so users can continue after refreshing the page. This reduces lost work when creating or editing guided tours and makes the recording experience more reliable.
Original PR description
Wrapper around localStorage for persistence of the current recording. Useful for resuming recording when the page refreshed. TASK-ID: 4378081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale sessions now include an indicator when they are connected to an Italian company. This helps related localization features apply the right Italian compliance behavior without requiring users to manually identify the company context.
Original PR description
added a session key to indicate if the current session is connected to an Italian company. Related: https://github.com/odoo/enterprise/pull/75147
The Point of Sale now records when a session belongs to an Italian company. This helps Italian localization rules apply only where relevant, reducing unnecessary checks and supporting more reliable compliance behavior.
Original PR description
added a session key to indicate if the current session is connected to an Italian company. Related: https://github.com/odoo/odoo/pull/189610
Resolved issues and error corrections
The chat window’s conversation name and avatar are now easier to click because a small unresponsive area beside them was removed. This keeps the same visual spacing while making the more-actions interaction feel more reliable for users.
Original PR description
When mouse-hovering more actions (the conversation name & avatar), the clickable zone had a small dead zone on the left. This comes from `mx-1`, which put good spacing but had the unintentional deadzone spacing. This commit replaces the `mx-1` by equivalent extra padding, thus removing the deadzone while keeping the overall same spacing. Before / After <img width="391" alt="Screenshot 2024-12-04 at 16 50 52" src="https://github.com/user-attachments/assets/323d8ece-2965-49c3-acc6-d2e4590c1fb2"> <img width="390" alt="Screenshot 2024-12-04 at 16 50 38" src="https://github.com/user-attachments/assets/97ba506d-8fa4-4825-957a-5f22be9910fe"> Difference (red) <img width="1911" alt="Screenshot 2024-12-05 at 12 44 00" src="https://github.com/user-attachments/assets/aa7c9079-f2b4-467d-8e1f-58f2ce9b8da1">
Opening a shared project task no longer automatically focuses the chatter area. This prevents unwanted scrolling, especially on mobile, so portal users land on the task details as expected.
Original PR description
… sharing The objective is to remove the focus on the chatter whenever a task is opened in project sharing. This aimed initially to avoid the automatic scroll to the bottom in mobile view. As a note: the Chatter component in project_sharing refers to the mail/chatter, however as project module also includes the portal/static/src/chatter/core/chatter_patch.js, Chatter template in project is overrided leading to autofocus triggering. To replicate: 1. Share a project with tasks to a user with Edit permission. 2. login with portal user and open the project portal view 3. Open a task. The focus should no longer be set on the Chatter automatically. 3-b. Also on Mobile, when opening a task the sreen should not scroll to the chatter. task: 4353290 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Messages that are not grouped together now show both the day and time, such as "Today at 10:00" or "Yesterday at 08:00". This makes busy conversations easier to follow when many messages were posted on the same day.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/188665 PR above changed "X days ago" on messages by time, so that the exact time can be viewed without requiring mouse-hovering. Indeed, after some…
Follow-up of https://github.com/odoo/odoo/pull/188665 PR above changed "X days ago" on messages by time, so that the exact time can be viewed without requiring mouse-hovering. Indeed, after some time, the rounding of the relative time tend to show relative day when message was posted but the datetime was lacking. However, by only showing time, when many messages are posted the same day, this becomes unclear to know the day the messages were posted, as the date sections do not have any sticky behaviour on viewport. Putting sticky behaviour on date section require more style change, which may probably be reserved for future improvements. This commit fixes the issue by showing the date of non-squashed messages, e.g. "Today at 10:00", "Yesterday at 08:00", "Dec 2 at 20:00", etc. Before / After <img width="194" alt="Screenshot 2024-12-05 at 11 42 33" src="https://github.com/user-attachments/assets/1c9cd1c9-d8d8-4700-88d1-2dba239c87c4"> <img width="265" alt="Screenshot 2024-12-05 at 11 42 18" src="https://github.com/user-attachments/assets/359a308c-a380-49af-986f-ab13839f013b">
The livechat window buttons now adapt their hover color to the customized chat header color instead of using a fixed white or dark style. This keeps actions visible and easier to use across default, white, dark, and customized livechat themes.
Original PR description
Chat window action mouse hover effect was hardcoded for white and dark theme. In livechat, the header color can be customised. With the default colors (purple background and white text), the hover…
Chat window action mouse hover effect was hardcoded for white and dark theme. In livechat, the header color can be customised. With the default colors (purple background and white text), the hover effect had white background, which made the action not visible. This commit fixes the issue by using a slight color invert when mouse hovering the action of a chat window, so that the color is slightly different from header color while keeping icon color distinguishable. Before / After <img width="390" alt="Screenshot 2024-12-04 at 17 10 23" src="https://github.com/user-attachments/assets/f4993b05-5f69-4de6-8423-fc69f7b2bdd7"> <img width="393" alt="Screenshot 2024-12-04 at 17 09 37" src="https://github.com/user-attachments/assets/1c867d1a-8df8-46e3-ae04-e68154e169a5"> White and dark theme are more catchy as a result: Before / After (white theme) <img width="394" alt="Screenshot 2024-12-04 at 17 11 16" src="https://github.com/user-attachments/assets/e29578ca-8b15-45d9-828a-aa65b43a6b23"> <img width="384" alt="Screenshot 2024-12-04 at 17 11 40" src="https://github.com/user-attachments/assets/025b2145-b783-4ab0-bf94-44fe24d32d81"> Before / After (dark theme) <img width="389" alt="Screenshot 2024-12-04 at 17 11 05" src="https://github.com/user-attachments/assets/be50f34d-7468-415b-b365-734fed3e9001"> <img width="387" alt="Screenshot 2024-12-04 at 17 11 59" src="https://github.com/user-attachments/assets/8a0a8c09-c179-4e1e-befe-0fcdff3a181c">
The automated tour for Knowledge article commands has been updated to work with the current editor behavior. This helps ensure the Knowledge app remains properly tested and reduces the risk of unnoticed issues reaching users.
Original PR description
In this commit, we fix knowledge_article_commands_tour by adapting the steps that concern the odoo editor in order to reactivate this tour.
This fix ensures key document-related automation is restored correctly when upgrading to version 18.0 if customers previously removed related document tags. It also prevents those restored records from being recreated again on later updates, reducing unexpected changes after the upgrade.
Original PR description
server actions that use document tag should be noupdate as well because document tag records are noupdate, and they could be deleted by clients. possible steps to reproduce: 1) make a database 17.0 2) delete document tags 3) upgrade the database to 18.0 Document tags and server actions should be recreated in upgrade scripts when upgrading to 18.0 if they are missing. Setting the noupdate=1, makes sure that they are not recreated on subsequent updates or upgrades after reaching 18.0. odoo/upgrade#6803
The Documents app now correctly copies shareable links when users select files from the list view. This prevents blank or missing links, making it easier for users to share documents reliably.
Original PR description
In list view, the "Copy links" [action](https://github.com/odoo/enterprise/blob/0c2b8ab5c0675485a8dbde3371e347f43250a66e/documents/static/src/views/search/documents_control_panel.xml#L42) was returning empty string (or undefined), since we haven't added the field `access_url` to the list view, so accessing it on the `record.data` [from JS](https://github.com/odoo/enterprise/blob/7a65d1e776ea486538cfc9762cb482fd71bf9dc1/documents/static/src/views/search/documents_control_panel.js#L262) returned `undefined`. Now, we add `access_url` field as a hidden field in the list view. opw-4309365
This fix ensures projects linked to shared documents are visible to portal users when needed. It keeps document access working as expected after related access rules changed, preventing failures for external users or automated checks.
Original PR description
Before this commit, the test fails due to the changes made in community to avoid having an access token if the project visibility is private. This commit makes sure the project visibility is `portal` to be able to set an access token as before. opw-4104804 task-4354145
The document deletion test tour has been adjusted to avoid timing-related failures caused by an error dialog appearing during automated checks. This helps keep validation runs more stable and faster, reducing false alarms for teams relying on test results.
Original PR description
In this commit, we fix the tour documents_delete_tours in which there is an error message that said: " Record does not exist or has been deleted. " As there is a modal in DOM, the next step could not be passed (depends on time the modal appears).
Miscellaneous changes
Commit [1] allowed to pass the env to overlays, as a prop. However, when doing so, the env was inserted in a reactive array (`overlays`) which thus made it reactive as well. That reactive env was then used as childEnv for the overlay items. Having a reactive env isn't a good idea, relying on this isn't either. Indeed, changes in the "non reactive" env wouldn't be taken into account. Moreover, it can lead to unexpected excessive re-renderings, or even to crashes (a reactive object is a proxy,
Original PR description
Commit [1] allowed to pass the env to overlays, as a prop. However, when doing so, the env was inserted in a reactive array (`overlays`) which thus made it reactive as well. That reactive env was then used as childEnv for the overlay items. Having a reactive env isn't a good idea, relying on this isn't either. Indeed, changes in the "non reactive" env wouldn't be taken into account. Moreover, it can lead to unexpected excessive re-renderings, or even to crashes (a reactive object is a proxy, and for instance, calling `difference` on a Set wrapped in a proxy crashes). [1] odoo/odoo@7851d85f26c525a90fdb1131c5e4d51a6b140c13 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#189764
**Steps to reproduce the bug:** - Create a storable product: - "Finished Product" with the following BoM: - Component: 1 unit of "C1" - Byproducts: - 1 unit of "By-product 1" - 1 unit of "By-product 2" - Create a manufacturing order to produce 5 units of the finished product. - Confirm the MO. - Set the quantity produced to 5 units. - Set the quantity of byproducts to: - By-product 1: 4 units - By-product 2: 3 units - Validate the MO. - Print
Original PR description
**Steps to reproduce the bug:**
- Create a storable product:
- "Finished Product" with the following BoM:
- Component: 1 unit of "C1"
- Byproducts:
- 1 unit of "By-product 1"
- 1 unit of "By-product 2"
- Create a manufacturing order to produce 5 units of the finished product.
- Confirm the MO.
- Set the quantity produced to 5 units.
- Set the quantity of byproducts to:
- By-product 1: 4 units
- By-product 2: 3 units
- Validate the MO.
- Print the cost analysis.
**Problem:**
The reported quantity does not show the actual quantity produced but
instead shows the "to produce" quantity.
opw-4312292
Forward-Port-Of: odoo/odoo#189198
Forward-Port-Of: odoo/odoo#188854Since odoo/odoo#171869, for inbox notification, we check if the mentioned partners have a valid uid, which makes sense. But the query to get recipients in `discuss.channel` doesn't take the `uid` into account, and this leads to not getting an inbox notification when mentioning a partner in a channel. This commit fixes that by including the uid in the recipients computation for channels. Steps to reproduce: - Set the first user's notification settings, e.g. admin, to `Handle in Odoo` - Logi
Original PR description
Since odoo/odoo#171869, for inbox notification, we check if the mentioned partners have a valid uid, which makes sense. But the query to get recipients in `discuss.channel` doesn't take the `uid` into account, and this leads to not getting an inbox notification when mentioning a partner in a channel. This commit fixes that by including the uid in the recipients computation for channels. Steps to reproduce: - Set the first user's notification settings, e.g. admin, to `Handle in Odoo` - Login as another user (e.g. demo) and send a message with mentioning the first user - The message will not appear in the first user's inbox until the page is refreshed Forward-Port-Of: odoo/odoo#189484
Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "
Original PR description
Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "Navbar" option. - Click the "Mobile Preview" button. - Click the "Hamburger menu" button to open the mobile navbar. - Bug: The text color is not "red". [1]: https://github.com/odoo/odoo/commit/1e30600d9e0e12e43fcbca60760a64f2551e3c8f opw-4364765 Forward-Port-Of: odoo/odoo#189417
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189644 Forward-Port-Of: odoo/odoo#189467
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189644 Forward-Port-Of: odoo/odoo#189467
Steps to Reproduce - Go to Surveys - Select a survey > Options Tab > Check the "Require Login" box - Save > Share the survey > Check the "Send by Email" box > Select any partner > "Send" - Go to Settings > Technical > Emails - Open the Email sent to the selected partner in step 3 - Try to open the link in an incognito browser instance (Not logged in) Current behaviour: Visiting the Survey Invite link throws "500: Internal Server Error" to the user. Expected behaviour: Redirect to t
Original PR description
Steps to Reproduce - Go to Surveys - Select a survey > Options Tab > Check the "Require Login" box - Save > Share the survey > Check the "Send by Email" box > Select any partner > "Send" - Go to Settings > Technical > Emails - Open the Email sent to the selected partner in step 3 - Try to open the link in an incognito browser instance (Not logged in) Current behaviour: Visiting the Survey Invite link throws "500: Internal Server Error" to the user. Expected behaviour: Redirect to the login page. Cause: The signature of `signup_prepare` changed in 94b969b035da3d4200, but `survey` code was not adapted. Fixes #189332 Forward-Port-Of: odoo/odoo#189381
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure status back to the user, even for sucessful subsequent operations. This is particularly problematic, for example in the special case of BlackBox BE, where some points of sales have multiple checkouts using the same POS session and the same IoT Box + BlackBox. If at any point, a cashier sent an erroneo
Original PR description
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure…
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure status back to the user, even for sucessful subsequent operations. This is particularly problematic, for example in the special case of BlackBox BE, where some points of sales have multiple checkouts using the same POS session and the same IoT Box + BlackBox. If at any point, a cashier sent an erroneous message to the IoT Box or to the Blackbox, all checkouts would become blocked, with the only alternative being to reload the handlers or restart the IoT Box. Furthermore, the subsequent actions appearing as refused may have executed successfully. Which means there would be a mismatch between the data stored in Odoo (multiple failed transactions) and the data sent to the SPF (one failed transaction, then many successful ones). After this commit, the driver status is reset after being sent once. That way, when a new action is sent from the client to the IoT box, it's the status of the execution of this action and not the previous one that gets sent back to the client. opw-4313538 opw-4182434 opw-4293988 Forward-Port-Of: odoo/odoo#189506 Forward-Port-Of: odoo/odoo#186735
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of concurrent.futures: exception calling callback for <Future at 0x7f212c073110 state=finished raised ChromeBrowserException> Traceback (most recent call last): File "concurrent/futures/_base.py", line 340, in _invoke_callbacks callback(self) File "odoo/odoo/tests/common.py", line 1532, in handler
Original PR description
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of concurrent.futures: exception calling…
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of
concurrent.futures: exception calling callback for <Future at 0x7f212c073110 state=finished raised ChromeBrowserException>
Traceback (most recent call last):
File "concurrent/futures/_base.py", line 340, in _invoke_callbacks
callback(self)
File "odoo/odoo/tests/common.py", line 1532, in handler
base_png = f.result(timeout=0)['data']
^^^^^^^^^^^^^^^^^^^
File "concurrent/futures/_base.py", line 449, in result
return self.__get_result()
^^^^^^^^^^^^^^^^^^^
File "concurrent/futures/_base.py", line 401, in __get_result
raise self._exception
odoo.tests.common.ChromeBrowserException: Internal error
As this is mostly unhelpful, handle the thing better, and lower the concern to `RUNBOT`: giving prominence to the screenshot failure is probably less relevant than the actual reason why we tried to take a screenshot in the first place?
Forward-Port-Of: odoo/odoo#189585Before this commit: - The `::before` pseudo-element had `width: -webkit-fill-available` and `width: -moz-available`, causing it to span the entire width of its container. - Its `z-index: 100` made it overlap with other elements, preventing interaction with underlying elements. After this commit: - `pointer-events: none` was applied to the pseudo-element. - This allows interactions with underlying elements while retaining the visual styling. task-4313526 --- I confirm I have sig
Original PR description
Before this commit: - The `::before` pseudo-element had `width: -webkit-fill-available` and `width: -moz-available`, causing it to span the entire width of its container. - Its `z-index: 100` made it overlap with other elements, preventing interaction with underlying elements. After this commit: - `pointer-events: none` was applied to the pseudo-element. - This allows interactions with underlying elements while retaining the visual styling. task-4313526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187915
In commit [1], we introduced a "data-forced-size" attribute on "image shapes" SVGs to adjust SVGs height to ensure the image fits properly within it (e.g. for "devices" shapes). However, the "image_shape" route was not updated to match this change, preventing the use of predefined building blocks containing an image shape with a "forced-size" attribute. This commit updates the "image_shape" route to support the "data-forced-size" attribute. [1]: https://github.com/odoo/odoo/commit/
Original PR description
In commit [1], we introduced a "data-forced-size" attribute on "image shapes" SVGs to adjust SVGs height to ensure the image fits properly within it (e.g. for "devices" shapes). However, the "image_shape" route was not updated to match this change, preventing the use of predefined building blocks containing an image shape with a "forced-size" attribute. This commit updates the "image_shape" route to support the "data-forced-size" attribute. [1]: https://github.com/odoo/odoo/commit/63cf8a693a5262600d465d70f0383229464d71e7 task-4094393 Forward-Port-Of: odoo/odoo#189156
In odoo#130825, we prevented the import of records that are given an XMLid that belongs to an Odoo module, because such records would be unlinked when the module is updated. However, if the XMLid has noupdate set to True, then the record will not get unlinked anyway when the module is updated, so we should not block it from being creataed. This is useful because there are cases where during an import, `_load_records` is called again by the business code. For example, in 17.0+, when impo
Original PR description
In odoo#130825, we prevented the import of records that are given an XMLid that belongs to an Odoo module, because such records would be unlinked when the module is updated. However, if the XMLid has noupdate set to True, then the record will not get unlinked anyway when the module is updated, so we should not block it from being creataed. This is useful because there are cases where during an import, `_load_records` is called again by the business code. For example, in 17.0+, when importing a chart of accounts on a new company, the import of the opening balances causes a new 'Unaffected Earnings' account to be created via `_load_records`, with `noupdate=True`.[^1] [^1]: https://github.com/odoo/odoo/blob/a73e45ff9459ffdc0128327fac47962c6fe27af7/addons/account/models/company.py#L473 task-none runbot-108001 Forward-Port-Of: odoo/odoo#189449 Forward-Port-Of: odoo/odoo#185030
Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal". This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'. This change remove the token when the privacy is changed at the time of the write() This change is done in the project module because it depends on "portal", and not the other way around. This change can also be
Original PR description
Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal". This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'. This change remove the token when the privacy is changed at the time of the write() This change is done in the project module because it depends on "portal", and not the other way around. This change can also be used as an invalidation mecanism in case of a token leak. Changing the privacy to 'private' then to 'portal' will allow for an invalidation of the previous token and the creation of new one. opw-4104804 task-4354145 Closes #176177 Forward-Port-Of: odoo/odoo#189314 Forward-Port-Of: odoo/odoo#188264
Steps to reproduce: - Navigate to Website - Open the user dropdown menu and select "My Account". - On the right-hand side of the page, click on "Edit information". - Enter edit mode. - Drag and drop a form inside the existing form. - Save the changes. - Re-enter edit mode. - Click on any field within the newly added form. - A traceback is triggered. HTML5, as defined by the W3C, prohibits the use of nested \<form\> elements, as they are invalid and lead to undefined behavior in bro
Original PR description
Steps to reproduce: - Navigate to Website - Open the user dropdown menu and select "My Account". - On the right-hand side of the page, click on "Edit information". - Enter edit mode. - Drag and drop…
Steps to reproduce: - Navigate to Website - Open the user dropdown menu and select "My Account". - On the right-hand side of the page, click on "Edit information". - Enter edit mode. - Drag and drop a form inside the existing form. - Save the changes. - Re-enter edit mode. - Click on any field within the newly added form. - A traceback is triggered. HTML5, as defined by the W3C, prohibits the use of nested \<form\> elements, as they are invalid and lead to undefined behavior in browsers. To address this, the website_form snippet has been updated to prevent it from being dropped inside another form. This fix ensures compliance with HTML5 specifications and prevents invalid document structures from being created within the website builder. Due to this commit [1], buttons were added as inline building blocks. As a result, you could insert blocks either directly before or after the button. Since this wasn't the case before, we never encountered any issues in forms, as nothing could be inserted there. [1]: https://github.com/odoo/odoo/commit/507b80a12574c opw-4305352 Forward-Port-Of: odoo/odoo#189420 Forward-Port-Of: odoo/odoo#188028
**Steps to reproduce the bug:** - Create a storable product: - "Finished Product" with the following BoM: - Component: 1 unit of "C1" - Byproducts: - 1 unit of "By-product 1" - 1 unit of "By-product 2" - Create a manufacturing order to produce 5 units of the finished product. - Confirm the MO. - Set the quantity produced to 5 units. - Set the quantity of byproducts to: - By-product 1: 4 units - By-product 2: 3 units - Validate the MO. - Print
Original PR description
**Steps to reproduce the bug:**
- Create a storable product:
- "Finished Product" with the following BoM:
- Component: 1 unit of "C1"
- Byproducts:
- 1 unit of "By-product 1"
- 1 unit of "By-product 2"
- Create a manufacturing order to produce 5 units of the finished product.
- Confirm the MO.
- Set the quantity produced to 5 units.
- Set the quantity of byproducts to:
- By-product 1: 4 units
- By-product 2: 3 units
- Validate the MO.
- Print the cost analysis.
**Problem:**
The reported quantity does not show the actual quantity produced but
instead shows the "to produce" quantity.
opw-4312292
Forward-Port-Of: odoo/enterprise#74917
Forward-Port-Of: odoo/enterprise#73666LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the IoT Box form view. Community PR: [https://github.com/odoo/odoo/pull/189467](https://github.com/odoo/odoo/pull/189467) Task: 4345731 Forward-Port-Of: odoo/enterprise#75161 Forward-Port-Of: odoo/enterprise#75074
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the IoT Box form view. Community PR: [https://github.com/odoo/odoo/pull/189467](https://github.com/odoo/odoo/pull/189467) Task: 4345731 Forward-Port-Of: odoo/enterprise#75161 Forward-Port-Of: odoo/enterprise#75074
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already. ======================================= [FIX] account_reports: properly handle groupby in account_co
Original PR description
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html ,…
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior
As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already.
=======================================
[FIX] account_reports: properly handle groupby in account_codes engine for grouping keys used with multiple accounts
// TO REPRODUCE
1) Create a report with a single line, whose computation uses the account_codes engine, with formula "1". Set "partner_id" as the groupby value for that line. Setup a "load more limit" of 2 on your report.
2) Create 3 accounts, with codes 11, 12, 13
3) Create 3 partners: A, B, and C
4) Create journal entries, with the following lines (all balancing lines must use other accounts as the ones defined in 2) ), in that order:
- on account 11, with partner A, debit=10
- on account 11, with partner A, debit=20
- on account 12, with partner A, debit=25
- on account 11, without partner, debit=30
- on account 11, without partner, debit=40
- on account 12, with partner B, debit=50
- on account 13, with partner C, debit=60
5) Open the report for a period covering all the created journal entries, and have a look at the sublines generated for the groupby.
=> With the limit being 2, you'd expect to see "A", "B", and a "Load more..." line allowing to visualize the rest (namely a line for "C", and "Unknown"). Instead of that, you see no "Load more ...", and line "A"'s amount is wrong.
// EXPLANATION
The SQL query of the account_codes engine is grouping not only by groupby key (here, partner_id), but also by account_id, to be able to process the "C" and "D" suffixes of the formula later on. Because of that, the LIMIT passed by the load_more_limit is applied on that grouping.
With a load_more_limit of 2, we try to load 3 lines. If we manage to load 3, we only display 2, but know we need to display the "Load more..." line. Else, we know there are no more results, so no need for that additional line.
So, with our example, the query runs with a LIMIT of 3, returning
- 30 for A on account 11
- 25 for A on account 12
- 70 for no partner on account 11
Then, another issue happens:
The results returned by the SQL query (hence, by the engine) contain two times the same partner_id. From an engine perspective, the grouping key is only partner_id, not account_id (which is only used for an inner computation, with the SQL query). So that means the same grouping key has two different values. This is not legit, and causes one of them to shadow the other.
The report computation then receives 1 result for A, and 1 for "Unknown", so it renders them, and since there is no third result, it does not display the "Load more ...".
Forward-Port-Of: odoo/enterprise#75024
Forward-Port-Of: odoo/enterprise#74784Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3) Enable the `repeat` and update the start and end date 4) Give the edit value as `All shifts` and make sure the resource be empty 5) Save the record. Error:- ``` IndexError: tuple index out of range ``` Here the `resource` is not required in planning slot. So, when the user tries to
Original PR description
Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3)…
Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3) Enable the `repeat` and update the start and end date 4) Give the edit value as `All shifts` and make sure the resource be empty 5) Save the record. Error:- ``` IndexError: tuple index out of range ``` Here the `resource` is not required in planning slot. So, when the user tries to update an open shift with the `repeat` enabled and `resource_update` as `all`, it leads to a traceback from the below line. https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/planning/models/planning.py#L866-L871 This is because when there is no `recurrence_slots` in the slot, we get an empty recordset for the `recurrence_slots`, which leads to the above traceback when trying to extract a value from the recurrency_slots. We can resolve this issue by adding an extra check of `recurrence_slots` which makes the code more robust. sentry-6096445646 Forward-Port-Of: odoo/enterprise#75085 Forward-Port-Of: odoo/enterprise#74866
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |------
Original PR description
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |--------------|---------|--------| | 500 | 2 s | 1.55 s | | 7k | 20 s | 19 s | | 17k | 50 s | 41 s | ### Reference opw-4287192 Forward-Port-Of: odoo/enterprise#74997 Forward-Port-Of: odoo/enterprise#74085
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will
Original PR description
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1.…
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will split the order, sending the done items to the next stage. 6. back in the POS, create a new order (any table) 7. on disp2, you will see a wrong duplication of the order the was split at the previous step number 5 The duplication would happen even if the order (and related split) are marked as done on both disp1 and disp2. What that means in the client flow is that you could have completely processed the order at both stations, and have it reappear at one of them. In practice, since inter-station communication is not always possible, it could lead to the staff preparing the same order multiple times. This in turn would incur losses because of the wasted orders and increased delays in processing other legitimate orders. After this commit, the other preparation displays (disp2 in my example above) get notified immediately of the change and update their respective statuses to reflect the order split. opw-4367937 Forward-Port-Of: odoo/enterprise#74816
Issue ===== When tracked product setting was disabled, the "Group by products" barcode setting for operation type was ignored. How to reproduce ================ - Install `stock_barcode_picking_batch`; - Ensure "Lots & Serial Numbers" is disabled, to be sure, go in Inventory > Configuration > Settings; - Now, go in Configuration > Operation Type > Receipts > Barcode App, and check "Group batch lines"; - Create a receipt for a product and confirm it; - Duplicate this receipt and co
Original PR description
Issue ===== When tracked product setting was disabled, the "Group by products" barcode setting for operation type was ignored. How to reproduce ================ - Install `stock_barcode_picking_batch`; - Ensure "Lots & Serial Numbers" is disabled, to be sure, go in Inventory > Configuration > Settings; - Now, go in Configuration > Operation Type > Receipts > Barcode App, and check "Group batch lines"; - Create a receipt for a product and confirm it; - Duplicate this receipt and confirm it aswell; - Add these two pickings in a batch and open it in the Barcode app -> You can see the lines for the same product are not grouped. Cause ===== The issue was, in the `BarcodeModel` code, we skip the method who group the lines if tracking is disabled. [task-4291149](https://www.odoo.com/odoo/project.task/4353554) Forward-Port-Of: odoo/enterprise#74696
## Issue: - The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit. ## Steps to reproduce: - Create a manufactured product and two components with costs and on hand quantities. - Confirm a manufacturing order for the product. - Adjust the manufactured quantity of the manufactured product. - Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit. ## Solution:
Original PR description
## Issue: - The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit. ## Steps to reproduce: - Create a manufactured product and two components with costs and on hand quantities. - Confirm a manufacturing order for the product. - Adjust the manufactured quantity of the manufactured product. - Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit. ## Solution: - Updated the calculation of `mo_qty` to sum the 'quantity' field instead of `product_qty`. opw-4118237 Forward-Port-Of: odoo/enterprise#74636 Forward-Port-Of: odoo/enterprise#70727
5 changes
Enhancements to existing features
This update addresses necessary adjustments to the Danish localization package (l10n_dk) following a recent change in the community version. Specifically, tests have been updated to align with the new account type. This ensures continued accurate reporting and compliance for Danish businesses using Odoo Enterprise.
Original PR description
Following the change of account type in the community pr, some tests had to be modified. task: 4341375
Resolved issues and error corrections
This update prevents the creation of quality checks when inventory is marked as 'Scrapped' within Odoo. Previously, a quality check was automatically generated after a 'Scrap' action, which was an unnecessary step. This change streamlines the process and ensures accurate inventory tracking.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1.” - Set up a quality point: - Control Per: By operation - Operation: Receipts - Product: P1 - Create a receipt for two units of P1. - Mark the receipt as "To Do." - Click on "Quality Check" → Fail. - Click on action → Scrap: - Scrap 1 unit of P1. - Confirm. Problem: A quality check is created for the scrapped move. This should not happen. opw-4345679
This update resolves a technical error that prevented users from successfully splitting documents when scheduling activities within the Documents module. The fix ensures that document IDs are correctly included, allowing the splitting functionality to work as intended. This improves the reliability of document management workflows.
Original PR description
useEffect hook on pdf_manager generates file urls from documents ids, before this commit documents comming from activity view didn't have id key set. Reproduce --- - install document - open documents activity view, schedule an activity with a document (that is possible to split) - attempt to split the document -> Traceback opw-4163726
This update resolves an issue where deleting all stages from a helpdesk ticket kanban view resulted in a blank screen. The fix ensures that the correct data is displayed after stage deletion, improving the user experience. The problem stemmed from a validation oversight in the system.
Original PR description
Steps: - Create a new helpdesk team. - Open tickets of that team. - Delete all ticket stages Issue: - If all the stages are deleted then the blank screen appears instead of shadow data. Cause: - Only `helpdesk.ticket` was being validated, but `helpdesk.stage.delete.wizard` was not included in the check. Fix: - The issue has been fixed by replacing active_model with default_team_id. task-4290529
This update corrects a technical issue that caused a traceback error when users interacted with the bank reconciliation feature in Odoo Enterprise. The fix ensures that the system correctly handles user selections, preventing errors and improving the overall stability of the accounting process. This resolves a minor disruption for users.
Original PR description
Fixing a traceback when selecting text, because the t-on-click was triggered but the target had no attribute. task: 4260301 Forward-Port-Of: odoo/enterprise#74509