Daily updates from Odoo
Friday, April 4, 2025
47 changes
21 changes
Enhancements to existing features
Bank reconciliation logic was reorganized to handle recalculations more safely when liquidity lines are reloaded. This reduces the risk of inconsistent statement handling and supports smoother accounting workflows, including Mexican electronic invoicing scenarios.
Original PR description
…ity_line() as a context manager Due to the cache invalidation that occurs in order to force the recomputation of computed fields, we need to track the statement line in the context. Previously, this was managed manually in a stable-version fix: https://github.com/odoo/enterprise/commit/46f838403c8d60760a5b37cb5fe8d052d2307999 This commit improves the approach by refactoring _action_reload_liquidity_line() into a context manager. no-task
Odoo Studio users can now edit placeholder text on multi-line text fields, bringing this option in line with other field types. This helps teams add clearer guidance directly in forms without custom development.
Original PR description
This commit adds the ability to edit the placeholder attribute from studio on multi-lines text fields. It was only supported on most other types of fields, and the placeholder attribute is supported for a while. A test has been added as well.
The Planning calendar now avoids showing the Edit button when a user does not have permission or ability to edit the item. This makes the calendar popover clearer and prevents users from trying actions that are not available to them.
Original PR description
This commit is the counterpart of odoo/odoo#204734 where the buttons logic inside the popover footer of the calendar view has been slightly reworked. task-4606641
This update adds automated checks for the Documents drag-and-drop experience, helping ensure the feature keeps working as expected. It also preserves the helpful shortcut indicator when users drag documents over the search panel while holding Ctrl, reducing confusion during file organization.
Original PR description
Add some unit tests for the new Drag and Drop feature using Hoot. Task-4681175
The appraisal form now shows helpful tooltip guidance for employee and manager feedback visibility toggles. This makes it easier for users to understand what publishing each type of feedback does before changing visibility settings.
Original PR description
The `help` parameter is used in the `employee_feedback_published` and `manager_feedback_published` fields to add a tooltip. Labels are used to display the help message for each field. task-4558176
Resolved issues and error corrections
The VoIP module now avoids asking for a field that can already be determined automatically. This reduces friction for related workflows and makes testing or dependent customizations easier without changing the core user experience.
Original PR description
This is highly annoying for tests and dependant modules, while this field is used in 3 flows and can be easily deduced.
Code cleanup and technical improvements
Sales commission achievement features have been moved back into the main Sales Commission module, replacing the temporary linked achievement module. This reduces module complexity while keeping the same commission tracking capabilities available in the standard sales commission flow.
Original PR description
…_achievement Since https://github.com/odoo/enterprise/pull/77483 a technical module introduced to do breaking changes in stable: sale_commission_linked_achievement. This commit move the functionallities back in sale_commission. taskid: 4630052
The online appointment website component was reworked to use Odoo's newer interaction approach. This keeps the feature aligned with the platform's current architecture while preserving the customer-facing appointment booking experience.
Original PR description
task-4367641
This change reorganizes how spreadsheet filter matching is handled behind the scenes. It removes a shared global mechanism in favor of more localized handling, reducing maintenance risk without changing expected user behavior.
Original PR description
Task: 4684668
Miscellaneous changes
Description ------------ Fix a performance issue in the partner search functionality used in the sharing widget. The problem was related to the PostgreSQL query planner choosing a suboptimal execution plan when using a limit of 4 records. With a very low limit of 4, PostgreSQL would choose to perform an index scan on the `complete_name` index instead of using the more efficient trigram indexes. This resulted in high I/O operations as it traversed the index from A until finding matches, caus
Original PR description
Description ------------ Fix a performance issue in the partner search functionality used in the sharing widget. The problem was related to the PostgreSQL query planner choosing a suboptimal…
Description ------------ Fix a performance issue in the partner search functionality used in the sharing widget. The problem was related to the PostgreSQL query planner choosing a suboptimal execution plan when using a limit of 4 records. With a very low limit of 4, PostgreSQL would choose to perform an index scan on the `complete_name` index instead of using the more efficient trigram indexes. This resulted in high I/O operations as it traversed the index from A until finding matches, causing significant performance degradation. The fix simply increases the limit to 8, consistent with other `name_search` operations, ensuring the query planner consistently chooses the trigram index path regardless of the search term. Benchmark ---------- On a database with over 8 digits count of partners, a non selective search of a partner (5 chars) took: | Before | After | Speedup | |--------|-------|---------| | 27.4s | 42ms | 652x | Reference --------- task-4686893 Forward-Port-Of: odoo/enterprise#82680
Fixing the tour that has been introduce here https://github.com/odoo/enterprise/pull/75658/commits/c2d18cea5db278b5a3203c4d3646411fc9bbd450 runbot-110627 Forward-Port-Of: odoo/enterprise#81776
Original PR description
Fixing the tour that has been introduce here https://github.com/odoo/enterprise/pull/75658/commits/c2d18cea5db278b5a3203c4d3646411fc9bbd450 runbot-110627 Forward-Port-Of: odoo/enterprise#81776
Versions -------- - saas-17.4+ Price already hidden in 17.0 & earlier. Steps ----- 1. Set website to prevent sale of zero-priced products; 2. create a zero-priced pricelist; 3. create a rental product; 4. set a rental price of $0 on the zero-priced pricelist; 5. go to rental product page on website. Issue ----- It displays "$0.00/day" above the "Not Available for Sale" text. Cause ----- The rental price element doesn't check whether zero-priced products should be made ava
Original PR description
Versions -------- - saas-17.4+ Price already hidden in 17.0 & earlier. Steps ----- 1. Set website to prevent sale of zero-priced products; 2. create a zero-priced pricelist; 3. create a rental product; 4. set a rental price of $0 on the zero-priced pricelist; 5. go to rental product page on website. Issue ----- It displays "$0.00/day" above the "Not Available for Sale" text. Cause ----- The rental price element doesn't check whether zero-priced products should be made available for sale. Solution -------- If the rental price is zero, and the website prevents sale of zero-priced products, hide the rental price element. We can use `combination_info['prevent_zero_price_sale']` for this thanks to commit 1f827ac1fad opw-4643155 Forward-Port-Of: odoo/enterprise#82849 Forward-Port-Of: odoo/enterprise#82535
* stock{,_barcode, _barcode_quality_control}, quality_control ### Issue: Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the bu
Original PR description
* stock{,_barcode, _barcode_quality_control}, quality_control ### Issue: Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a…
* stock{,_barcode, _barcode_quality_control}, quality_control
### Issue:
Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.
The above issue can be triggered in many situations. Here are the two major ones:
### Use case I:
Creating a delivery or an internal transfer on the fly from the barcode app.
### Steps to reproduce:
- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.
### Cause of the issue:
The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133
### Use case II:
Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailed operations.
### Steps to reproduce:
- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.
### Cause of the issue:
For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.
### Fix:
We ensure the creation of quality checks for moves that end up being created but will never be confirmed.
### Technical limitation:
Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.
Community: https://github.com/odoo/odoo/pull/202725
opw-4480104
Forward-Port-Of: odoo/enterprise#82643
Forward-Port-Of: odoo/enterprise#81850Pytz raises a `NonExistentTimeError` or an `AmbiguousTimeError` when trying to get the offset of a non localized datetime during the daylight saving changing time. Remark: the `_is_customer_in_the_same_timezone` method name should be changed in master as it does the complete opposite. runbot error 162039 Fix courtesy of @Xavier-Do Forward-Port-Of: odoo/enterprise#82810
Original PR description
Pytz raises a `NonExistentTimeError` or an `AmbiguousTimeError` when trying to get the offset of a non localized datetime during the daylight saving changing time. Remark: the `_is_customer_in_the_same_timezone` method name should be changed in master as it does the complete opposite. runbot error 162039 Fix courtesy of @Xavier-Do Forward-Port-Of: odoo/enterprise#82810
This commit fixes the overlapping between the dialog and file viewer due to a combination of the z-index value set by the .modal class and the .fixed-top utility class. This is the counterpart of the related community change in FileViewer. Forward-Port-Of: odoo/enterprise#82186
Original PR description
This commit fixes the overlapping between the dialog and file viewer due to a combination of the z-index value set by the .modal class and the .fixed-top utility class. This is the counterpart of the related community change in FileViewer. Forward-Port-Of: odoo/enterprise#82186
Forward-Port-Of: odoo/enterprise#72380
Original PR description
Forward-Port-Of: odoo/enterprise#72380
- l10n_de_pos_res_cert/static/tests/tours/fiskaly_tour.js Add wait request steps (to fix undeterministic behavior). - mrp_workorder/tests/test_shopfloor.py Add a step_delay=500. This step delay will be removed from codebase soon. This is an intermediate fix. - website_sale_renting/static/tests/tours/website_sale_renting_select... Avoid the usage of datepicker interface that causes problems for now in tours. Forward-Port-Of: odoo/enterprise#82554 Forward-Port-Of: odoo/enterprise#82524
Original PR description
- l10n_de_pos_res_cert/static/tests/tours/fiskaly_tour.js Add wait request steps (to fix undeterministic behavior). - mrp_workorder/tests/test_shopfloor.py Add a step_delay=500. This step delay will be removed from codebase soon. This is an intermediate fix. - website_sale_renting/static/tests/tours/website_sale_renting_select... Avoid the usage of datepicker interface that causes problems for now in tours. Forward-Port-Of: odoo/enterprise#82554 Forward-Port-Of: odoo/enterprise#82524
Dynamically use the latest `html_migrations` version in the `knowledge_history_tour` to avoid having to update the test every time a new html version is deployed. task-4640490 Forward-Port-Of: odoo/enterprise#82817 Forward-Port-Of: odoo/enterprise#81344
Original PR description
Dynamically use the latest `html_migrations` version in the `knowledge_history_tour` to avoid having to update the test every time a new html version is deployed. task-4640490 Forward-Port-Of: odoo/enterprise#82817 Forward-Port-Of: odoo/enterprise#81344
Steps to reproduce the bug: - Create a storable product “P1”: - Create a BoM - Go back to the product form and create an ECO: - Apply on: “Bill of Materials” - The created BoM will be selected automatically. - Save. - Return to the product form. - The ECO count in the smart button is 1. - Click on it. Problem: No ECO is displayed because the domain filters only ECOs applied to the product: https://github.com/odoo/enterprise/blob/ec6b4717f49ccd5b651be80aed21494ed
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Create a BoM - Go back to the product form and create an ECO: - Apply on: “Bill of Materials” - The created BoM will be selected…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Create a BoM
- Go back to the product form and create an ECO:
- Apply on: “Bill of Materials”
- The created BoM will be selected automatically.
- Save.
- Return to the product form.
- The ECO count in the smart button is 1.
- Click on it.
Problem:
No ECO is displayed because the domain filters only ECOs applied to the product:
https://github.com/odoo/enterprise/blob/ec6b4717f49ccd5b651be80aed21494ed500f580/mrp_plm/models/product.py#L17-L20
Solution:
only ECOs of type "Product" should be counted in the product form.
Issue 2:
- Try updating the "Apply on" field of the ECO to “Product.”
Problem:
The "Bill of Materials" field becomes invisible but is not cleared. As a result, when counting the number of ECOs linked to the BoM, the count will be incorrect.
https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48
opw-4653598
Forward-Port-Of: odoo/enterprise#82576[FIX] hr_appraisal: prevent TypeError for raw record data The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None. This occurred because the code attempted to create a set from the None value directly. Steps to reproduce: ------------------- * Open Appraisal app and click on an employee's card * Activate debug mode * From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+ > Observation: Fil
Original PR description
[FIX] hr_appraisal: prevent TypeError for raw record data The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None. This…
[FIX] hr_appraisal: prevent TypeError for raw record data
The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None.
This occurred because the code attempted to create a set from the None value directly.
Steps to reproduce:
-------------------
* Open Appraisal app and click on an employee's card
* Activate debug mode
* From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+
> Observation:
File "/data/build/enterprise/hr_appraisal/models/hr_appraisal.py", line 539, in read
check_notes = set(fields) & {'note', 'assessment_note'}
^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable
Why the fix:
------------
set() requires an iterable. By adding this condition, we avoid iterating over NoneType. This maintains the intended default functionality while preventing the crash.
opw-4631142
Forward-Port-Of: odoo/enterprise#82711
Forward-Port-Of: odoo/enterprise#81758Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user. **Steps to reproduce:** - Install the `account` and `l10n_hr_payroll` modules. - Navigate to the **Vendors** view and delete the `Register for State Labour Welfare Fund Deduction` record. - In **Scheduled Actions**, manually execute `Payroll: Update data`. - Observer the backend error. **Error:** `ValueError - ParseError('while parsing /home/odoo/src/
Original PR description
Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user. **Steps to reproduce:** - Install the `account` and…
Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user.
**Steps to reproduce:**
- Install the `account` and `l10n_hr_payroll` modules.
- Navigate to the **Vendors** view and delete the `Register for State Labour Welfare Fund Deduction` record.
- In **Scheduled Actions**, manually execute `Payroll: Update data`.
- Observer the backend error.
**Error:**
`ValueError - ParseError('while parsing /home/odoo/src/enterprise/saas-18.2/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data...`
The error occurs because the method at [1] attempts to load the `hr_salary_rule_ind_emp_data.xml` file that references a deleted `partner_id` [2], leading to a parsing error.
[1] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/models/hr_payslip.py#L44-L54
[2] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data.xml#L364
This commit ensures that `res_partner_data.xml` is loaded before `hr_salary_rule_ind_emp_data.xml`, preventing errors due to missing partners.
Sentry - 6429993371
Forward-Port-Of: odoo/enterprise#8191726 changes
Resolved issues and error corrections
This update removes an unnecessary warning shown when postponing replenishment rules created by the superuser. It reduces confusion for inventory users while preserving the corrected behavior from a previous fix.
Original PR description
Thanks to this fix: https://github.com/odoo/odoo/commit/8ad00b8ee6340dba1e027bb27a8f05489b4253a9 we can revert this one: https://github.com/odoo/odoo/pull/200777/commits/237feaee5fcf1e166bf39e78e8839b191f92c306 The pot file already deleted: https://github.com/odoo/odoo/commit/0361582de7c28bb4847a9c4dbaa712b67f4ca577#diff-4424c1629e21b466bb7af6ab0cb3a674d1bf3e75d93e7e76cf77870dc5bcc853R8693-L9114 opw-4628611
Odoo now safely ignores translation-control markers in web view templates during browser-side compilation. This prevents form and kanban views from failing when those markers are present, improving reliability without changing what users see.
Original PR description
Form and kanban view archs are compiled into owl templates. Those archs are translated server-side, before being sent to the client. They can contain `t-translation` directives (typically ="off" to…
Form and kanban view archs are compiled into owl templates. Those archs are translated server-side, before being sent to the client. They can contain `t-translation` directives (typically ="off" to disable translations). This tells the view processing in python not to translate the subtree. In the js compilers, that attribute is listed among the tolerated attributes for kanban archs, but not for forms. However, the cases are similar, so their should be not differences between the two. Moreover, since [1], compiled templates are wrapped into a ```xml <t t-translation="off"/> ``` node, s.t. terms aren't translated twice (once in python, and once in js, by owl). Instead of tolerating the `t-translation` directive in form view, this commit ignores it in all view compilers. This directive indeed makes sense, so it is valid to use it in kanban and form archs (then used by the view processing in python). But the view compilers in js must ignore it, so we simply remove it. [1] odoo/odoo#158759 Fixes runbot error-134670 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The editor now correctly enables AI and translation actions when users select normal text, even if the surrounding content includes protected elements such as a signature. This prevents valid selections in the email composer from being blocked unnecessarily.
Original PR description
**Problem**: If the selection does not include unsplittable nodes but the `commonAncestorContainer` contains one, the AI/Translation button will be disabled. **Solution**: Instead of relying on `commonAncestorContainer`, check only the traversed nodes to determine if the selection is valid. **Steps to reproduce**: 1. Open Full Composer with a signature. 2. Add text. 3. Select only the text you added. - **Issue**: The AI/Translation button is disabled. **opw-4649819** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
PayPal payment requests now leave out the company email field when no email is set, instead of sending an empty value that PayPal rejects. This helps avoid confusing payment integration failures for businesses with incomplete company contact details.
Original PR description
Since paypal does not allow empty fields to be sent, its better to add email only if it exists. Some customers find it confusing that paypal integration fails without proper feedback that the issue comes from the empty email in their company form. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents accounting tax updates from failing when expected repartition line details are absent. Instead of triggering an error, the system now skips that update safely, improving stability for affected accounting configurations.
Original PR description
When there are no repartition_lines we should skip updating them because it will cause IndexError: list index out of range. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Gantt view compiler now safely accepts older translation markers while ignoring them during processing. This prevents unnecessary errors and keeps behavior aligned with the broader platform change, with no expected visible impact for users.
Original PR description
This commit is the counterpart of odoo/odoo#204833 which ignores the `t-translation` attributes in view compilers. As a consequence, this directive should no longer be in the list of accepted directives.
This update corrects an automated website shop test for subscription product variants. It helps ensure the checkout flow for variant-based subscription products is reliably validated, reducing the chance of unnoticed issues reaching users.
Original PR description
Fixing the tour that has been introduce here https://github.com/odoo/enterprise/pull/75658/commits/c2d18cea5db278b5a3203c4d3646411fc9bbd450 runbot-110627
Miscellaneous changes
Steps to reproduce ================== - Use a mobile viewport - Go to any list/kanban view - Open a record - Use the pager to switch to the next record => "1 / x" is displayed where x is the total amount of records - Click next => "2 / x" is displayed - Click previous => "3 / x" is displayed The pager is displaying the values before the switch has been made. Cause of the issue ================== When sending `this.value` on the `PAGER_UPDATED_EVENT` bus, the props have not bee
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Go to any list/kanban view - Open a record - Use the pager to switch to the next record => "1 / x" is displayed where x is the total amount of records - Click next => "2 / x" is displayed - Click previous => "3 / x" is displayed The pager is displaying the values before the switch has been made. Cause of the issue ================== When sending `this.value` on the `PAGER_UPDATED_EVENT` bus, the props have not been updated yet. This means that we send the previous value. Solution ======== We send the event once either the offset, limit or total props have been updated. opw-4666878 Forward-Port-Of: odoo/odoo#204168
Steps to reproduce: - Activate developer mode - Install website Google Maps module - Navigate to Website in edit mode - Drop the google maps snippet - Enter a correct API key - The dialog closes but the snippet is removed This is due to a promise not resolved when confirming the API key. Forward-Port-Of: odoo/odoo#204139
Original PR description
Steps to reproduce: - Activate developer mode - Install website Google Maps module - Navigate to Website in edit mode - Drop the google maps snippet - Enter a correct API key - The dialog closes but the snippet is removed This is due to a promise not resolved when confirming the API key. Forward-Port-Of: odoo/odoo#204139
Versions -------- - 16.0+ Steps ----- 1. Have a payment token saved via Flutterwave; 2. use token to pay for an order. Issue ----- Error: Provide a valid redirect url Cause ----- Flutterwave now mandates authorization for tokenized flows. They provide an authorization url for this, and expect to receive a redirect url value to return to afterwards. Solution -------- Solution partially based on the Ogone redirect flow added in 0ed92bcc9791 The authorization url is provid
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a payment token saved via Flutterwave; 2. use token to pay for an order. Issue ----- Error: Provide a valid redirect url Cause ----- Flutterwave now mandates authorization for tokenized flows. They provide an authorization url for this, and expect to receive a redirect url value to return to afterwards. Solution -------- Solution partially based on the Ogone redirect flow added in 0ed92bcc9791 The authorization url is provided in the notification data. Store this in the `provider_reference` field if the transaction is pending. When processing the pending transaction, initiate a redirect flow, which redirects the user to the authorization url. opw-4669110 Forward-Port-Of: odoo/odoo#204599 Forward-Port-Of: odoo/odoo#204322
In a form snippet, enabling the "Description" option for a field and then undoing this action caused the field to lose its styling and available customization options. Steps to reproduce: - Enter Edit mode. - Add a Form snippet. - Select any field (e.g., "Your Name"). - Enable the "Description" option from the customization panel. - Undo the action (Ctrl+Z). This results in the field losing its padding and the "Description" and other options being removed. Cause: A redundant line
Original PR description
In a form snippet, enabling the "Description" option for a field and then undoing this action caused the field to lose its styling and available customization options. Steps to reproduce: - Enter Edit mode. - Add a Form snippet. - Select any field (e.g., "Your Name"). - Enable the "Description" option from the customization panel. - Undo the action (Ctrl+Z). This results in the field losing its padding and the "Description" and other options being removed. Cause: A redundant line of code was adding an extra step in the mutation history. When undoing, this extra step caused the removal of essential classes from the field, leading to the loss of styling and options. Fix: Removed the redundant line to ensure undoing the action correctly restores the previous state without affecting the field’s styling or customization options. task-4013551 Forward-Port-Of: odoo/odoo#179858
Steps to reproduce the bug: - Create a storable product, that is tracked by serial number - Add to in Hand the product and set the serial number to it - Create a quotation of this product and confirm to be a sale order - Open a pos session, and select quotations and orders from pos - Select the sales order created and settle the order - The order line will be imported without asking if serial number can be linked Issue: The function settleOrder in pos_sale/pos_store.js reads the sales
Original PR description
Steps to reproduce the bug: - Create a storable product, that is tracked by serial number - Add to in Hand the product and set the serial number to it - Create a quotation of this product and confirm…
Steps to reproduce the bug: - Create a storable product, that is tracked by serial number - Add to in Hand the product and set the serial number to it - Create a quotation of this product and confirm to be a sale order - Open a pos session, and select quotations and orders from pos - Select the sales order created and settle the order - The order line will be imported without asking if serial number can be linked Issue: The function settleOrder in pos_sale/pos_store.js reads the sales order using this.data.read, this will read the sales order with the sale order line but without the information of the lot numbers and more info. These informations are returned in a read_converted function on sale.order.line inherited model on pos_sale, and this function is not used to read the sale order lines, hence no information related to the lots and the pop up that asks if the lot number may be linked will not appear anymore. opw-4591887 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#201400
Purpose ======= The Indian government updated its UOM code https://einvoice1.gst.gov.in/Others/MasterCodes (select UQC Codes) So In this commit, I have updated `l10n_in_code` in UOM Mili Meter and Square Foot. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204598
Original PR description
Purpose ======= The Indian government updated its UOM code https://einvoice1.gst.gov.in/Others/MasterCodes (select UQC Codes) So In this commit, I have updated `l10n_in_code` in UOM Mili Meter and Square Foot. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204598
Steps to reproduce the issue: - Enter Website edit mode. - Click on the "Theme" tab. - Pick a black color for the website background (4th color button). - Click on a link in the website navbar to make the link popover appear. - Bug: The popover background is black, and its buttons are not visible as they are also black. Bug introduced by this commit [1], where popover colors were updated to match the website's theme. The goal was to align popovers, such as the one for the e-commerce ca
Original PR description
Steps to reproduce the issue: - Enter Website edit mode. - Click on the "Theme" tab. - Pick a black color for the website background (4th color button). - Click on a link in the website navbar to…
Steps to reproduce the issue: - Enter Website edit mode. - Click on the "Theme" tab. - Pick a black color for the website background (4th color button). - Click on a link in the website navbar to make the link popover appear. - Bug: The popover background is black, and its buttons are not visible as they are also black. Bug introduced by this commit [1], where popover colors were updated to match the website's theme. The goal was to align popovers, such as the one for the e-commerce cart button, with the theme colors. However, the change unfortunately also affected the link editing popover, which should remain neutral as it is part of the interface elements. [1]: https://github.com/odoo/odoo/commit/0d96be06faf8aad1a92183bd2b6371253980c7e6 task-4422810 | Before | After | | ------------- | ------------- | |  |  | Forward-Port-Of: odoo/odoo#203958
Commit 2afc30a introduced reward validation before payment, due to this if promotion expired during payment step during checkout, error informing that promotion was expired was thrown, but user was not able to do anything about. Info about refreshing page has been added. opw-4573640 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.co
Original PR description
Commit 2afc30a introduced reward validation before payment, due to this if promotion expired during payment step during checkout, error informing that promotion was expired was thrown, but user was not able to do anything about. Info about refreshing page has been added. opw-4573640 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#203564 Forward-Port-Of: odoo/odoo#203395
One issue remained for the 'Multiple choice: multiple answers allowed' option in this task: https://www.odoo.com/odoo/project.task/4663115 Task- 4663115 Forward-Port-Of: odoo/odoo#204603
Original PR description
One issue remained for the 'Multiple choice: multiple answers allowed' option in this task: https://www.odoo.com/odoo/project.task/4663115 Task- 4663115 Forward-Port-Of: odoo/odoo#204603
Currently, a traceback occurs when the user tries to send multiple invoices to sign in the list view, which includes draft invoices. Error:- ``` TypeError: the JSON object must be str, bytes or bytearray, not bool ``` Cause:- When the user resets an Egyptian invoice to draft status, the value of `l10n_eg_eta_json_doc_id` is set to False as seen in the following line https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/accoun
Original PR description
Currently, a traceback occurs when the user tries to send multiple invoices to sign in the list view, which includes draft invoices. Error:- ``` TypeError: the JSON object must be str, bytes or…
Currently, a traceback occurs when the user tries to send multiple invoices to sign in the list view, which includes draft invoices. Error:- ``` TypeError: the JSON object must be str, bytes or bytearray, not bool ``` Cause:- When the user resets an Egyptian invoice to draft status, the value of `l10n_eg_eta_json_doc_id` is set to False as seen in the following line https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/account_move.py#L66-L67 After that when the user attempts to sign the document through the list view, it leads to the traceback. This happens because we are passing self instead of the invoices to the method `action_sign_invoices`. https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/account_move.py#L73 https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/account_move.py#L106 As a result, self contains all draft invoices (if selected by the user), leading to the traceback since the value of l10n_eg_eta_json_doc_id is False for the reset draft invoice. https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/eta_thumb_drive.py#L34-L35 sentry-6448238266 Forward-Port-Of: odoo/odoo#203064
The domain was syntactically wrong. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204532
Original PR description
The domain was syntactically wrong. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204532
Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the app
Original PR description
Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users. opw-3841495 Forward-Port-Of: odoo/odoo#178142
Currently, if a serialization error occurs right after sending an invoice to SDI, Odoo retries the submission. This causes issues as the move’s transaction ID will be updated to the second attempt, not the first. Additionally, SDI will detect a duplicate submission and return a "notificaScarto" status. Since only the second transaction ID is stored, Odoo will incorrectly display the invoice as rejected, even though the first submission was actually accepted. This fix ensures the move
Original PR description
Currently, if a serialization error occurs right after sending an invoice to SDI, Odoo retries the submission. This causes issues as the move’s transaction ID will be updated to the second attempt, not the first. Additionally, SDI will detect a duplicate submission and return a "notificaScarto" status. Since only the second transaction ID is stored, Odoo will incorrectly display the invoice as rejected, even though the first submission was actually accepted. This fix ensures the move is locked before sending to SDI, preventing this issue. opw-4643686 Forward-Port-Of: odoo/odoo#202693
**Current behavior:** `expected_component_cost_unit` does not accurately reflect the per unit price of a component depending on the manufacturing order's quantity ratios. **Expected behavior:** Accurate price per unit of component. **Steps to reproduce:** 1. Create a finished product with a BoM: * has a 1:1 comp to final ratio with quantities greater than 1 (e.g., 2 units component producing 2 units final) * make component cost $100 for sake of example * has a workorder with a workce
Original PR description
**Current behavior:** `expected_component_cost_unit` does not accurately reflect the per unit price of a component depending on the manufacturing order's quantity ratios. **Expected behavior:**…
**Current behavior:** `expected_component_cost_unit` does not accurately reflect the per unit price of a component depending on the manufacturing order's quantity ratios. **Expected behavior:** Accurate price per unit of component. **Steps to reproduce:** 1. Create a finished product with a BoM: * has a 1:1 comp to final ratio with quantities greater than 1 (e.g., 2 units component producing 2 units final) * make component cost $100 for sake of example * has a workorder with a workcenter with capacity sufficient to handle full BoM quantity producing (so 2 if used 2 -> 2 on BoM) 2. Create & process MO for finished product 3. Open the Production Analysis pivot view in the mrp app 4. In the `Measures` dropdown, check the `Expected Component Cost / Unit` field -> see that it shows `$50 / unit` instead of the expected `$100 / unit` **Cause of the issue:** This per unit value is divided by the BoM `product_qty` 2x: 1: https://github.com/odoo/enterprise/blob/ab86dadfcbe9662d611127546d9fb054759d325f/mrp_account_enterprise/reports/mrp_report.py#L184 2: https://github.com/odoo/enterprise/blob/ab86dadfcbe9662d611127546d9fb054759d325f/mrp_workorder_hr_account/report/mrp_report.py#L32 **Fix:** Remove the additional division operation in `mrp_workorder_hr_account` opw-4474710 Forward-Port-Of: odoo/enterprise#80560
Versions -------- - saas-17.4+ Price already hidden in 17.0 & earlier. Steps ----- 1. Set website to prevent sale of zero-priced products; 2. create a zero-priced pricelist; 3. create a rental product; 4. set a rental price of $0 on the zero-priced pricelist; 5. go to rental product page on website. Issue ----- It displays "$0.00/day" above the "Not Available for Sale" text. Cause ----- The rental price element doesn't check whether zero-priced products should be made ava
Original PR description
Versions -------- - saas-17.4+ Price already hidden in 17.0 & earlier. Steps ----- 1. Set website to prevent sale of zero-priced products; 2. create a zero-priced pricelist; 3. create a rental product; 4. set a rental price of $0 on the zero-priced pricelist; 5. go to rental product page on website. Issue ----- It displays "$0.00/day" above the "Not Available for Sale" text. Cause ----- The rental price element doesn't check whether zero-priced products should be made available for sale. Solution -------- If the rental price is zero, and the website prevents sale of zero-priced products, hide the rental price element. We can use `combination_info['prevent_zero_price_sale']` for this thanks to commit 1f827ac1fad opw-4643155 Forward-Port-Of: odoo/enterprise#82535
[FIX] hr_appraisal: prevent TypeError for raw record data The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None. This occurred because the code attempted to create a set from the None value directly. Steps to reproduce: ------------------- * Open Appraisal app and click on an employee's card * Activate debug mode * From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+ > Observation: Fil
Original PR description
[FIX] hr_appraisal: prevent TypeError for raw record data The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None. This…
[FIX] hr_appraisal: prevent TypeError for raw record data
The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None.
This occurred because the code attempted to create a set from the None value directly.
Steps to reproduce:
-------------------
* Open Appraisal app and click on an employee's card
* Activate debug mode
* From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+
> Observation:
File "/data/build/enterprise/hr_appraisal/models/hr_appraisal.py", line 539, in read
check_notes = set(fields) & {'note', 'assessment_note'}
^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable
Why the fix:
------------
set() requires an iterable. By adding this condition, we avoid iterating over NoneType. This maintains the intended default functionality while preventing the crash.
opw-4631142
Forward-Port-Of: odoo/enterprise#82711
Forward-Port-Of: odoo/enterprise#81758Pytz raises a `NonExistentTimeError` or an `AmbiguousTimeError` when trying to get the offset of a non localized datetime during the daylight saving changing time. Remark: the `_is_customer_in_the_same_timezone` method name should be changed in master as it does the complete opposite. runbot error 162039 Fix courtesy of @Xavier-Do Forward-Port-Of: odoo/enterprise#82810
Original PR description
Pytz raises a `NonExistentTimeError` or an `AmbiguousTimeError` when trying to get the offset of a non localized datetime during the daylight saving changing time. Remark: the `_is_customer_in_the_same_timezone` method name should be changed in master as it does the complete opposite. runbot error 162039 Fix courtesy of @Xavier-Do Forward-Port-Of: odoo/enterprise#82810
Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this
Original PR description
Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users. This change adds the necessary override in enterprise. See change in community here: https://github.com/odoo/odoo/pull/178142 opw-3841495 Forward-Port-Of: odoo/enterprise#69036
Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user. **Steps to reproduce:** - Install the `account` and `l10n_hr_payroll` modules. - Navigate to the **Vendors** view and delete the `Register for State Labour Welfare Fund Deduction` record. - In **Scheduled Actions**, manually execute `Payroll: Update data`. - Observer the backend error. **Error:** `ValueError - ParseError('while parsing /home/odoo/src/
Original PR description
Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user. **Steps to reproduce:** - Install the `account` and…
Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user.
**Steps to reproduce:**
- Install the `account` and `l10n_hr_payroll` modules.
- Navigate to the **Vendors** view and delete the `Register for State Labour Welfare Fund Deduction` record.
- In **Scheduled Actions**, manually execute `Payroll: Update data`.
- Observer the backend error.
**Error:**
`ValueError - ParseError('while parsing /home/odoo/src/enterprise/saas-18.2/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data...`
The error occurs because the method at [1] attempts to load the `hr_salary_rule_ind_emp_data.xml` file that references a deleted `partner_id` [2], leading to a parsing error.
[1] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/models/hr_payslip.py#L44-L54
[2] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data.xml#L364
This commit ensures that `res_partner_data.xml` is loaded before `hr_salary_rule_ind_emp_data.xml`, preventing errors due to missing partners.
Sentry - 6429993371
Forward-Port-Of: odoo/enterprise#81917