Monday, April 29, 2024
35 changes · 17.0
Resolved issues and error corrections
Analytics account searches no longer check partner records that are already reflected in the account name. This removes unnecessary work and should improve performance during distribution analytics without changing expected business results.
Original PR description
Before this commit, our distribution analytics process included searching the table res.partner for potential matches, which negatively impacted performance. However, this is no longer necessary as the default name of the account matches the name of the partner. This change removes the unnecessary performance overhead.
Vendor bills reset to draft now refresh payment term details before reposting. This ensures changed early-payment discount rates are applied correctly, so vendor settlement amounts match the latest payment terms.
Original PR description
Steps to reproduce: 1. create a payment term "A" with discount 10% 2. make a vendor bill with payment term "A" (post it) 3. change discount on payment term "A" to 20% 4. go to vendor bill - reset to draft - put back the payment term - post it. 4. Check vendor > Amount to settle. (the discount amount is not updated). Issue: Still 10% instead of 20% opw-3768356
This fix improves the speed of receipt printing when a preparation display is connected to the point of sale system. Previously, order changes were sent to the preparation display before printing the receipt, causing users to wait for those requests to complete. Now the receipt prints first, allowing the workflow to proceed more quickly.
Original PR description
Order changes are sent to the preparation display before printing the receipt. This slows down the workflow as users have to wait for other requests to finish before the receipt is printed when a preparation display is connected. opw-3756416
This fix corrects the Spanish VAT report (Libro de IVA) export to exclude withholding tax lines, ensuring only VAT base amounts and VAT tax lines are included in the report. This ensures compliance with Spanish tax reporting requirements and prevents incorrect tax data from appearing in official tax documents.
Original PR description
Withholding tax lines should not appear in the Libro de IVA export, where only base lines and Tax Lines of IVA (=VAT) taxes should be reported. task-3875272
Fixed an issue where running timers on timesheet-based service orders would remain active after invoice creation, forcing users to manually discard them. Now, when an invoice is created, all active timers are automatically stopped and their time is included in the invoice amount.
Original PR description
Steps to reproduce: - Make a service product, with invoicing policy based on timesheet and project & task set for create on order. - Make an SO for that product - The SO will create the task and the project - Register timesheet linked with the task with 15 min - Start a timer - Create the invoice Issues: The timer is still running, with the only choice possible being to discard it. Solution: The behaviour wanted by the po is to stop all the timer and count them in the invoice. opw-3715694
Fixed an issue where viewing timesheets from an invoice in the customer portal was incorrectly showing timesheets from multiple invoices instead of just the current one. The fix ensures that when searching for timesheets linked to a specific invoice, only the relevant timesheets are displayed, improving accuracy and preventing confusion for customers reviewing their invoiced work.
Original PR description
Steps to reproduce: ------------------- - create a product: - service - based on timesheets - create a project and task on order - create an order with this product - confirm the order - open an…
Steps to reproduce: ------------------- - create a product: - service - based on timesheets - create a project and task on order - create an order with this product - confirm the order - open an helpdesk ticket for the same customer - select the previous created sale order item - create a timesheet for this helpdesk ticket - from the sale order, create the invoice - confirm the invoice - go to the invoice and click on preview - click on view timesheets --> we have the correct timesheet (OK) - go to the task and create a timesheet - create the second invoice from the sale order - go to the second invoice and click on preview - click on view timesheets --> we have the two timesheets which is wrong (KO) Cause: ------ When we build the domain to search for timesheets linked to an invoice, we add an `OR` domain which takes into account timesheets linked to helpdesk tickets (and on the same sale order line). Solution: --------- When searching by invoice, it is necessary to look for timesheets in the helpdesk tickets, but making sure that they are not linked to an invoice that may not be the one requested in the search. opw-3865963 Forward-Port-Of: odoo/enterprise#61596 Forward-Port-Of: odoo/enterprise#61287
Fixed an issue where helpdesk tickets created from emails sent by contacts not in the database were missing their description. The system now correctly identifies and captures the ticket description by matching email addresses instead of internal contact IDs, ensuring all customer communications are properly recorded.
Original PR description
To reproduce: ============= - configure helpdesk team with email address - contact this email address with a contact doesn't exist in the database -> the created ticket won't have a description Problem: ======== the message's `author_id` is not set, which prevents the description to be set, as we compare the `partner_id` of the ticket with the message's `author_id` to make sure to deal with real customer and not Odoobot or anything else. Solution: ========= instead of comparing the `partner_id` of the ticket with the message's `author_id`, we compare the `partner_email` of the ticket with the message's `email_from`. opw-3850228 Forward-Port-Of: odoo/enterprise#60858
This update improves how Odoo processes bank statements from Nordic countries (particularly Sweden) by adding support for additional data fields required by Nordic banks. The system now correctly extracts partner names and transaction details from bank statement files, ensuring accurate financial records for companies using Nordic banking services.
Original PR description
…ements - Add partner name check for Ultimate Debtor/Creditor (UltmtDbtr/UltmtCrdt) - Add transaction name check for Additional Remittance Information (AddtlRmtInf) Initial request from Swedish partner @daniel-stenlov, confirmed with documents: https://www.nordea.com/en/doc/nordea-caar-camt.053.001.02-account-statement-extended-0.pdf Related: https://github.com/odoo/enterprise/pull/49542 Co-authored-by: daniel-stenlov Forward-Port-Of: odoo/enterprise#59927
This fix resolves a database compatibility issue where some systems had an invalid default value for a Mexican electronic invoice field. The system was rejecting this outdated value and causing errors. We've updated the field to use a proper default value so users won't experience disruptions when processing invoices.
Original PR description
Some databases have a default column value `undefined` on l10n_mx_edi_cfdi_sat_state. When assigning `undefined` to `l10n_mx_edi_cfdi_sat_state`, the orm raises an error because it's no longer a valid value for this selection field. To not block people, let's set the field to None by default.
Fixed the bank reconciliation widget to correctly display transaction details from the dedicated transaction_details field instead of outdated narration fields. Transaction details are now consistently shown in a dedicated tab regardless of whether the transaction has been reconciled, improving the user experience and ensuring information is always accessible in the same location.
Original PR description
In saas-16.3 we started to use a dedicted field transaction_details on statements [1] instead of the narration fields from `account.move`. 1. Fix the view so that it displays the right field. 2. Move transaction details to the same place regardless of the reconciled status of the transaction, into the dedicated tab. Previously, this transaction details was displayed in the manual operations tab when the statement was not reconciled and in debug mode. When reconciled it was available in a dedicted tab "Transaction Details" (no need to be in debug). [1] https://github.com/odoo/odoofin/blob/17.0/odoofin_proxy/models/odoofin_proxy.py#L315 task-id: 3888162 Forward-Port-Of: odoo/enterprise#61559 Forward-Port-Of: odoo/enterprise#61316
This fix restores the "Reset to Draft" button functionality for journal entries in the Mexican EDI module. A missing condition was incorrectly hiding this button from all users. The fix ensures that users can properly reset journal entries to draft status when needed.
Original PR description
Missing condition that is hiding the "Reset to Draft" button on all journal entries.
Fixed a bug where pressing the tab key in a stock operation dialog would incorrectly move focus to the list view outside the dialog. This issue occurred when opening stock move records in a dialog window. The fix ensures that keyboard navigation stays within the active dialog instead of jumping to background elements.
Original PR description
Steps to reproduce ================== - Install stock,purchase - Create a new storable product tracked by USN - Create a new RFQ with that product - Confirm it - Click on the receipt smart button - In the operation notebook, click on the "Open move" button (last blue button) - Press tab => The focus is moved to the list view outside the dialog Cause of the issue ================== This issue is specific to the `StockMoveX2ManyField` as it's the only one where you can either edit the record inline, or open it in a dialog. Outside stock, if we are allowed to edit a line record in a dialog, isInlineEditable will evalutate to false. In that case, the record will be considered readonly, and focusCell won't do anything. Solution ======== We should only change the focus is the list view is the one from `uiService.activeElement` opw-3719834
This fix resolves an issue where users couldn't reliably drag and drop elements in the content editor. The problem occurred when the system waited too long before recognizing the drag action, causing elements to be removed before the drag could start. The fix enables drag and drop to respond immediately to user actions.
Original PR description
Before this commit, the drag and drop functionality of the MoveNodePlugin was not working all the time. The movable element would not move. The bug started with the introduction of the new drag and drop util (useNativeDraggable). The util has a parameter tolerance that does not start the drag and drop until the mouse has moved a certain distance. If the mouse entered another hook element before the start of the drag was triggered, the node that the user clicked would be removed before the drag started, therefore it would never start. This commit fixes the issue by setting the tolerance to 0, so the drag and drop starts immediately. task-3802746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a display issue in the Sequences settings page where the legend text was difficult to read due to being confined to a single column. The text now spans multiple columns, allowing it to display properly without awkward line breaks. This improves the user experience when viewing sequence information in the Technical Settings.
Original PR description
Issue ----- The trailing text on the `ir.sequence` view is unreadable due to spanning only one column which leads to awkward line-wrapping. Steps ----- - Go to Settings -> Technical -> Sequences. - Select the sequence with code "sale.order". - Have a look at the legend. Cause ----- The `<div>` containing the text spans only one column which is not suitable for long text. opw-3820141 Forward-Port-Of: odoo/odoo#160912
This fix corrects an issue where time accrual allocations were being calculated incorrectly when set to start in the past. Previously, the system would fail to save the accrual amount, causing duplicate allocations to be processed in future months. The fix ensures the accrual amount is properly saved when creating allocation records.
Original PR description
### Current Issue: When we have an accrual plan where the accrued time is allocated at the start of the accrual period and we set the allocation start time in the past, the plan will be processed but `already_accrued` will not be saved. ### Example: - We have an accrual plan that allocates 1 day per month at the start of the accrual period. Milestone reached 0 days after allocation start. - We set the start date of the allocation to 2024-01-01, the current date is 2024-03-15. The number of days are calculated to 3.00 (jan, feb, mar). - We save the record, `already_accrued` is not saved (defaults to false) - When the scheduled action runs (2024-04-01), it will allocate 2 days instead of 1 ### Solution: This commit fixes this behavior by adding the `already_accrued` field to the form view so that it is saved when the record is created. opw-3851320
This update fixes how discount lines from delivery and loyalty programs are handled during invoicing. Previously, when these discount lines were the only items to invoice, they were incorrectly processed. The fix ensures consistent behavior across all discount types so that discount-only invoices are properly managed.
Original PR description
Delivery and loyalty discount lines were already disregarded when computing the invoice status if they were the only lines to invoice, but new logic of discount lines, introduced in 17 with bf95b1f2ade01a79263461987e62d3b5b1b09483, didn't consider this situation. This commit harmonizes the existing logic of `loyalty` & `delivery`, directly in `sale`, making sure this is correctly handled at once for the three cases. opw-3853012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a bug where invalid recipients (contacts without email addresses) remained in the recipient field even after users closed the email validation popup without providing an email. Now when users dismiss the popup, invalid recipients are properly removed, preventing repeated validation prompts when selecting other recipients.
Original PR description
### [FIX] mail: rm invalid recipient on m2x popup close Before this change incorrect records with invalid/lacking emails were added to tag field (they were not displayed) and user was prompted to fix…
### [FIX] mail: rm invalid recipient on m2x popup close Before this change incorrect records with invalid/lacking emails were added to tag field (they were not displayed) and user was prompted to fix invalid email. The issue was that discarding the popup didn't remove the invalid records from the tag field. ### [Reproduce] - Install contact (or crm,sale... whatever with a composer) - Create a contact C without an email - Open a full screen composer: 1. Select a contact 2. Click "Send message" on the chatter 3. Click the expand button, to bring up full-screen composer - In the "Recipients": 1. Select recipient C, this will open a popup asking to fill in missing email 2. Close the popup without filling the email 3. Select another recipient, with an email 4. BUG: popup asking to fill in email for C is showed Note: issue exists in every composer view, not specyfic to crm opw-3829741 ## BEFORE https://github.com/odoo/odoo/assets/33809926/ff04beab-51a1-4405-b535-0c9869556947 ## AFTER https://github.com/odoo/odoo/assets/33809926/6f493ceb-99a8-4b49-9043-02ef929b7d14
This fix resolves an issue where WebP images would cause the system to crash when displayed in PDF reports. The system now properly handles WebP images by automatically converting them to JPG format for PDF compatibility, ensuring reports display images correctly without errors.
Original PR description
See discussions on https://github.com/odoo/odoo/pull/85494/. TLDR: webp image format needs to be supported, but we should avoid going through the Pillow library as it is largely unsafe for that…
See discussions on https://github.com/odoo/odoo/pull/85494/. TLDR: webp image format needs to be supported, but we should avoid going through the Pillow library as it is largely unsafe for that format. jpg attachment are created in JS at upload time. Wkhtmltopdf doesn't support webp, so, in reports, we should display one of those jpg copies This work is handled by `ir.qweb: _get_converted_image_data_uri` which is used as: ```xml <img src="image_data_uri(some_b64value)" /> ``` The mentionned PR did not however adapt the ir.qweb.field.image that, when passed the option `qweb_img_raw_data` should return a base64 url such as `data:[mimetype],base64,[datas]`. usage: ```xml <span t-field="object.image_field" t-options-qweb_img_raw_data="1" /> ``` Hence, before this commit, there was a crash as we tried to pass that value to PIL. After this commit, there is no crash, and the image displays correctly as JPG in the PDF opw-3859423 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#161931
Fixed a display issue in the Documents app where dragging workspaces in the search panel to reorder them didn't show visual feedback about where they would be placed. The fix restores proper styling rules that were accidentally overridden by bootstrap classes, ensuring the drag-and-drop interface works as intended.
Original PR description
In Documents when dragging a workspace in the search panel to resequence it there was no visual effect showing where the workspace would drop. This was due to some css rules that were replaced by a bootstrap class in the following commit : 6f63e2349c397807588fcfcae9d28d93c9c378cf In our case, the `o_search_panel_category_value` node already has a `py-1` bootstrap class, which overrides the value set by the `py-0` class. this commit restores the `padding-top: 0 !important;` and `padding-bottom:0 !important;` rules to avoid conflict with other py-X CSS rules (e.g.: py-1, py-2, ...) Task-3877426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue in manufacturing orders where adjusting the quantity of consumed materials after a price change would create duplicate inventory records instead of merging them. The fix ensures inventory movements are properly consolidated regardless of price changes, improving data accuracy and reducing manual reconciliation work.
Original PR description
Steps to reproduce the bug: - Create a storable product C1: - standard_price: $10 - Update the quantity to 2 units - Create a storable product P1 with BoM: - Component: 1 unit of C1 - Create a MO to produce 1 unit of P1: - Confirm it - Update the price of C1 to $20 - Go back to the MO and set the quantity consumed of C1 to 2 - Mark the MO as done - Confirm the difference in consumption Problem: Another move is created with 1 unit of C1 consumed but is not merged with the first move because the two moves were created with different prices, making them incompatible for merging. Solution: There's no need to create the moves with `price_unit`. OPW-3791816
This fix resolves an accounting issue where invoices created after a Point of Sale session closes were not properly reconciling stock transactions. The solution reorders the process to create inventory pickings before generating invoices, ensuring all financial records match correctly in accounting systems that use automated inventory valuation.
Original PR description
We are in the context of anglo-saxon accounting, when selling a product having an automated valuation. The invoice linked to the `pos.order` should have its stock output line reconciled with its counterpart in the stock valuation journal. That is what happens if you create the invoice directly from point of sale. Currently, if you do not create the invoice, keep the session open and then click the "Invoice" button on the pos order, the stock output line will not be reconciled. This happens because in `action_pos_order_invoice`, the picking is created after the invoice. But the reconciliation happens when creating the invoice. As it doesn't have its valuation counterpart yet (which is created from the picking), it then do not reconcile with anything. The fix here is to create the picking before. opw-3702345 Forward-Port-Of: odoo/odoo#162594 Forward-Port-Of: odoo/odoo#154595
Users with permission to change task status were getting access errors when moving tasks to stages with SMS templates. This fix allows the system to send SMS notifications without requiring users to have direct access to SMS template records. The change ensures that legitimate task status transitions work smoothly for all authorized users.
Original PR description
### Steps to reproduce: Be sure to have the `sale_sms` module installed. - Connect as Marc Demo. Note: Marc has the administrator access rights in every service application including projects,... -…
### Steps to reproduce: Be sure to have the `sale_sms` module installed. - Connect as Marc Demo. Note: Marc has the administrator access rights in every service application including projects,... - Go to the field service app create a new task and change its state to `planned`. **> Access error: you are not allowed to access 'SMS Templates'** ### Expected behavior: Since the newly created user has the rights to modify the state of the task and since he does not try to access the content of any sms.template he should not raise this access error. ### Cause of the issue: The stage `planned` is associated with an SMS template. As such, when a task is moved to this stage, an sms will be sent using the template. This action is done during the `write` override of the `project_sms` module: https://github.com/odoo/odoo/blob/5f1a3bdcaa63492cf169f6f5f3eb2e2281ad5ab5/addons/project_sms/models/project_task.py#L24-L32 However, this `_send_sms` method will need to 'read' the sms.template to generate the sms: https://github.com/odoo/odoo/blob/e6be732450d9ef662a48ba074e1ca1ad32e35c04/addons/sms/models/mail_thread.py#L191-L192 Since the user does not have the acess rights to 'read' this template because of the `ir_rule_sms_template_so_sale_manager` acess rule defined in the `sale_sms` module, the access error will be raised. ### Fix: Since the `_send_sms` method will only read records in order to generate the sms that will be send, we should bypass access rigths checks during the call of this method. Note: this was already the solution used for portal users. opw-3789197 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163359 Forward-Port-Of: odoo/odoo#157702
This fix ensures that when database constraints are removed from models in Odoo, they are properly deleted from the database tables. Previously, constraints were left behind, causing problems during system upgrades. This resolves a common source of upgrade failures.
Original PR description
Otherwise we leave the constraints in the table. Common source of upgrade issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161115
This fix resolves a bug in the Website editor where dragging snippets to the bottom of the page would not scroll the page after closing a popup modal. The issue occurred because the system was still trying to scroll the modal instead of the page after it was closed. This fix ensures the correct scrollable element is restored when the modal closes, allowing smooth dragging and scrolling of snippets on the main page.
Original PR description
Steps to reproduce the bug: - In "Website" edit mode. - Drag and drop enough snippets onto the page to make the vertical scrollbar appear. - Drag and drop the "Popup" snippet onto the page. - Drag…
Steps to reproduce the bug: - In "Website" edit mode. - Drag and drop enough snippets onto the page to make the vertical scrollbar appear. - Drag and drop the "Popup" snippet onto the page. - Drag and drop enough snippets into the "Popup" to make the vertical scrollbar appear. - Close the popup. - Drag a snippet from the snippet menu without releasing the mouse. - Move it to the bottom of the page. - Bug: the page doesn't scroll. In the following commit [1], we enabled "smooth scroll on drag" to work within a modal. The element being scrolled was indeed the modal when dragging a snippet over it. However, in a later commit [2], the behavior was changed and caused the bug. After closing the modal, we did not redefine the scrollable element, so it remained the modal instead of the page. [1]: https://github.com/odoo/odoo/commit/40795c00368677b643afb7c0f2ccea7dd2eeb2ee [2]: https://github.com/odoo/odoo/commit/7ed3f3151a5352958f929ac8a4f10ea181be5ab1 task-3854032 Forward-Port-Of: odoo/odoo#162166
This fix resolves a crash that occurs during odooBot onboarding when users try to use canned responses. The issue was that canned responses weren't being properly passed along when sending messages, and they were only enabled in certain chat types. This update enables canned responses to work in the odooBot chat and ensures they're correctly included when messages are sent.
Original PR description
*: im_livechat, im_livechat_mail_bot Since odoo/odoo#110188 `canned_response_ids` is not being passed to `mail_message_post` and since odoo/odoo#127382 canned response is enabled in only non-channel threads so odooBot onboarding crashes on the canned response step. This commit allows using `canned responses` in `chat with odooBot` and makes sure that we send them with the message post data. Related to odoo/odoo#157997 Forward-Port-Of: odoo/odoo#163527 Forward-Port-Of: odoo/odoo#162234
Fixed an issue that prevented users from editing task views in Studio when using the Sales with Projects module. The system was incorrectly replacing view configurations, causing duplicate key errors. The fix now properly remaps view IDs instead of replacing the entire view list, allowing users to customize task views including Gantt, Activity, and Map views.
Original PR description
Steps to reproduce ================== - Install sale_project,industry_fsm,web_studio - Open quotation S00023 - Click on the Tasks stat button - Open studio - Go to views - Enable the gantt view =>…
Steps to reproduce ================== - Install sale_project,industry_fsm,web_studio - Open quotation S00023 - Click on the Tasks stat button - Open studio - Go to views - Enable the gantt view => Unable to complete the operation: duplicate key value violates unique constraint "act_window_view_unique_mode_per_action" Cause of the issue ================== The [action record] already contains the gantt view, but it is replaced inside the python [action]. In [previous] version, the user was entering this condition and thus had no problem editing the views Solution ======== Instead of replacing the entire action['views'], we can remap the view ids to the ones we want. One side effect of this though is that the `gantt,activity,map` views will be available by default. --- [action record]: https://github.com/odoo/enterprise/blob/1df090289f3c45c200d133734989a6d9a8073145/project_enterprise/views/project_task_views.xml#L227 [action]: https://github.com/odoo/odoo/blob/1a9302dc3a9b0d9323612c10e0f3a91300bb89fd/addons/sale_project/models/sale_order.py#L154 [previous]: https://github.com/odoo/odoo/blob/8dbcd3d955e7270fc26a6141e8fce751029e5a4b/addons/sale_project/models/sale_order.py#L133-L141 opw-3800071 Forward-Port-Of: odoo/odoo#163170
This fix corrects an inconsistency in how project profitability is calculated when purchase orders and vendor bills include taxes in their prices. Previously, purchase orders and vendor bills were calculated differently, leading to incorrect profitability figures. The fix ensures both are calculated consistently using the same method, providing accurate project cost tracking.
Original PR description
### Steps to reproduce the issue: 1. Create a purchase Tax and tick Include in Price in the Advanced Options 2. Create a Purchase Order with Analytic Distribution towards a Project in the Order Line…
### Steps to reproduce the issue: 1. Create a purchase Tax and tick Include in Price in the Advanced Options 2. Create a Purchase Order with Analytic Distribution towards a Project in the Order Line 3. Set the purchase Tax created before as the tax of the Order Line 4. Confirm the Purchase Order 5. Make sure the Project is Billable, then go to the Project Updates 6. The profitability calculated the price with the included Tax 7. Create a Vendor Bill and set the same Tax and Analytic Distribution as the Purchase order 8. Confirm the Bill 9. Return to the Project Updates 10. The profitability doesn't calculate the included Tax ### Explanation: In `project.project._get_profitability_items`, we can find an inconsistency in the queries. The query for `purchase.order.line` is looking for `price_unit`, which takes included taxes into account. https://github.com/odoo/odoo/blob/249aaac7bd1a13d62c947cddb1835772659aabff/addons/project_purchase/models/project.py#L125-L132 The query for `account.move.line` retrieves `price_subtotal`, which does not. https://github.com/odoo/odoo/blob/249aaac7bd1a13d62c947cddb1835772659aabff/addons/project_purchase/models/project.py#L171-L181 ### Suggested fix: In `project.project._get_revenues_items_from_invoices`, the `account.move.line` query retrieves `price_subtotal` as well. https://github.com/odoo/odoo/blob/8750b94c53c6ab58567873b0745fa6d9a18c97d0/addons/sale_project/models/project.py#L467-L474 With above information and input of PO (olma), taxes will not be calculated in `project.project._get_profitability_items`, therefore we will replace `price_unit` with `price_subtotal` in the `purchase.order.line` query. opw-3781426 Forward-Port-Of: odoo/odoo#163212 Forward-Port-Of: odoo/odoo#161634
This update fixes code compatibility issues with Python 3.12 by correcting invalid escape sequences throughout the Odoo codebase. These syntax warnings would become errors in future Python versions, so this proactive fix ensures the system continues to work smoothly as Python evolves. The changes are technical in nature and do not affect user-facing functionality.
Original PR description
Since python3.12 invalid escape sequences are deprecated and this will be removed in future versions. This commit fixes all the missing escape automatically using All checks passed!. Some will be escaped, other may be replaced by r string. Another solution would be to hide the deprecation warning but this would maybe need to adapt some of the versions later leading to another forwardport hell, lets fix it one for all once we are at it. Note that ruff check will forbid to introduce new ones in any cases. Manual forward port of #163493
This update corrects how product information (ID, quantity, and price) is processed in the product configurator tool. Previously, these values were being read as text when they should be numbers, which was causing inconsistencies with how tracking data is calculated elsewhere in the system. This fix ensures accurate product tracking across the platform.
Original PR description
Previously, some pieces of tracking info were parsed in the wrong format in the product configurator. I.e. id, quantity and price were parsed as strings but should be numbers (to be consistent with tracking info computations elsewhere). This change fixes the issue. Fixes #158052 Forward-Port-Of: odoo/odoo#163361 Forward-Port-Of: odoo/odoo#162932
This fix corrects an issue where viewing timesheets from an invoice in the customer portal would incorrectly display timesheets from other invoices on the same sales order. The system now properly filters timesheets to show only those linked to the specific invoice being viewed, ensuring customers see accurate billing information.
Original PR description
Steps to reproduce: ------------------- - create a product: - service - based on timesheets - create a project and task on order - create an order with this product - confirm the order - open an…
Steps to reproduce: ------------------- - create a product: - service - based on timesheets - create a project and task on order - create an order with this product - confirm the order - open an helpdesk ticket for the same customer - select the previous created sale order item - create a timesheet for this helpdesk ticket - from the sale order, create the invoice - confirm the invoice - go to the invoice and click on preview - click on view timesheets --> we have the correct timesheet (OK) - go to the task and create a timesheet - create the second invoice from the sale order - go to the second invoice and click on preview - click on view timesheets --> we have the two timesheets which is wrong (KO) Cause: ------ When we build the domain to search for timesheets linked to an invoice, we add an `OR` domain which takes into account timesheets linked to helpdesk tickets (and on the same sale order line). Solution: --------- When searching by invoice, it is necessary to look for timesheets in the helpdesk tickets, but making sure that they are not linked to an invoice that may not be the one requested in the search. opw-3865963 Forward-Port-Of: odoo/odoo#163617 Forward-Port-Of: odoo/odoo#162960
This fix corrects a test in the Manufacturing Subcontracting module that was failing in the community version due to an incorrect field reference. The test was using an outdated field name that only worked when an enterprise module was installed, masking the underlying issue. The fix ensures tests run correctly across all versions.
Original PR description
qty_done -> quantity Breaks tests for community version. Error is undetected with enterprise module 'stock_barcode' that re-introduce the field 'qty_done'
This fix corrects how the system finds the right business partner when processing electronic invoices. Previously, when multiple partners shared the same tax ID, the system would fail to identify the correct one. The fix restores the proper search logic to prioritize partners linked to the current company first, ensuring accurate invoice processing.
Original PR description
Before fce296acd9f4187c8473ca5ae0b68fb96e9026ff, the retrieve partner function first looked for a partner with company_id = env.company.id. If a parter wasn't found, a global search without constraining `company_id` was made.
Thus, a search in a database with 2 partners with the same VAT (one has a company_id, the other not) would return the partner linked to the right company.
After fce296acd9f4187c8473ca5ae0b68fb96e9026ff, it is no longer the case. The search is done with `[('company_id', 'in', [self.env.company.id, False])`, so 2 partners are found, and none are returned.
We reintroduce that loop in this commit to fix that case.
Forward-Port-Of: odoo/odoo#163386
Forward-Port-Of: odoo/odoo#163188This fix restores the ability for employees who don't have associated user accounts to submit expenses through email aliases. A recent change inadvertently blocked this functionality, preventing these employees from creating expense reports via email. The fix ensures all employees can use the email alias feature regardless of whether they have a user account in the system.
Original PR description
[FIX] hr_expense: allow to create expenses via alias for employees not related to a user Current behavior: When trying to create an expense using alias, if a `hr.employee` not linked to a user want to, he won't be able This bug occurs after this [commit](https://github.com/odoo/odoo/commit/fbeb7aebcadbe77ff7774b538550373650b329fe) Steps to reproduce the error : - Create an employee not related to a user - Configure alias for expenses - Try to send an email to the expense's alias and check at the logs After this commit: Employees without a related user will be able to create an expense from an email alias opw-3892778 opw-3892701 opw-3893319 opw-3893591 Forward-Port-Of: odoo/odoo#163494
Portal users encountered an error when trying to filter job listings by department on the careers page. This fix adjusts access permissions so that the department filter works correctly for all users, allowing them to browse available positions by department without restrictions.
Original PR description
Problem --- When logged in as a portal user, if the `/jobs` route is configured to allow filtering by department the user gets a 403 when choosing a department to filter by and an `AccessError` is thrown for the `hr.department` model Steps --- * install website, and create a "Career" page in the wizard * on the `.../jobs` page: Editor > Edit > Customize > toggle 'Departments Filter' * log out and log in as `portal` (pw: `portal`) * go to `.../jobs` and select a department to filter by (dropdown in the topbar) * An `AccessError` is thrown Fix --- Give access rights to the responsible piece of code, so the website functions as expected. opw-3874665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162396
This update fixes deprecated escape sequence warnings that will cause errors in Python 3.12. The changes ensure the codebase remains compatible with current and future Python versions by properly escaping special characters throughout the system. This is a preventive maintenance fix that avoids future compatibility problems.
Original PR description
Since python3.12 invalid escape sequences are deprecated and this will be removed in future versions. This commit fixes all the missing escape automatically using All checks passed!. Some will be escaped, other may be replaced by r string. Another solution would be to hide the deprecation warning but this would maybe need to adapt some of the versions later leading to another forwardport hell, lets fix it one for all once we are at it. Note that ruff check will forbid to introduce new ones in any cases. Manual forward port of #61571