Daily updates from Odoo
Navigate
Branch
Monday, April 28, 2025
53 changes
24 changes
Security fixes and vulnerability patches
Live chat reaction summaries now use an agent’s custom live chat display name when one is set, instead of showing their real user name. This prevents accidental exposure of staff identities while keeping reaction details understandable for visitors and operators.
Original PR description
Before this PR, real user name was displayed in the message reaction summary. We should use the custom live chat name if any not to leak the real name of the agent. This PR fixes this 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
Resolved issues and error corrections
A missing controller connection was added to the Project kanban view so that previously prepared behavior now works as intended. This helps ensure users see the correct project task interactions in the kanban interface.
Original PR description
The controller extended in the PR https://github.com/odoo/odoo/pull/194090 is not added in to the view. Adding into project kanban view.
Self-order pickup or takeout times now appear at the time selected by the customer instead of being shifted by the local time zone. This prevents staff from seeing incorrect preparation or collection times in the Point of Sale order view.
Original PR description
Steps to reproduce ------------------ 1. Enable self order, and enable presets 2. In self order interface, choose the preset "takeout" that will by default be configured to use time slots. 3. When paying the order, select a time, say 12:00 Observation ----------- In the PoS session interface, go to orders, and observe that this order shows the time as 14:00 (or whatever your tz diff is + 12:00). Reason ------ When assigning a datetime to `preset_time`, we assign it as a local datetime, when it waits to be assigned a UTC datetime. So for instance, if we assign "2025-04-25 12:00:00" to it, it will be interpreted as UTC date an hence in the PoS orders UI, we see it converted to local date and hence a mismatch. Fix --- Convert the formatted date string into UTC before assigning it to `preset_time`. opw-4728248
Miscellaneous changes
Issue --> When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this method, the search domain contains `qty_to_order` which causes computations to fulfil the search query. The search_query also contains `("trigger", "=", "manual")`. Even if the recordset for this leaf is 0, the `qty_to_order` computations still occur, only to return 0 records in the search. Soluti
Original PR description
Issue --> When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this…
Issue -->
When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this method, the search domain contains `qty_to_order` which causes computations to fulfil the search query. The search_query also contains `("trigger", "=", "manual")`. Even if the recordset for this leaf is 0, the `qty_to_order` computations still occur, only to return 0 records in the search.
Solution -->
Move the `qty_to_order <= 0` check after the search produces a recordset for `("trigger", "=", "manual")`. This avoids unnecessary computations.
Benchmarks -->
For this benchmark, we'll assume the worst case, where every orderpoint on the database has trigger set to `auto`. The number of seconds represents the time taken to open the Replenishment view.
| # of auto trigger orderpoints | Before | After |
|--------|--------|--------|
| 12.2k | 155.58 s | 4.49 s |
| 6k | 59.87 s | 3.78 s |
opw-4606704
Forward-Port-Of: odoo/odoo#203182This commit disable both protection upon neutralizing a db by removing the tokens. Manual forward port of #207020 opw-4734555 upg-2759374 Forward-Port-Of: odoo/odoo#207684
Original PR description
This commit disable both protection upon neutralizing a db by removing the tokens. Manual forward port of #207020 opw-4734555 upg-2759374 Forward-Port-Of: odoo/odoo#207684
In Romania, when sending multiple invoices to e-Factura, if one invoice is rejected, the Send & Print wizard will raise a UserError at https://github.com/odoo/odoo/blob/9416ca8cb63fc53a862aa8533dfa60ba33506191/addons/account/wizard/account_move_send.py#L461 This causes the transaction to get rolled back, and any successfully-sent invoices to be lost. Solution: Commit after each invoice is sent. opw-4630496 Forward-Port-Of: odoo/odoo#206901 Forward-Port-Of: odoo/odoo#205593
Original PR description
In Romania, when sending multiple invoices to e-Factura, if one invoice is rejected, the Send & Print wizard will raise a UserError at https://github.com/odoo/odoo/blob/9416ca8cb63fc53a862aa8533dfa60ba33506191/addons/account/wizard/account_move_send.py#L461 This causes the transaction to get rolled back, and any successfully-sent invoices to be lost. Solution: Commit after each invoice is sent. opw-4630496 Forward-Port-Of: odoo/odoo#206901 Forward-Port-Of: odoo/odoo#205593
Accessing external resources in chrome can increase randomness in execution for multiple reasons: - the external resource may temporary not be available - the external resource may be faster-slower to load - the external server could block some requests because of rate limiting - the network may be unreachable. Moreover, downloading fonts at every execution also slows down the tests A possibility to solve the issue was to block the network on runbot, in the dockers. The main problem
Original PR description
Accessing external resources in chrome can increase randomness in execution for multiple reasons: - the external resource may temporary not be available - the external resource may be faster-slower…
Accessing external resources in chrome can increase randomness in execution for multiple reasons: - the external resource may temporary not be available - the external resource may be faster-slower to load - the external server could block some requests because of rate limiting - the network may be unreachable. Moreover, downloading fonts at every execution also slows down the tests A possibility to solve the issue was to block the network on runbot, in the dockers. The main problem with this solution is that it wouldn't be the same behavior locally. It is also hard to adapt all versions at the same time. This commit introduced another solution, using Fetch.enable in the chrome developers tools. This will allow to have a callback on every external request, allowing to enable/disable/give an alternate answer to the request. All local request are allowed, all external request should be either blocked or an alternative answer given. This could be costly but at first glance it looks like it had no visible negative impact on performances. The first version was blocking all external requests, leading to a lot of failing tests, most of them already seen in nighties. It is hard to say since depending on when it happens it could create different error message, at least a few dozens of error related to this where found, maybe a few hundreds looking at the kind of patterns it can cause. Following this attempts a fix was to vendor all needed sources leading to ~130 cached url, with more than 100 fonts. This list was furthered reduced to have default fonts that would be returned reducing the load. A test was made to return a 404 instead and it was actually enough, and it is the same for most requests (stripe, ayden, ...). Only a few of them needs a answer close to reality. - The gooleapis css can be emty but not a 404 because it may make some of the css computation fail (website.backend_assets_all_wysiwyg.min.css) One of the failling test is TestCustomSnippet.test_01_run_tour This final version returns a 404 for most resources. A version returning 500 also works fine. This pr could impact other cis (odoosh, other runbot) but the impact is expected to be slow wince only two tests needed to be adapted outside tests/common.py. It would be still possible to make Fetch.enable optional using an environment variable. Targeting 18.0 looks reasonable for a start, could be backported to 16.0 later Note that this pr may make some random error more frequent, #207469 was needed to make this pr green. The assumption is that the speedup of the loading of some resources (or possible slowdown of local request) may change the timing of the execution revealing making some error more frequent. Forward-Port-Of: odoo/odoo#207157
Steps to reproduce the bug: - Create a service product “S1” - Create a repair order: - In the parts: - Click on the catalog Problem: You can select a service product, whereas the products in the repair parts should be restricted to consumable-type products only: https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48 opw-4687472 Forward-Port-Of: odoo/odoo#206521 Forward-Port-Of: odoo/odoo#204527
Original PR description
Steps to reproduce the bug:
- Create a service product “S1”
- Create a repair order:
- In the parts: - Click on the catalog
Problem:
You can select a service product, whereas the products in the repair parts should be restricted to consumable-type products only:
https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48
opw-4687472
Forward-Port-Of: odoo/odoo#206521
Forward-Port-Of: odoo/odoo#204527[FIX] accounting: missing chart line "758 Indemnités et autres produits" was missing Steps to reproduce: ------------------- * French Fiscal Localization * Open the Chart of Accounts * Line 758 missing Why the fix: ------------ Based on French government documentation https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/Plan-de-comptes-PCG-2025.pdf opw-4699235 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/
Original PR description
[FIX] accounting: missing chart line "758 Indemnités et autres produits" was missing Steps to reproduce: ------------------- * French Fiscal Localization * Open the Chart of Accounts * Line 758 missing Why the fix: ------------ Based on French government documentation https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/Plan-de-comptes-PCG-2025.pdf opw-4699235 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207312 Forward-Port-Of: odoo/odoo#205552
Issue Before This Commit: ------------------------------ The 'company' field was required but not validated in relevant triggers for scrap orders. This allowed operations to proceed even when the 'company' field was unset, leading to unexpected issues and inconsistent behavior. Steps to reproduce: ------------------------------ 1. Enable multi-step routes. 2. Create a new scrap order and add a product. 3. Remove the company from the company field. With This Commit: -----------------
Original PR description
Issue Before This Commit: ------------------------------ The 'company' field was required but not validated in relevant triggers for scrap orders. This allowed operations to proceed even when the 'company' field was unset, leading to unexpected issues and inconsistent behavior. Steps to reproduce: ------------------------------ 1. Enable multi-step routes. 2. Create a new scrap order and add a product. 3. Remove the company from the company field. With This Commit: ------------------------------ - Added a check for 'company' in relevant triggers to ensure that operations only proceed if a company is set. - This fix guarantees that the 'company' field is always set (required), preventing errors and maintaining consistent behavior in scrap orders. task-4497387 Forward-Port-Of: odoo/odoo#194702
https://runbot.odoo.com/odoo/error/163640 Forward-Port-Of: odoo/odoo#207642
Original PR description
https://runbot.odoo.com/odoo/error/163640 Forward-Port-Of: odoo/odoo#207642
Steps: === - Open Restaurant in POS system. - Create an order with preset as `Takeout` and select desired time. - validate it. - open that order in backend. - Observe the takeout date & time—it differs from the originally selected time. Issue: === - The POS system stores the preset_time in local time directly to the database, but the backend consider it as UTC, leading to mismatched times when displayed. Fix: === - The frontend now sets preset_time in UTC before saving, ensuring
Original PR description
Steps: === - Open Restaurant in POS system. - Create an order with preset as `Takeout` and select desired time. - validate it. - open that order in backend. - Observe the takeout date & time—it differs from the originally selected time. Issue: === - The POS system stores the preset_time in local time directly to the database, but the backend consider it as UTC, leading to mismatched times when displayed. Fix: === - The frontend now sets preset_time in UTC before saving, ensuring consistent time handling across the system. Task: 4477402 Related: odoo/enterprise#77558 Forward-Port-Of: odoo/odoo#194058
The certificate and keys models were added in 18.0. A few docstrings could help devs using those methods. Furthermore, a few more checks and robustness were added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202253
Original PR description
The certificate and keys models were added in 18.0. A few docstrings could help devs using those methods. Furthermore, a few more checks and robustness were added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202253
Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request. This is because this stable solution cannot catch a cursor without cookie that is executed after the browser closes, or during the next test. Checking the logs: 2025-04-11 05:18:04,048 13 INFO 78181227-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /knowledge/tests/test_knowledge_form_ui.py:TestKnowledgeUI.test_knowledge_main_flow 20
Original PR description
Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request. This is because this stable solution cannot catch a cursor without cookie that is executed…
Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request. This is because this stable solution cannot catch a cursor without cookie that is executed after the browser closes, or during the next test. Checking the logs: 2025-04-11 05:18:04,048 13 INFO 78181227-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /knowledge/tests/test_knowledge_form_ui.py:TestKnowledgeUI.test_knowledge_main_flow 2025-04-11 04:56:57,155 13 INFO 78181121-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /test_sale_product_configurators/tests/test_sale_product_configurator.py:TestProductConfiguratorUi.test_02_product_configurator_advanced That indicates that we are in the case where the request don't have a cookie, despite the route being called from a chrome. It is most likely due to the fact that the browser cookie are cleared at the end of a browser js call, before navigating to about:blank 2025-04-11 04:56:57,119 13 INFO 78181121-16-0-all odoo.addons.test_sale_product_configurators.tests.test_sale_product_configurator.TestProductConfiguratorUi: Deleting cookies and clearing local storage It is actually easy to reproduce by adding a sleep before navigating to about:blank in browser.clear(). We can see that the websocket route is still called periodically at the end of a test. This error will occur when this request is made just between the cookies are cleared and the page navigates to about:blank. One possibility is to avoid to clear the cookie since the user profile is deleted after the browser is stopped, but unfortunately in this version the browser is kept between tests of the same class. It is maybe not sufficient but navigating to a blank page before removing the cookies should reduce the possibility of having a request without cookie reaching the server. In this case a sleep after about:blank, before clearing the cookie shows that we don't have repeated call to /websocket anymore. Another possibility is to check if the request is a websocket request and to not open a cursor in that case if we don't have a cookie identifying the test. This cannot be done for all requests since it is possible that some call are made when generating a pdf, or any call that would open a TestCursor without being inside a browser_js or url_open Combining both solution should hopefully highly reduce this error. A final decision was made to also forbid any request coming after a browser_js. - browser_js is the main source of request reaching the server asynchronously. Other ways to create a request on the server is synchronous with the test and will wait for the result. - After a browser js, it is unlikely to make another request outside an url_open or browser_js. It was the case for some xmlrpc requests, the dirty solution was to make the test non strict during this request. Those tests could still be a small cause of randomness. Note: The explicit deletion of the session cookie is also removed, it is not needed since all cookies are cleared just after, and having a request that could reach the server without session cookies feels a little like a good solution to have random access error. Forward-Port-Of: odoo/odoo#206933 Forward-Port-Of: odoo/odoo#206006
### Steps to reproduce: - Create a leave type that creates timesheet - Create a leave for a flexible employee for 4 days - Check the timesheet created for this leave - Notice the amount of this timesheet is 83 hours not 32 ### Cause: When creating a timesheet or a work entry for a leave we get the difference between the start and the end date in milliseconds and divide it by 3600 to get the hours. Timesheet: https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d9
Original PR description
### Steps to reproduce: - Create a leave type that creates timesheet - Create a leave for a flexible employee for 4 days - Check the timesheet created for this leave - Notice the amount of this…
### Steps to reproduce: - Create a leave type that creates timesheet - Create a leave for a flexible employee for 4 days - Check the timesheet created for this leave - Notice the amount of this timesheet is 83 hours not 32 ### Cause: When creating a timesheet or a work entry for a leave we get the difference between the start and the end date in milliseconds and divide it by 3600 to get the hours. Timesheet: https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_mixin.py#L208-L213 Work entry: https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_calendar.py#L522-L525 This doesn't work for flexible hours as when fetching attendance intervals for flexible employee we return one big block for the whole period as there is no attendance intervals for the flexible employees. https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_calendar.py#L370-L376 ### Fix: When fetching the attendance intervals for flexible employee we return the hours per day as duration hours not the diff between the start and the end date of the period. We only use the diff between the dates in case of fully flexible. Then we use this duration hours in timesheet and work entry creation opw-4628296 Forward-Port-Of: odoo/odoo#207299 Forward-Port-Of: odoo/odoo#206252
It seems it was an error of https://github.com/odoo/odoo/commit/077f6d449a660ee6961cce8174c9c6caaf5bc23f. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207465
Original PR description
It seems it was an error of https://github.com/odoo/odoo/commit/077f6d449a660ee6961cce8174c9c6caaf5bc23f. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207465
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + fre
Original PR description
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + french translation added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205755 Forward-Port-Of: odoo/odoo#174511
There was an issue in the `PropertyDefinition:state.propertyDefinition`, which could sometimes not be updated properly, resulting in a traceback after multiple property definition changes. ### How to reproduce: - Open a CRM Lead form view and add a property of type `tags`. - Save and fully reload the form view. - Change the property type to `separator` - Change the property name to another value. - Click outside the popover to close it. => Traceback ``` Cannot read properties of und
Original PR description
There was an issue in the `PropertyDefinition:state.propertyDefinition`, which could sometimes not be updated properly, resulting in a traceback after multiple property definition changes. ### How to…
There was an issue in the `PropertyDefinition:state.propertyDefinition`, which could sometimes not be updated properly, resulting in a traceback after multiple property definition changes. ### How to reproduce: - Open a CRM Lead form view and add a property of type `tags`. - Save and fully reload the form view. - Change the property type to `separator` - Change the property name to another value. - Click outside the popover to close it. => Traceback ``` Cannot read properties of undefined (reading 'type') at PropertiesField.onPropertyDefinitionChange ``` ### Technical explanation: The `propertyDefinition` argument given to `onChange` props of `PropertyDefinition` component is expected to be modified in place, since it is used as the `propertyDefinition` state value. `pick` function creates a shallow copy, therefore using it on `propertyDefinition` in `PropertiesField:onPropertyDefinitionChange` and applying changes on that copy (i.e. in `_regeneratePropertyName`) will prevent these changes to be registered in the `PropertyDefinition:state.propertyDefinition`, resulting in inconsistent values with `PropertyField:propertyList`, which would manifest at the next definition change, since `_getPropertyIndex` would not be able to find the index of the now obsolete `propertyDefinition`. task-4743860 Forward-Port-Of: odoo/odoo#206977 Forward-Port-Of: odoo/odoo#206871
task-4715664 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#205388
Original PR description
task-4715664 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#205388
Since the widget for non trailing zeros float is used in payroll and payroll does not depend on hr_holidays now, we move the widget to core hr Forward-Port-Of: odoo/odoo#207441
Original PR description
Since the widget for non trailing zeros float is used in payroll and payroll does not depend on hr_holidays now, we move the widget to core hr Forward-Port-Of: odoo/odoo#207441
Steps: ----- 1. Make an order from a time zone such that does not have the same local date as UTC. For instance, from Mexico at 23h. The next day, the order date will say "Today" instead of yesterday's date. Reason: ------- We were not taking into consideration the current timezone when checking if the UTC date corresponds to the local today's date. Fix: ---- Convert the UTC date to a local date before proceeding with our conditional checks. opw-4699263 Forward-Port-Of: odoo/o
Original PR description
Steps: ----- 1. Make an order from a time zone such that does not have the same local date as UTC. For instance, from Mexico at 23h. The next day, the order date will say "Today" instead of yesterday's date. Reason: ------- We were not taking into consideration the current timezone when checking if the UTC date corresponds to the local today's date. Fix: ---- Convert the UTC date to a local date before proceeding with our conditional checks. opw-4699263 Forward-Port-Of: odoo/odoo#206827
steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR
Original PR description
steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207145 Forward-Port-Of: odoo/odoo#176765
This error is generated when a user tries to `create new equipment`. Steps to Reproduce : 1. Install the `MRP` and `Maintenance` modules 2. Go to Settings and set the `Barcode Nomenclature` to `Default GS1 Nomenclature`. 3. In Maintenace > Equipments > Machine & Tools > New. `TypeError: expected string or bytes-like object, got 'bool'` The error occurs when the system attempts to parse a False value through `parse_barcode`, which expects a string. This commit resolves the error
Original PR description
This error is generated when a user tries to `create new equipment`. Steps to Reproduce : 1. Install the `MRP` and `Maintenance` modules 2. Go to Settings and set the `Barcode Nomenclature` to `Default GS1 Nomenclature`. 3. In Maintenace > Equipments > Machine & Tools > New. `TypeError: expected string or bytes-like object, got 'bool'` The error occurs when the system attempts to parse a False value through `parse_barcode`, which expects a string. This commit resolves the error by returning the original condition if a value is false. Sentry:6544673924 OPW : 4725056 Forward-Port-Of: odoo/odoo#206268
Currently the IoT Box are being infested with logs like `2025-04-17 11:30:46,925 13649 WARNING ? odoo.addons.hw_drivers.websocket_client: message type not supported: bundle_changed` This PR removes them as they aren't useful information task-4735615 Forward-Port-Of: odoo/odoo#206503
Original PR description
Currently the IoT Box are being infested with logs like `2025-04-17 11:30:46,925 13649 WARNING ? odoo.addons.hw_drivers.websocket_client: message type not supported: bundle_changed` This PR removes them as they aren't useful information task-4735615 Forward-Port-Of: odoo/odoo#206503
29 changes
Enhancements to existing features
Studio’s automated checks for form and list editing were updated to a newer testing approach. This helps the team validate Studio changes more reliably without changing day-to-day user functionality.
Indian payroll reports are now easier to read and use, with better default selections, formatting, and alignment in exported spreadsheets. Reports also work more reliably for businesses operating multiple companies by keeping each company’s payroll reports separate and preventing duplicate reports for the same period.
Original PR description
This PR improves the clarity, readability and UX of the reports of the indian payroll localisation. What has been done: - The current month is set as default in the EPF report - The text/numbers are correctly left (right) aligned in the xlsx reports - The year is correctly formatted in the EPF report list view - Prevent multiple generation of the report for a given month/year pair The PR also makes the reports compatible with a multi-company environment. task-4711790
Egypt payroll now includes additional salary rules for allowances, leave calculations, overtime, annual leave balances, and yearly gross pay. The update also aligns social insurance naming and tax settings with revised exemption and bracket percentages, helping payroll teams calculate Egyptian payslips more accurately.
Original PR description
In this PR, I have added the salary rule to the employee structure for Egypt. - Salary Rules: - Housing Allowance. - Annual leave provision. - Sick leave calculation. - Unpaid leave calculation. - Out-of-contract leave calculation. - Annual leaves remaining balance. - Gross Yealy. - Overtime. - Updated the name of the Social Insurance rule. - Adjusted the Income Tax exemption amount to 20,000. - Revised the percentages for the Tax Brackets. Task-4509957
The VoIP module has been updated to use Odoo’s newer internal domain handling approach, replacing an older component that is being phased out. This helps keep the module aligned with platform changes and reduces future maintenance risk, with no expected direct change for end users.
Original PR description
odoo.osv is on its way to being deprecated. This commit replaces its usage with Domain, along with rewriting some domains with the new super cool syntax.
Helpdesk users now create a sales order from a dedicated button on the ticket form instead of creating sales order lines automatically from the field. This makes the sales workflow clearer and aligns helpdesk billing behavior with recent sales process changes.
Original PR description
In this PR, we replace the creation of SOL on the fly by an SO creation button in the ticket form. This follows the changes introduced in https://github.com/odoo/odoo/pull/193079. related-https://github.com/odoo/enterprise/pull/42211 task-4461919
Users can now start a signature request by choosing a PDF from the Documents app directly within Sign. This streamlines the workflow by creating a sign template from the selected document and taking users straight to preparing and sharing it.
Original PR description
## Before this commit: Importing PDF files from the documents app to sign on the sign app was not possible. ## After this commit: A new option is shown now in the sign request cog menu that allows the users to import a pdf file from Documents, create a sign template for it, and redirects them to sign and share it. task-4484893
Printed payslips now follow the payroll structure setting for worked day lines. If worked day details are disabled on the payslip structure, the printed report no longer shows the worked days table, keeping employee documents consistent with the form view.
Original PR description
- If the payslip struct has `use_worked_day_lines = False` the printed payslip should not have worked_days_table Task: 4720429
Social media communications for events with multiple time slots are now limited to one post for the overall event. This avoids duplicate promotional messages for each individual slot, keeping event communication clearer and less repetitive.
Original PR description
Do not consider this PR - closed soon. Used for testing and tests.
The end of service report for UAE payroll now calculates worked years based on the employee's full time with the company, rather than only counting actual worked days. This provides a more complete tenure figure for end of service reporting and related HR payroll decisions.
Original PR description
- update the calculation for the worked years in the end of service report to return the whole duration worked with the comapny not just the actual worked days. Task: 4703337
Resolved issues and error corrections
Payroll batches now select employees based on active contracts during the batch period, reducing mistakes such as duplicate or incorrectly matched payslips. This helps payroll teams generate batches with the right contracts and salary structures, improving accuracy across payroll and related accounting reports.
Original PR description
* = hr_payroll{,_account}, l10n_{be,in}_hr_payroll
Problem
----------
- An employee can not have multiple payslip in a batch
- Wrong contract can be selected in the wizard
- Difference between structure payslip's structure and contract's one
Objective
----------
- Base the employees selection on active contracts running in the batch period
- Update tests to follow the good behaviour
Solution
----------
- Link payslip employee wizard with a batch one time with the context
task-4483393The update removes an unrelated point of sale manager permission from shared accounting test setup so permission checks better reflect real usage. Point of sale tests now receive that access only where needed, and product users gain read-only access to Urban Piper status data.
Original PR description
The `group_pos_manager` was previously reintroduced in `AccountTestInvoicingCommon` due to demo data changes. However, this group is unrelated to the `account` module and may mask real permission issues in tests. This commit removes the group from the common test setup and adds it explicitly in the relevant PoS test cases where needed. Grants read-only access to `product.urban.piper.status` for product users. task-id: 4678172 community PR: https://github.com/odoo/odoo/pull/205318
A subscription project helper was renamed to stay aligned with the related sales project update. This prevents a mismatch that could affect revenue item retrieval for subscription projects, with no expected change to day-to-day workflows.
Original PR description
Match the method name from `sale_project` changed in community side PR. opw-4652472
Pivot tables in spreadsheets now generate DATE formulas without unwanted spaces before the day and month values. This prevents formatting issues and makes generated spreadsheet formulas cleaner and more reliable for users.
Original PR description
Removed extra spaces in front of the day and month in DATE function. Task: 4725023
Code cleanup and technical improvements
IoT action confirmations are now handled through a more general confirmation message instead of being limited to print confirmations. This makes it easier for different connected devices and sessions to confirm operations reliably while keeping messages tied to the right session.
Original PR description
Before this commit, the only action confirmation available through websocket was `print_confirmation`. This message has been generalized to allow listening for every action confirmation (now `operation_confirmation`). The recipient will be able to filter messages by `session_id` in order to get those from its session. Community PR: [https://github.com/odoo/odoo/pull/206903](https://github.com/odoo/odoo/pull/206903)
Miscellaneous changes
With this commit we remove the namespaces that are not used in the cdfi document. Steps: - Create an invoice and send the edi document - Look at the xml -> namespace `xmlns:cce20="http://www.sat.gob.mx/ComercioExterior20"` is included but unused opw-4493568 Forward-Port-Of: odoo/enterprise#83838
Original PR description
With this commit we remove the namespaces that are not used in the cdfi document. Steps: - Create an invoice and send the edi document - Look at the xml -> namespace `xmlns:cce20="http://www.sat.gob.mx/ComercioExterior20"` is included but unused opw-4493568 Forward-Port-Of: odoo/enterprise#83838
Avoids unnecessary `/sign/sign_request_items` call after refusal by: - Adding `isRefused` flag to skip RPC when token is invalidated - Preserves normal flow for successful signatures **Benefits:** Reduces network traffic + server load in refusal scenarios. task-4642104 Forward-Port-Of: odoo/enterprise#81248
Original PR description
Avoids unnecessary `/sign/sign_request_items` call after refusal by: - Adding `isRefused` flag to skip RPC when token is invalidated - Preserves normal flow for successful signatures **Benefits:** Reduces network traffic + server load in refusal scenarios. task-4642104 Forward-Port-Of: odoo/enterprise#81248
Change VAT in invoice report if the invoice is set as cfdi to public to use a generic vat for both national and international clients to have more coherence with the xml that is generated for the invoice. task-4588311 Forward-Port-Of: odoo/enterprise#83771 Forward-Port-Of: odoo/enterprise#79775
Original PR description
Change VAT in invoice report if the invoice is set as cfdi to public to use a generic vat for both national and international clients to have more coherence with the xml that is generated for the invoice. task-4588311 Forward-Port-Of: odoo/enterprise#83771 Forward-Port-Of: odoo/enterprise#79775
Creating an SO requires either sudo or some sort of SO group which is not set by default. In this case it looks like sudo-ing for creation during setup then unsudo-ing works fine. So do that to avoid over-accessing. https://runbot.odoo.com/odoo/error/163657 Forward-Port-Of: odoo/enterprise#84272
Original PR description
Creating an SO requires either sudo or some sort of SO group which is not set by default. In this case it looks like sudo-ing for creation during setup then unsudo-ing works fine. So do that to avoid over-accessing. https://runbot.odoo.com/odoo/error/163657 Forward-Port-Of: odoo/enterprise#84272
In this commit: === - Fixed a traceback that occurred during menu synchronization caused by multiple product.template.attribute.value (PTAV) records found, where only one was expected (singleton error). - The issue was due to having both active and inactive PTAV records linked to a product. task-4753173 Forward-Port-Of: odoo/enterprise#84211 Forward-Port-Of: odoo/enterprise#84127
Original PR description
In this commit: === - Fixed a traceback that occurred during menu synchronization caused by multiple product.template.attribute.value (PTAV) records found, where only one was expected (singleton error). - The issue was due to having both active and inactive PTAV records linked to a product. task-4753173 Forward-Port-Of: odoo/enterprise#84211 Forward-Port-Of: odoo/enterprise#84127
The pos.order form view removed the refund button for the inherited view. This can cause issues if other modules depend on that button to add to the arch, so making it invisible would still make the element accessible by xpath. ci error https://runbot.odoo.com/runbot/build/78974416 Forward-Port-Of: odoo/enterprise#84118 Forward-Port-Of: odoo/enterprise#84030
Original PR description
The pos.order form view removed the refund button for the inherited view. This can cause issues if other modules depend on that button to add to the arch, so making it invisible would still make the element accessible by xpath. ci error https://runbot.odoo.com/runbot/build/78974416 Forward-Port-Of: odoo/enterprise#84118 Forward-Port-Of: odoo/enterprise#84030
Removed extra spaces in front of the day and month in DATE function. Task: 4725023 Forward-Port-Of: odoo/enterprise#84121
Original PR description
Removed extra spaces in front of the day and month in DATE function. Task: 4725023 Forward-Port-Of: odoo/enterprise#84121
In this commit: - Updated Table 12 HSN Summary to classify HSN data separately for B2B and B2C as per the latest GST advisory. - Previously, all HSN summary data was pushed into Table 12 without distinction. - Now, HSN summary is categorized into B2B and B2C for accurate reporting. Task ID: 4465102 Forward-Port-Of: odoo/enterprise#84218 Forward-Port-Of: odoo/enterprise#80738
Original PR description
In this commit: - Updated Table 12 HSN Summary to classify HSN data separately for B2B and B2C as per the latest GST advisory. - Previously, all HSN summary data was pushed into Table 12 without distinction. - Now, HSN summary is categorized into B2B and B2C for accurate reporting. Task ID: 4465102 Forward-Port-Of: odoo/enterprise#84218 Forward-Port-Of: odoo/enterprise#80738
In cc759094a32e413cb1b71cbbe7be9dc85ded819f, the follow-up report generation was moved from `_send_email` to `execute_followup`, which is only called during manual follow-up processing. As a result, the report was missing when follow-ups were triggered by the cron. This commit moves the report generation logic to `_execute_followup_partner`, which is called in both manual and automatic (cron) cases. Also, patched `_run_wkhtmltopdf` in `TestAccountFollowupReports` to prevent tests from han
Original PR description
In cc759094a32e413cb1b71cbbe7be9dc85ded819f, the follow-up report generation was moved from `_send_email` to `execute_followup`, which is only called during manual follow-up processing. As a result, the report was missing when follow-ups were triggered by the cron. This commit moves the report generation logic to `_execute_followup_partner`, which is called in both manual and automatic (cron) cases. Also, patched `_run_wkhtmltopdf` in `TestAccountFollowupReports` to prevent tests from hanging, since PDF generation requires multiple workers and tests run with only one. task-4752110 Forward-Port-Of: odoo/enterprise#84114
Currently, an error is raised when the system tries to load non-existent XML files via a scheduled action. **Steps to produce:** - Install `l10n_lu_hr_payroll` module. - Navigate to `Settings > Technical > Scheduled Actions`. - Run action manually for **Payroll: Update data**. - Observe the error. `ValueError: FileNotFoundError('File not found: l10n_lu_hr_payroll/data/hr_salary_rule_data.xml') while evaluating 'model._update_payroll_data()'` Here, `_get_data_files_to_update` method
Original PR description
Currently, an error is raised when the system tries to load non-existent XML files via a scheduled action.
**Steps to produce:**
- Install `l10n_lu_hr_payroll` module.
- Navigate to `Settings > Technical > Scheduled Actions`.
- Run action manually for **Payroll: Update data**.
- Observe the error.
`ValueError: FileNotFoundError('File not found: l10n_lu_hr_payroll/data/hr_salary_rule_data.xml') while evaluating 'model._update_payroll_data()'`
Here, `_get_data_files_to_update` method at [1] attempts to load the `hr_salary_rule_data.xml` and `hr_gratification_rule_data.xml` files, which are not present in the codebase.
[1] - https://github.com/odoo/enterprise/blob/809fda39b439edf6259ade445e396e722c1bb53a/l10n_lu_hr_payroll/models/hr_payslip.py#L219-L220
This commit ensures the removal of invalid file references to prevent errors when executing the scheduled action.
Sentry - 6316151728
Forward-Port-Of: odoo/enterprise#83968
Forward-Port-Of: odoo/enterprise#83893Steps to reproduce: - starting planning_test_tour => error raised Source: - https://github.com/odoo/enterprise/pull/69888 introduced a new method _get_non_working_days_bounds which computes user_tz but the value can be False and also not coherent with user_tz computed in _calculate_start_end_dates (method from wich this new method is called) Fix: user_tz is computed the same way as its computed in the original method, the code is duplicated as signature cannot be changed in stable. For
Original PR description
Steps to reproduce: - starting planning_test_tour => error raised Source: - https://github.com/odoo/enterprise/pull/69888 introduced a new method _get_non_working_days_bounds which computes user_tz but the value can be False and also not coherent with user_tz computed in _calculate_start_end_dates (method from wich this new method is called) Fix: user_tz is computed the same way as its computed in the original method, the code is duplicated as signature cannot be changed in stable. Forward-Port-Of: odoo/enterprise#83955 Forward-Port-Of: odoo/enterprise#83926
**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form for a helpdesk team. - Create a menu item for the website, using a URL starting with helpdesk, e.g. `/helpdesk-123-test` - This menu is always invisible to the public user. **Cause** This issue was fixed in previous versions, but it appears the duplicated `_compute_visible` code present
Original PR description
**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form…
**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form for a helpdesk team. - Create a menu item for the website, using a URL starting with helpdesk, e.g. `/helpdesk-123-test` - This menu is always invisible to the public user. **Cause** This issue was fixed in previous versions, but it appears the duplicated `_compute_visible` code present in `website.py` was not deleted in forward ports of the fix (see enterprise PR 63105). https://github.com/odoo/enterprise/blob/b320390d23d3f009beb809e0334c8fa61c44d824/website_helpdesk/models/website.py#L24-L26 As a result, the menu item starting with `/helpdesk` is matched as a helpdesk menu, but will logically not be part of the helpdesk published menus: https://github.com/odoo/enterprise/blob/b320390d23d3f009beb809e0334c8fa61c44d824/website_helpdesk/models/website.py#L30-L32 opw-4560291 Forward-Port-Of: odoo/enterprise#83863 Forward-Port-Of: odoo/enterprise#82824
Updated test case `test_searching_lot_gs1`. This commit updates the test_searching_lot_gs1 test case to include an assertion ensuring that no lot is returned while searching. Related Community PR: https://github.com/odoo/odoo/pull/206268 Sentry:6544673924 OPW: 4725056 Forward-Port-Of: odoo/enterprise#83920
Original PR description
Updated test case `test_searching_lot_gs1`. This commit updates the test_searching_lot_gs1 test case to include an assertion ensuring that no lot is returned while searching. Related Community PR: https://github.com/odoo/odoo/pull/206268 Sentry:6544673924 OPW: 4725056 Forward-Port-Of: odoo/enterprise#83920
`TestPayslipValidation.setUpClass` tries to create an `hr.leave.type` but that requires hr admin access. So add that. Issue likely became visible from the removal of demo data, though it only popped up on April 1st instead of March 27th or whenever the demo data change was merged. https://runbot.odoo.com/odoo/error/162257 Forward-Port-Of: odoo/enterprise#83667 Forward-Port-Of: odoo/enterprise#83665
Original PR description
`TestPayslipValidation.setUpClass` tries to create an `hr.leave.type` but that requires hr admin access. So add that. Issue likely became visible from the removal of demo data, though it only popped up on April 1st instead of March 27th or whenever the demo data change was merged. https://runbot.odoo.com/odoo/error/162257 Forward-Port-Of: odoo/enterprise#83667 Forward-Port-Of: odoo/enterprise#83665
These tests create sale orders, but `self.env.user` does not necessarily have the right to create one by default. https://runbot.odoo.com/odoo/error/163635 Forward-Port-Of: odoo/enterprise#83676 Forward-Port-Of: odoo/enterprise#83672
Original PR description
These tests create sale orders, but `self.env.user` does not necessarily have the right to create one by default. https://runbot.odoo.com/odoo/error/163635 Forward-Port-Of: odoo/enterprise#83676 Forward-Port-Of: odoo/enterprise#83672