Daily updates from Odoo
Friday, February 7, 2025
43 changes · 18.0
New functionality added to Odoo
This change adds a custom quotation module that extends Odoo Sales quotation behavior. It introduces additional credit-limit validation so orders can be blocked when a customer's credit exposure exceeds the allowed limit, helping reduce financial risk before confirming sales.
Original PR description
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
Enhancements to existing features
Live chat chatbots can now include a step that ends the conversation immediately. This helps businesses control chatbot flows more clearly and prevents customers from receiving irrelevant follow-up messages after a session should be closed.
Original PR description
Purpose of this PR: Introduce a new 'end_session' step type to the chatbot. When the chatbot reaches this step, the live chat conversation will terminate, ensuring that any subsequent steps are not executed. task-id:4509331 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Users in the Invoicing & Banks role can now access customer statements and partner ledger reports from partner records. This fixes a permissions gap so the new invoicing role can use the expected reporting tools without needing broader accounting access.
Original PR description
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208
This fix restores behavior that prevents imported accounting lines from unexpectedly changing tax values. It helps businesses avoid incorrect tax handling when importing accounting data, reducing manual corrections and compliance risk.
Original PR description
[IMP] account - imported line shouldn't change tax Foward-port https://github.com/odoo/odoo/pull/193483 messed up and removed important code of https://github.com/odoo/odoo/pull/172787. This commit adds it back. task-4547597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing font size on underlined or strikethrough text now applies the sizing to the full styled text rather than only wrapping the inner characters. This keeps the underline or strikethrough visually aligned with the resized text for a more consistent editor experience.
Original PR description
**Problem**: When `u` or `s` tags are applied, changing the `font-size` wraps the text inside these tags instead of applying it to the tags themselves. For example, `a<u>b</u>c` → `a<u><font>b</font></u>c`, which results in an inconsistent appearance. **Solution**: Ensure that the `span` for font size is applied to the highest non-block ancestor to maintain proper styling. **Steps to Reproduce**: 1. Add text. 2. Apply underline. 3. Increase font size. 4. Observe that the underline remains the original size instead of scaling with the text. opw-3086072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale login flow now correctly returns from the screensaver without treating it as the prior screen. This prevents staff from getting stuck seeing the screensaver during employee login after the terminal has been idle.
Original PR description
Before this commit, when the login screen was left idle using an employee login, the screensaver would appear as expected. However, upon user interaction (e.g., moving the mouse), the system would update the previous screen to the screen saver. This causing issues during login where the screensaver would be displayed. opw-4494087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale order screen now handles offline and slow connections more gracefully. Staff can continue viewing previously loaded orders instead of seeing a blank screen or getting stuck in repeated loading.
Original PR description
This fix prevent blank screen (when offline) & inifinte loop (when in 3G or other low connection) on order screen. - **Offline Mode:** When accessing the order screen offline, now the screen loads previously fetched orders and displays a "Limited Functionality" popup. - **Slow Connection (3G):** Infinite loop (caused by repeated call to `await this.pos.getServerOrders()`) is fixed by ensuring orders load only once, even on slow connections using the flag `loadingOrderState` task-id: 4550978 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how eligible profit and loss accounts are filtered when configuring cash rounding. It ensures the account choices follow the intended rules consistently, reducing the chance of selecting an incorrect account.
Original PR description
The domain on the view overrides the domain on the model. As both domains are correct, this commit moves the partial domain on the view and adds it to the partial domain on the model. task-4514485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When Audit Trail is enabled, users who try to delete an incorrect payment now receive a more accurate error message. This avoids suggesting an unavailable archive option and helps users understand why the action is blocked.
Original PR description
**issue:** When "Audit Trail" is activated and a user creates an incorrect payment, deleting the payment is not possible. The error message suggests archiving the payment; however, there is no option to archive it. A more flexible error message should be used instead. opw-4494820
Users in the Invoicing & Banks group can now access customer statements and partner ledger reports from partner records. This fixes missing report access for the newer invoicing role, making day-to-day customer follow-up and account review smoother.
Original PR description
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208
The commissions report no longer displays a summed Achieved Rate when users group their commission records. This avoids showing an incorrect total for a percentage-based value, making grouped commission views clearer and less misleading.
Original PR description
Steps to reproduce: -Make multiple sales and assign a salesman to it in order to have a commission -Go to My Commissions -Add a Group By -The Achieved Rate column is displaying the sum of the achieved rates instead but it shouldn't display anything Problem: When making a group by on the commissions view and enabling the optional column achieved rate, the result of this group by would be the sum of all the achieved rate for this group, which is not correct. As it was decided that it made no sense, the total would not be displayed anymore. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/sale_commission/report/commission_report.py#L19 Fix: The aggregator parameter was used to prevent the total to be displayed. opw-4512739
This update cleans up an unusual indentation issue in the tax report code. It is a minor maintenance fix that helps keep the reporting module tidy and easier to maintain, with no expected change to business workflows.
Original PR description
The aim of this commit is cleaning a weird indentation introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/103369fb171654f4b0457d9b1629224def7465eb
This fixes an issue where old error messages could remain visible after processing Uruguay electronic invoices. Users will see more accurate current status information, reducing confusion when reviewing invoices.
The Kenya payroll accounting demo data now assigns the required payroll journal before confirming demo payslips. This prevents demo installation and automated validation failures, helping test and demonstration environments load reliably.
Original PR description
In odoo 18.0 the `journal_id` on `hr.payroll.structure` [became not required](https://github.com/odoo/enterprise/commit/fb59524a95b0f78112002d1e4d5ad3d6c301de7e#diff-761891fe4e3aa9cb1df74ffca5261004adaf8ac8c3df5857035953e5318be967L16-R16). And in the demo data for this module `action_payslip_done` is called, which [requires](https://github.com/odoo/enterprise/blob/4784d4a48d11c72afb05f2bc7c9062c5644bbf75/hr_payroll_account/models/hr_payslip.py#L53-L54) the payroll structure to have a journal. `hr_payroll_structure_ken_employee_salary` is used as the structure for all the payslips in the demo error in runbot [build](https://runbot.odoo.com/runbot/build/73486292)
Selecting multiple documents with Shift now works correctly in both kanban and list views. This prevents folders from being accidentally selected and aligns document list behavior with other Odoo list views, making bulk actions more reliable.
Original PR description
Before this commit, In kanban view when selecting multiple documents while holding shift as modifier, it could happen that folders were selected too. This was due to the logic which was using document ids as the range value when looping on `root.records` but with the new UI where the folders are now displayed on top of the documents it was buggy. In list view, we would like to keep the same behavior as in other list views. This commit fixes those issues. Task-4532046
Users can now reliably insert views or view links from custom menus into Knowledge articles. This prevents failed insertions and error pages when navigating from custom menu actions, helping teams keep article content connected to the right business views.
Original PR description
Issue ===== The view is not inserted into the article, or the view link results in a traceback error. Steps ====== 1. Create a custom menu with its configuration using the model (Create a Menu). 2. Navigate to the custom menu action via the parent menu's route. 3. Use the actions to navigate to Knowledge > Insert view/link in article, then select an article (either existing or new). Technical ========= Due to a recent change introduced in this [commit](https://github.com/odoo/enterprise/commit/30c71b1fee8c91df5342b2b1ef5f6e888e84571d) the issue arises from the function 'this.actionService.loadAction' requiring either an actionxmlid or actWindow to process the action. Previously, only the actionxmlid was available, which caused the problem. The provided fix resolves this issue by ensuring both identifiers are correctly handled. Task-4437944
The Studio report editor now shows the translation button again when editing a report source. This lets users translate report field labels directly from the editor, restoring expected access for multilingual reports.
Original PR description
Version - 18.0 Problem - The translation button in the studio reports is hidden/ not accessible to the customer Steps to reproduce- Open Sales app > Go to the Studio view > Select Reports from the menu > Open any report among the listed ones On the left hand side - in the studio editor select "Edit Source" On the Edit source file - In the initial version there used to be an EN (Translation button) for them to translate the display field names opw-4417402
Code cleanup and technical improvements
This change removes an unused internal input from the HTML editor’s text paste handling. It simplifies the code and helps prevent future maintenance issues without changing the user experience.
Original PR description
**Reason**: After PR https://github.com/odoo/odoo/pull/196130, we discovered that the `selection` parameter of `pasteText` was unnecessary. It was not used before calling `insert`, and after that, the selection is outdated. The current selection should instead be retrieved from the selection plugin. **Change**: Remove the unused `selection` parameter from `pasteText`. opw-4558222 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
Letzdoo has formally signed Odoo's Contributor License Agreement. This confirms the company can contribute to Odoo under the required legal terms, supporting compliant future collaboration.
Original PR description
Sign the CLA in name of Letzdoo https://www.letzdoo.com --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-orde
Original PR description
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. opw-4225668 (This pr was merged but introduced an error with the test which was fixed in a separate pr: https://github.com/odoo/odoo/pull/186539) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186174 Forward-Port-Of: odoo/odoo#183601
Versions -------- - saas-17.4+ Steps ----- 1. Go eCommerce products page; 2. click on a product; 3. use browser's "Go back" button to go back. Issue ----- There's no going back. Cause ----- PR https://github.com/odoo/odoo/pull/157412 modified the `_setUrlHash` method used to manage product attributes. One of the changes it made is modified the current URL using `window.location.hash` instead of `window.location.replace`. While both methods can make identical changes to the
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Go eCommerce products page; 2. click on a product; 3. use browser's "Go back" button to go back. Issue ----- There's no going back. Cause ----- PR…
Versions -------- - saas-17.4+ Steps ----- 1. Go eCommerce products page; 2. click on a product; 3. use browser's "Go back" button to go back. Issue ----- There's no going back. Cause ----- PR https://github.com/odoo/odoo/pull/157412 modified the `_setUrlHash` method used to manage product attributes. One of the changes it made is modified the current URL using `window.location.hash` instead of `window.location.replace`. While both methods can make identical changes to the URL, a key side-effect of `Location:replace()` is that the URL being replaced won't get saved in the session's `History`[^1]. As this method is called the moment the page loads, modifying the URL via `location.hash` will store the initial product page URL without attribute hashes in the session history. Then when trying to navigate back, the method will be called again immediately to apply attribute hashes, again modifying the session history, making it virtually impossible to leave the page without clicking a new URL. Solution -------- Use `history.replaceState`[^2] to update the current state, and not create any new entries. opw-4416701 [^1]: https://developer.mozilla.org/en-US/docs/Web/API/Location/replace [^2]: https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState Forward-Port-Of: odoo/odoo#194712
### Issue: Curently, the reservation state of a production is computed from the status of the move raws that are not picked. This includes moves wihtout demands which should not infer with the reservation state at all. ### Steps to reproduce: - In the settings, Enable "Multi-Step Routes" - Go to Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in 2 steps-manufacturing - Create a final product (FP) tracked by Serial number, and 2 storable components:
Original PR description
### Issue: Curently, the reservation state of a production is computed from the status of the move raws that are not picked. This includes moves wihtout demands which should not infer with the…
### Issue:
Curently, the reservation state of a production is computed from the status of the move raws that are not picked. This includes moves wihtout demands which should not infer with the reservation state at all.
### Steps to reproduce:
- In the settings, Enable "Multi-Step Routes"
- Go to Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in 2 steps-manufacturing
- Create a final product (FP) tracked by Serial number, and 2 storable components: COMP1 and COMP2
- Create a BOM for FP:
- Component lines:
- 1 x COMP1
- 0 x COMP2 !!
- Operations:
- OP1 with an instruction of type "register production"
1. Create an MO for 1 x FP > Confirm
2. Validate the pick transfer for 1 unit of COMP1
> Currently OP1 is marked as ready
3. Mark the component line of COMP1 as "picked"
#### > OP1 is in waiting status
Same result as 3:
3'. Go to the shopfloor > register production from the MO card
#### > This will pick the COMP1 raw move and OP1 will disappear because of the "ready" filter
### Cause of the issue:
Since you manufacture in 2 steps, the state of the raw move of COMP2 is waiting even though its demand is 0 (before and after you validated the pick move for COMP1). However, only non picked moves are considered to be relevant in the computation of the reservation state of the MO: https://github.com/odoo/odoo/blob/d8fc04f5875dbd3098e58f382d0cea3c7c7c38af/addons/mrp/models/mrp_production.py#L613-L621 Once you pick the COMP1 move which should be the only relevant one the reservation state of the MO becomes computed solely based on the state of the COMP2 raw move and becomes "waiting". In turns, this triggers a recomputation of the state of the workorders and flagging it as waiting: https://github.com/odoo/odoo/blob/d8fc04f5875dbd3098e58f382d0cea3c7c7c38af/addons/mrp/models/mrp_workorder.py#L148-L165
opw-4383004
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#196517
Forward-Port-Of: odoo/odoo#196388The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217 Forward-Port-Of: odoo/odoo#196702 Forward-Port-Of: odoo/odoo#195482
Original PR description
The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217 Forward-Port-Of: odoo/odoo#196702 Forward-Port-Of: odoo/odoo#195482
Description of the issue/feature this PR addresses: This PR aims to allow the user to create a CN in a different journal than the one the invoice has. Current behavior before PR: When a user tries to create a CN from a E-invoice with a manual journal, and then changes the journal on the CN wizard, the field "Document number" that is required for manual journals is still visible and required so the wizard can not be confirmed. Desired behavior after PR is merged: When the user creates a
Original PR description
Description of the issue/feature this PR addresses: This PR aims to allow the user to create a CN in a different journal than the one the invoice has. Current behavior before PR: When a user tries to create a CN from a E-invoice with a manual journal, and then changes the journal on the CN wizard, the field "Document number" that is required for manual journals is still visible and required so the wizard can not be confirmed. Desired behavior after PR is merged: When the user creates a CN and then change the journal on the CN wizard, the visibility and requirement of the fields should be adjusted as expected for the journal type selected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192728
The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935) Forward-Port-Of: odoo/odoo#196886 Forward-Port-Of: odoo/odoo#196835
Original PR description
The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935) Forward-Port-Of: odoo/odoo#196886 Forward-Port-Of: odoo/odoo#196835
Behavior Before the Commit: Whenever you change the account type of a Cash and Bank account to a different type, please ensure that the Reconcile option is set to True. However, if you later switch the account type back to Cash and Bank, the Reconcile option will remain True and will not automatically revert to False. Fix: explicitly set reconcile to False for account_type 'Cash and Bank' in compute_reconcile method. Behavior After the commit: Reconcile will be changed to false o
Original PR description
Behavior Before the Commit:
Whenever you change the account type of a Cash and Bank account to a different type,
please ensure that the Reconcile option is set to True. However, if you later switch
the account type back to Cash and Bank, the Reconcile option will remain True and
will not automatically revert to False.
Fix: explicitly set reconcile to False for account_type 'Cash and Bank' in compute_reconcile
method.
Behavior After the commit:
Reconcile will be changed to false on changing the account type to Cash and Bank.
opw-4450088: https://www.odoo.com/odoo/my-support-tasks/4450088
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194358### Steps to reproduce: - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable prodcut - Update the on hand quantity: - 10 units in package PK - Inventory > Configuration > Warehouse Management > Locations - Create 2 warehouse locations: WH/LOC1, WH/LOC2 - Go to the barcode app and proceed with the scans: 1. Scan the internal transfer picking type 2. Scan WH/STOCK as a source location 3. Scan the package name (PK) 4. Scan WH/LOC1 as
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable prodcut - Update the on hand quantity: - 10 units in package PK - Inventory >…
### Steps to reproduce:
- In the settings enable: Multi-Step Routes, Operations > Packages
- Create a storable prodcut
- Update the on hand quantity:
- 10 units in package PK
- Inventory > Configuration > Warehouse Management > Locations
- Create 2 warehouse locations: WH/LOC1, WH/LOC2
- Go to the barcode app and proceed with the scans:
1. Scan the internal transfer picking type
2. Scan WH/STOCK as a source location
3. Scan the package name (PK)
4. Scan WH/LOC1 as destination location
- Leave the barcode app without validation
- Go to the barcode app and proceed with the scans: i -> iii, iv'. Scan WH/LOC2 as destination location
- Try to validate the picking
#### > Invalid operation: You cannot move the same package content more than once in the same transfer or split the same package into two location.
### Cause of the issue:
As both pickings were treated via the barcode app, they generated picked move lines related to the package. Both of these move lines have updated the reserved quantity of the stock.quant present in stock:
- WH/STOCK, quantity: 10, reserved_quantity: 20.
When you try to validate the second picking, you will launch an `_action_done` of its move line that will create a new quant in WH/LOC2 and update the quant in stock:
- WH/STOCK, quantity: 0, reserved_quantity: 10.
- WH/LOC2, quantity: 10, reserved_quantity: 0.
The error is raised just after since 2 quants with either a quantity or reserved quantity are found:
https://github.com/odoo/odoo/blob/6349fb0362d881672616bb4b800bd32be82f9a5f/addons/stock/models/stock_move.py#L1910-L1917
### Fix:
Since the check is made in order to check the consistency of result packages moved by the current validation the "reserved_quantity" should not matter.
opw-4456484
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#193214**Current behavior:** With a FIFO + real-time product, `ProductA`: Creating a sale order with multiple order lines for ProductA, processing the resulting delivery in 2 separate pickings via backorder (1st delivery for the 1st line, 2nd delivery for the 2nd line), then invoicing the delivered product separately result in an invoice with invoice lines which do not reflect the value of the product at delivery time. **Expected behavior:** The SVLs generated from the deliveries should info
Original PR description
**Current behavior:** With a FIFO + real-time product, `ProductA`: Creating a sale order with multiple order lines for ProductA, processing the resulting delivery in 2 separate pickings via backorder…
**Current behavior:** With a FIFO + real-time product, `ProductA`: Creating a sale order with multiple order lines for ProductA, processing the resulting delivery in 2 separate pickings via backorder (1st delivery for the 1st line, 2nd delivery for the 2nd line), then invoicing the delivered product separately result in an invoice with invoice lines which do not reflect the value of the product at delivery time. **Expected behavior:** The SVLs generated from the deliveries should inform the generated AccountMoves. **Steps to reproduce:** 1. `FIFO-prod`: FIFO and real-time valuation & costing 2. Receive 12 units of `FIFO-prod` @ $100 per 3. Create a sale order with order lines: * `FIFO-prod` `10 units` `price_unit=$100` * `FIFO-prod` `2 units` `price_unit=$100` 4. Confirm the sale order, on the delivery, only receive the first move for the 10 qty, backorder the other 2 qty 5. Receive the backorder, create an invoice- edit the invoice lines so that 5/10 of line 1 and 2/2 of line 2 are invoiced, then post/confirm 6. Edit the `standard_price` of `FIFO-prod` (e.g., $100 -> $50) 7. Create another invoice for the remaining quantity and post 8. Observe that the COGs lines on the invoice have been calculated with a different price unit than the other invoice & unit_price for the out SVLs **Cause of the issue:** When getting the price unit of a given anglo saxon invoice line, there is no check that all the collected COGS lines are linked to the sale order line which corresponds to the product and product_qty that we are attempting to value. This creates an imbalance in the qty calculation later here: https://github.com/odoo/odoo/blob/f2728b2fe13a355ecb301a3714639b8a07f418b4/addons/stock_account/models/stock_valuation_layer.py#L202-L211 when the valuation is actually performed. **Fix:** Only consider posted COGS lines for the sale order line with the product qty that is getting valued when calculating `qty_invoiced`. opw-4321363 Forward-Port-Of: odoo/odoo#196067 Forward-Port-Of: odoo/odoo#195046
Before this commit: when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception. after this commit: currentOrder is stored before processing the request to avoid the exception. opw-3859174 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-p
Original PR description
Before this commit: when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception. after this commit: currentOrder is stored before processing the request to avoid the exception. opw-3859174 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#194726 Forward-Port-Of: odoo/odoo#165333
Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On Odoo the label was appearing fine but when the invoice was confirmed and sent, the XML file content is created with hidden characters.This produced the web service to return an error when trying to validate the electronic invoice. Current behavior before PR: Special or hidden characters appear o
Original PR description
Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On…
Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On Odoo the label was appearing fine but when the invoice was confirmed and sent, the XML file content is created with hidden characters.This produced the web service to return an error when trying to validate the electronic invoice. Current behavior before PR: Special or hidden characters appear on the XML file of an electronic invoice. Steps to reproduce: 1. Install Uruguay - Electronic Invoice module 2. Create EDI invoice, add special character to the description of the product you are using. Example used for testing (copy-paste it): 219179120011 3. Validate the invoice 4. Print and send it 5. Check "DscItem" field on the XML file created. Here is a one minute [video](https://drive.google.com/file/d/18JcnKCbaq7cH_NVyPol4CWXHdqZAxAdo/view) reproducing the error on runbot. Desired behavior after PR is merged: These characters are cleaned up at the xml level on cleanup_xml_node method to avoid them to appear and prevent errors when validating the XML on localizations web services. Related PR on v16 regarding the same issue in another context: https://github.com/odoo/odoo/pull/154509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193047
When AE localization extends the default invoice report, they replace the `<th name="th_taxes"><span>Taxes</span></th>` with `<th name="th_taxes"><span t-if="...">VAT</span><span t-else="">Taxes</span></th>`. Then when AR localization is installed, it will replace the first div with the t-if. We end up in a situation with a `<span/>` followed by a `<span t-else=""/>` which raise an error because it is expecting a `t-if`. task-no Forward-Port-Of: odoo/odoo#196765
Original PR description
When AE localization extends the default invoice report, they replace the `<th name="th_taxes"><span>Taxes</span></th>` with `<th name="th_taxes"><span t-if="...">VAT</span><span t-else="">Taxes</span></th>`. Then when AR localization is installed, it will replace the first div with the t-if. We end up in a situation with a `<span/>` followed by a `<span t-else=""/>` which raise an error because it is expecting a `t-if`. task-no Forward-Port-Of: odoo/odoo#196765
In SEPA payment files, when a structured reference is used, it is put in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a maximum length of 35 characters. Since we only use structured references that are always less that 35 characters, this should not be a problem. However, the way we validated the structured reference was by performing a `re.match()`, which only matches from the beginning of the string. So if more characters would be after the structured reference, it would still
Original PR description
In SEPA payment files, when a structured reference is used, it is put in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a maximum length of 35 characters. Since we only use structured references that are always less that 35 characters, this should not be a problem. However, the way we validated the structured reference was by performing a `re.match()`, which only matches from the beginning of the string. So if more characters would be after the structured reference, it would still match and it would be possible to go beyond 35 characters. In this commit, we fix this by using a full match instead of a match from the beginning. [opw-4357554](https://www.odoo.com/odoo/project.task/4357554) Forward-Port-Of: odoo/odoo#194583
…on display option Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is
Original PR description
…on display option Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. (forward port of https://github.com/odoo/enterprise/commit/d3606d5a99ba7328cce164c0c16ff594d7639f4a) opw-4225668 X-original-commit: https://github.com/odoo/odoo/commit/2d753a90d0612b35d9d012574915d2e6bb754b1f Forward-Port-Of: odoo/enterprise#74256
The idea is: 1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable. 2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpD
Original PR description
The idea is: 1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each…
The idea is: 1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable. 2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpDisplay` so it doesn't do a lot of sense to define it in `MrpDisplaySearchModel`. The only exception is in the `_notify` where the cache is invalidated (TODO: to check if it still relevant.) Also, instead of havin an object with one uniq key who refers to an array (`recordCache.ids`), it will now be an array directly. 3. Make `recordCacheIds` part of the `MrpDisplay` `state`. The purpose of this change is to refresh the app everytime the cache is modified. Also, this commit fix an issue where the record cache wasn't correctly updated when the selected employee requieres a PIN code. The issue was the cache was invalided before the PIN code was validated, a lot of async methods weren't awaited and the dialog itself wasn't bound to a callback in a way to be able to invalidate cache at the right moment. OPW-4256568 Forward-Port-Of: odoo/enterprise#77784 Forward-Port-Of: odoo/enterprise#74421
Before this commit: when triggering a followup reports on parent company, followup levels on both parent company and branches were triggered, meaning duplicated datas could be sent to customers. After this commit: Now only the followup on the current company is triggered, ignoring all the branches. task-4393081 Forward-Port-Of: odoo/enterprise#77954 Forward-Port-Of: odoo/enterprise#75572
Original PR description
Before this commit: when triggering a followup reports on parent company, followup levels on both parent company and branches were triggered, meaning duplicated datas could be sent to customers. After this commit: Now only the followup on the current company is triggered, ignoring all the branches. task-4393081 Forward-Port-Of: odoo/enterprise#77954 Forward-Port-Of: odoo/enterprise#75572
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like lea
Original PR description
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the…
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like leaving the "tax" column empty), then confirm and send the invoice again to DGI, a new pop up is raised showing a new error message accordingly but the banner of the header remains showing the same error as before (saying the product unit price is 0). This leads to confusion about what is the current error to be amended to properly send the invoice to DGI. Steps to reproduce the error: - Create an uruguayan electronic invoice on a testing enviroment. - Select a product and change its unit price to 0. - Try to send & print the invoice, creating the CFE. - An error like this will be shown:  - Go back to the move and check that a banner with the error has been added at the top.  - Reset to draft, add a valid unit price and delete the "Taxes" column value. - Confirm, Send&Print the invoice. - A new pop up like this should raise:  - Go back to the invoice and check that the banner remains as before, showing an outdated error message. Forward-Port-Of: odoo/enterprise#77710
This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#78680
Original PR description
This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#78680
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the
Original PR description
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those…
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the same issue - didn't complained with it... But the "new" mode (which is actually closer to the actual GUI behavior of Chrome) got stuck at those steps. This commit fixes this issue by using the `private_street` field (which contains the actual street name) instead of the `private_street2` field (which is often empty). Once done, a second issue was detected as the step filling the computation of "58/4" didn't match (even wrongly) any empty field anymore. This commit simply removes those unused steps. Forward-Port-Of: odoo/enterprise#78626 Forward-Port-Of: odoo/enterprise#78397
Users with the ability to see the button 'Report in next payslip' should be able to use it even if they don't have Payroll access rights. task-4481091 Forward-Port-Of: odoo/enterprise#77193
Original PR description
Users with the ability to see the button 'Report in next payslip' should be able to use it even if they don't have Payroll access rights. task-4481091 Forward-Port-Of: odoo/enterprise#77193
Steps to Reproduce: 1. Enable the Rental Transfers option in Configuration > Settings. 2. Create a rental order with one rental product and one sales product. 3. Confirm the order. 4. Validate the delivery order. Issue: - The delivered quantity is updated for the rental product but not for the sales product. Cause: - This behavior arises because the assign_picking method reuses an existing picking_id if the domain matches, updating subsequent moves' location_dest_id to match
Original PR description
Steps to Reproduce: 1. Enable the Rental Transfers option in Configuration > Settings. 2. Create a rental order with one rental product and one sales product. 3. Confirm the order. 4. Validate the delivery order. Issue: - The delivered quantity is updated for the rental product but not for the sales product. Cause: - This behavior arises because the assign_picking method reuses an existing picking_id if the domain matches, updating subsequent moves' location_dest_id to match the reused picking. Fix: - Override _compute_location_dest_id and update the location_dest_id if conditions are fulfilled. opw-4298443 Forward-Port-Of: odoo/enterprise#73895
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78700 Forward-Port-Of: odoo/enterprise#77103
Original PR description
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78700 Forward-Port-Of: odoo/enterprise#77103
This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947
Original PR description
This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947 BANK DETAILS: TEST12344 4) Confirm, print and send the invoice. 5) Check the pdf is created like this:  Expected behavior after this PR: The text on the "Adenda" section of the pdf should not print hidden characters. Forward-Port-Of: odoo/enterprise#76972
Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600 Forward-Port-Of: odoo/enterprise#73821
Original PR description
Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600 Forward-Port-Of: odoo/enterprise#73821