Monday, October 28, 2024
102 changes
17 changes
Miscellaneous changes
this commit reverts changes introduced in https://github.com/odoo/odoo/pull/183616 During reconciliation when two payment methods (cash and bank) are used simultaneously. the change amount is incorrectly deducted from the bank payment. An attempt to resolve this issue introduced further complications with payment amounts. By creating a single account move, it attempted to deduct the change amount from the cash payment, which led to inaccurate payment amounts. opw-4276421 --- I confirm
Original PR description
this commit reverts changes introduced in https://github.com/odoo/odoo/pull/183616 During reconciliation when two payment methods (cash and bank) are used simultaneously. the change amount is incorrectly deducted from the bank payment. An attempt to resolve this issue introduced further complications with payment amounts. By creating a single account move, it attempted to deduct the change amount from the cash payment, which led to inaccurate payment amounts. opw-4276421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185323 Forward-Port-Of: odoo/odoo#185291
The `move.reversed_move_id` field only represents the credit note that the user has manually created to revert a move, entirely or partially, but it doesn't take into consideration all moves reconciled through other means. We now use the method `move._get_reconciled_invoices()` which goes through all the partials to retrieve them instead. This enables also the reconciliation with the outstanding credits case to be covered. Closed 16.0 PR: odoo/odoo#119132 Task [link](https://www.odoo
Original PR description
The `move.reversed_move_id` field only represents the credit note that the user has manually created to revert a move, entirely or partially, but it doesn't take into consideration all moves reconciled through other means. We now use the method `move._get_reconciled_invoices()` which goes through all the partials to retrieve them instead. This enables also the reconciliation with the outstanding credits case to be covered. Closed 16.0 PR: odoo/odoo#119132 Task [link](https://www.odoo.com/odoo/project/967/tasks/3281816) task-3281816 Forward-Port-Of: odoo/odoo#184783
Bug introcued by this commit: https://github.com/odoo/odoo/pull/174984/commits/7bcfc3a1107650deff9dd8af02a3717304cb7d4e Steps to reproduce the bug: - Create a storable product “P1” tracked by serial number - update the qty with SN1 - Create a delivery order with SN1 - Validate it - go to the product and come back to the delivery - click on detailed operation in the move line Problem: “Unnamed” is displayed instead of the display_name of the quant opw-4279953 opw-4277630 opw-42
Original PR description
Bug introcued by this commit: https://github.com/odoo/odoo/pull/174984/commits/7bcfc3a1107650deff9dd8af02a3717304cb7d4e Steps to reproduce the bug: - Create a storable product “P1” tracked by serial number - update the qty with SN1 - Create a delivery order with SN1 - Validate it - go to the product and come back to the delivery - click on detailed operation in the move line Problem: “Unnamed” is displayed instead of the display_name of the quant opw-4279953 opw-4277630 opw-4276882 opw-4276058 opw-4252901 Forward-Port-Of: odoo/odoo#184920
Before this commit: Steps 1) Switch to DE company 2) Upload invoice using corrupted PDF (size = 0 KB) 3) Delete that invoice => It shows an error with a traceback File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 17, in <lambda> and guess_mimetype(attachment.raw) in ( File "/data/build/odoo/odoo/tools/mimetypes.py", line 156, in _odoo_guess_mimetype if bin_data.startswith(signature): AttributeError: 'bool' object has no attribute 'startswith' After this commit:
Original PR description
Before this commit: Steps 1) Switch to DE company 2) Upload invoice using corrupted PDF (size = 0 KB) 3) Delete that invoice => It shows an error with a traceback File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 17, in <lambda> and guess_mimetype(attachment.raw) in ( File "/data/build/odoo/odoo/tools/mimetypes.py", line 156, in _odoo_guess_mimetype if bin_data.startswith(signature): AttributeError: 'bool' object has no attribute 'startswith' After this commit: Invoices in l10n_de with corrupted attachments will be deleted without errors screen recording: https://drive.google.com/file/d/1TMjkwYbLZwEXyLfbSzjmDaO6jOrRk2RO/view?usp=sharing opw-4115496 Forward-Port-Of: odoo/odoo#183768
Issue: ====== We can't save address in website of latam company (peru for example) Steps to reproduce the issue: ============================= - Install ecommerce and peru localization - Change the company of the website to the peru company - Go to website add anything to cart and checkout - Edit the address - Save - Required fields missing even though there is no field with red showing a warning. Origin of the issue: ==================== In the template of the address of `l1
Original PR description
Issue: ====== We can't save address in website of latam company (peru for example) Steps to reproduce the issue: ============================= - Install ecommerce and peru localization - Change the company of the website to the peru company - Go to website add anything to cart and checkout - Edit the address - Save - Required fields missing even though there is no field with red showing a warning. Origin of the issue: ==================== In the template of the address of `l10n_pe_website_sale` we show the `partner_info` using an xpath on `vat`. But in the common template we show the VAT number on condition so when that condition is false we will have some mandatory fields missing because we didn't show them in the address form. Solution: ========= backport of https://github.com/odoo/odoo/commit/3a2eb31de39c9da162ef1bc53deb88a4c6b841f6 opw-4148782 Forward-Port-Of: odoo/odoo#180416
* STEP TO REPRODUCE: create a new uom category and add a new line -> Save. Then delete one line (uom_ids) -> raise UserError because the system force an uom category need to have at least one reference unit. * Fix by allowing to delete uom categ when it only has one single line of reference (by first delete the line and then delete the category), just like behaviour in v15 when we just make a user warning and still allow user to delete it Related forum issue: https://www.odoo.com/forum/
Original PR description
* STEP TO REPRODUCE: create a new uom category and add a new line -> Save. Then delete one line (uom_ids) -> raise UserError because the system force an uom category need to have at least one reference unit. * Fix by allowing to delete uom categ when it only has one single line of reference (by first delete the line and then delete the category), just like behaviour in v15 when we just make a user warning and still allow user to delete it Related forum issue: https://www.odoo.com/forum/help-1/unit-of-measure-categories-archive-option-255227 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#173990
**[FIX] l10n_in: Remove Enterprise Widget from Indian Electronic Waybill** **Description of the issue/feature this PR addresses:** System shows Enterprise Widget on Indian Electronic Waybill module. Although Indian Electronic Waybill is available in community addons . **Impacted versions:** * 17.0 * 18.0 **Steps to Reproduce :** - Install l10n_in module. - Now Go to the invoicing --> Configuration --> Setting. - See the Enterprise Widget is on Indian Electronic Waybill. **Curr
Original PR description
**[FIX] l10n_in: Remove Enterprise Widget from Indian Electronic Waybill** **Description of the issue/feature this PR addresses:** System shows Enterprise Widget on Indian Electronic Waybill module. Although Indian Electronic Waybill is available in community addons . **Impacted versions:** * 17.0 * 18.0 **Steps to Reproduce :** - Install l10n_in module. - Now Go to the invoicing --> Configuration --> Setting. - See the Enterprise Widget is on Indian Electronic Waybill. **Current behaviour before PR:** Enterprise Widget Should not show on Indian Electronic Waybill as it is available in community addons. **Desired behaviour after PR is merged:** After this PR merge, System will allow to install Indian Electronic Waybill module in community version. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184401
If the bank account number is not in a valid format, it is rejected by `NAV`. When that happened we returned a `(None) None: None` error message, which is not very useful. This was due to an error in xml namespace when looking for the error message. Now, we return the proper error message. We also check that the bank account number is in a valid format before sending it to `NAV` and **warn** the user. The user is still free to send the document anyway. Task-id: 4254627 --- I confirm
Original PR description
If the bank account number is not in a valid format, it is rejected by `NAV`. When that happened we returned a `(None) None: None` error message, which is not very useful. This was due to an error in xml namespace when looking for the error message. Now, we return the proper error message. We also check that the bank account number is in a valid format before sending it to `NAV` and **warn** the user. The user is still free to send the document anyway. Task-id: 4254627 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184470
When typing '>:)' in the composer, it should be replaced by '😈'. The problem is that the emoji generator doesn't work with '<', '>' because the text is escaped and the '<', '>'is replaced by '<', '>'. In this case, the regrex doesn't match. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185192 Forward-Port-Of: odoo/odoo#185091
Original PR description
When typing '>:)' in the composer, it should be replaced by '😈'. The problem is that the emoji generator doesn't work with '<', '>' because the text is escaped and the '<', '>'is replaced by '<', '>'. In this case, the regrex doesn't match. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185192 Forward-Port-Of: odoo/odoo#185091
It is currently not possible to embed the factur-x.xml in custom pdf templates, although it is supported in 17.4. In this commit, we add the possibility to to do so, by adding a system parameter "account.custom_templates_facturx_list" that contains a list of the custom report names (field `report_name` on `ir.actions.report`) for which we want to embed a factur-x.xml. We also re-introduce the extension of `_render_qweb_pdf_prepare_streams`. In addition, we add a context_key `from_account_
Original PR description
It is currently not possible to embed the factur-x.xml in custom pdf templates, although it is supported in 17.4. In this commit, we add the possibility to to do so, by adding a system parameter "account.custom_templates_facturx_list" that contains a list of the custom report names (field `report_name` on `ir.actions.report`) for which we want to embed a factur-x.xml. We also re-introduce the extension of `_render_qweb_pdf_prepare_streams`. In addition, we add a context_key `from_account_move_send` to avoid adding the Factur-X twice in case we are in the Send & Print flow (see `_hook_invoice_document_after_pdf_report_render`). See https://github.com/odoo/odoo/pull/179548 opw-4160945 Forward-Port-Of: odoo/odoo#184451
Versions -------- - 16.0 up to saas-17.4 Steps ----- 1. Add one or more lines to an SO with the same tax; 2. apply a discount coupon. Issue ----- Tax gets mentioned in the discount line name, even though it isn't really necesarry in this scenario. Cause ----- When generating the discount line description, a `tax_desc` gets added for any tax with a name. Solution -------- Only add `tax_desc` if there's more than one discount line being generated due to multiple taxes. op
Original PR description
Versions -------- - 16.0 up to saas-17.4 Steps ----- 1. Add one or more lines to an SO with the same tax; 2. apply a discount coupon. Issue ----- Tax gets mentioned in the discount line name, even though it isn't really necesarry in this scenario. Cause ----- When generating the discount line description, a `tax_desc` gets added for any tax with a name. Solution -------- Only add `tax_desc` if there's more than one discount line being generated due to multiple taxes. opw-4072437 Forward-Port-Of: odoo/odoo#183686
When the language is not in the context the report will always show the en_US version. opw-4220270 Description of the issue/feature this PR addresses: Current behavior before PR: - translation is bypassed Desired behavior after PR is merged: - report will be shown in the correct language --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184538
Original PR description
When the language is not in the context the report will always show the en_US version. opw-4220270 Description of the issue/feature this PR addresses: Current behavior before PR: - translation is bypassed Desired behavior after PR is merged: - report will be shown in the correct language --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184538
Issue --> A noticeable amount of time is spent in the method `_get_outgoing_incoming_moves` when doing the `OR` operation on the stock.move recordsets when there is a large number of moves to iterate through. Solution --> Replace the odoo recordset operations with set operations. Benchmarks --> | # of moves | Before | After | |--------|--------|--------| | 32000 | 24.08s | 1.43s | | 7300 | 1.74s | 0.40s | opw-4220302 Forward-Port-Of: odoo/odoo#185068 Forward-Port-Of: odoo/
Original PR description
Issue --> A noticeable amount of time is spent in the method `_get_outgoing_incoming_moves` when doing the `OR` operation on the stock.move recordsets when there is a large number of moves to iterate through. Solution --> Replace the odoo recordset operations with set operations. Benchmarks --> | # of moves | Before | After | |--------|--------|--------| | 32000 | 24.08s | 1.43s | | 7300 | 1.74s | 0.40s | opw-4220302 Forward-Port-Of: odoo/odoo#185068 Forward-Port-Of: odoo/odoo#183671
Adds default value to a few required selection fields as currently a value is apparently set in the form (as the select field will pick the first value) but without having the value really set in the field, meaning that on save, the field will appear as invalid. Also, to be able to select the "almost default" value, you'd need to select another value then pick the first value again to properly set it in the field and be able to save the form. To avoid those issue, we can add a default value t
Original PR description
Adds default value to a few required selection fields as currently a value is apparently set in the form (as the select field will pick the first value) but without having the value really set in the field, meaning that on save, the field will appear as invalid. Also, to be able to select the "almost default" value, you'd need to select another value then pick the first value again to properly set it in the field and be able to save the form. To avoid those issue, we can add a default value to those fields corresponding to the current "default" value in the form. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185269 Forward-Port-Of: odoo/odoo#184939
When archiving an operation in a bom, currently it will unlink if from bom lines that had it set as their `Consumed in Operation`. However, it's not the case for byproducts, meaning that the byproducts lines will still display the now archived operation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185290 Forward-Port-Of: odoo/odoo#185093
Original PR description
When archiving an operation in a bom, currently it will unlink if from bom lines that had it set as their `Consumed in Operation`. However, it's not the case for byproducts, meaning that the byproducts lines will still display the now archived operation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185290 Forward-Port-Of: odoo/odoo#185093
On small images, the actions to delete image is barely usable. In mobile, these actions are always shown, so they could even prevent clicking on attachment to view in dialog. Also on big a image the 2 actions are far away, which is can be exhausting. This commit fixes the issue by using a dropdown when there is more than 1 action or when the image is considered very small. Images visual is at most 75px width and height, so smaller images now show a background, which ensures image actions and
Original PR description
On small images, the actions to delete image is barely usable. In mobile, these actions are always shown, so they could even prevent clicking on attachment to view in dialog. Also on big a image the 2 actions are far away, which is can be exhausting. This commit fixes the issue by using a dropdown when there is more than 1 action or when the image is considered very small. Images visual is at most 75px width and height, so smaller images now show a background, which ensures image actions and clicking on image for preview are both reachable with ease, also added the required changes accordingly. task-3563828 Backport of: https://github.com/odoo/odoo/pull/180671 Forward-Port-Of: odoo/odoo#185219
HTML user menu items were escaped on the mobile client Fixes #145693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152809
Original PR description
HTML user menu items were escaped on the mobile client Fixes #145693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152809
20 changes
Enhancements to existing features
The timesheet leaderboard now labels totals with the relevant month abbreviation, making it clearer which period the figures refer to. This small wording improvement helps users interpret leaderboard results more quickly and reduces ambiguity.
Original PR description
- Change "total" to "timesheets [month abbreviation]". task-3906433
55 changes
Enhancements to existing features
The event badge printing setup now keeps only the supported 96x82mm Epson badge format and removes the unsupported 96x134mm option. Printed badge notifications also show the badge type, such as VIP or Standard, making it clearer which badge was produced.
Original PR description
in this [PR](https://github.com/odoo/odoo/pull/179903) configured two badge formats for the EPSON C4000e printer: - 96x82mm, - 96x134mm. As we don't have a dedicated proper template for the 96x134mm format, we remove it. In addition, we added the badge type (e.g. VIP, Standard, ...) in the notification displayed once a badge is printed. Tasks: 4231455, 4229143
8 changes
Resolved issues and error corrections
This update fixes a translation issue within the Spreadsheet Edition of Odoo, ensuring breadcrumb tooltips are accurately displayed in multiple languages. This improves the user experience for international users and maintains consistent branding across different locales. The change addresses a minor usability concern.
Original PR description
opw-4160838 Community: https://github.com/odoo/odoo/pull/184555
This update renames an internal controller setting from “json” to “jsonrpc” to better reflect how Odoo web requests work. It does not change how users or integrations call these features, but it reduces confusion for developers and helps prevent future misconfiguration.
Original PR description
The json type is actually Odoo-RPC over Json-RPC. The "type='json'" name has been a source of confusion for years now. Fix it. It changes nothing to the way those controller are called. It only changes the way those controllers should be defined in the source code. New occurences of `@route(type='json')` are going to raise an error for an unknown controller type. If you want a cross-version compatible thing you can do: ```py @route(type='json' if odoo.release.version_info < (18, 0) else 'jsonrpc') ``` or ```py @route(type=odoo.http.JsonRPCDispatcher.routing_type) ``` A upgrade-code script exists '18.1-02-route-jsonrpc.py', use it via the new command line: ./odoo-bin code_upgrade. task-4257153
Resolved issues and error corrections
This draft update focuses on stabilizing several automated website and document workflow checks so teams can rely on them during future releases. The current visible change touches document folder rights testing, with additional tour fixes noted as in progress across website, rental, sales, eLearning, and reporting areas.
Original PR description
.test_rental_order_with_rental_product_and_sale_product_matrix, => No longer exist :TestAddToCartSnippet.test_configure_product, => Done .test_01_automatic_editor_on_new_website, => Done **.test_08_portal_tour_archived_variant_multiple_attributes**, => Trying **.test_10_multi_checkbox_attribute,** => TODO **.test_dblclick_event_from_calendar**, => TODO **.test_course_publisher_elearning_manager**, => Problem with preview Mode (sometimes in fullscreen mode and sometimes not) .test_09_website_edit_link_popover, => TODO :TestSaleTimesheetUi.test_ui, => Should be good. :TestReportSections.test_sections_tour, => TODO .test_document_folder_rights_for_multi_company_tour, => TODO .test_02_homepage_tour_every_theme => TODO
Features or functions removed from Odoo
An obsolete internal field related to model access groups was removed from the Studio export process. This cleanup reduces maintenance overhead without changing day-to-day functionality for users.
Original PR description
odoo/odoo#185501 task-2410245
Miscellaneous changes
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter will be posted in all of the sale order's pickings. **Expected behavior:** The chatter should only be posted in the picking which was actually validated. **Steps to reproduce:** *Install delivery_dhl and l10n_be_hr_payroll* *Swap to My Belgian Company* *Duplicate the My Belgian Compan
Original PR description
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter…
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter will be posted in all of the sale order's pickings. **Expected behavior:** The chatter should only be posted in the picking which was actually validated. **Steps to reproduce:** *Install delivery_dhl and l10n_be_hr_payroll* *Swap to My Belgian Company* *Duplicate the My Belgian Company partner record, giving it new unique values where necessary (VAT, address, etc.)* 1. Create a new sale order to the copied Belgian company 2. Add some storable product and add DHL EU shipping to the order (only DHL connector working) 3. Confirm the order, and validate the delivery 4. Back on the sale order, add another order line and save 5. Validate the new delivery, see that the delivery chatter is posted on both deliveries **Cause of the issue:** The message is currently logged on `sale_id.picking_ids`. **Fix:** Change the line in question to only log the message on the currently iterated over picking, as well as any relevant, previously created ones (e.g., in a multistep route context). opw-4059145 Forward-Port-Of: odoo/enterprise#72730 Forward-Port-Of: odoo/enterprise#71441
Fix the flicker of the control panel when selecting a document. Remove the extra padding that was set around the current selection button so that its height matches the one of the other control panels buttons preventing the flicker. Task-4266281 Forward-Port-Of: odoo/enterprise#72175
Original PR description
Fix the flicker of the control panel when selecting a document. Remove the extra padding that was set around the current selection button so that its height matches the one of the other control panels buttons preventing the flicker. Task-4266281 Forward-Port-Of: odoo/enterprise#72175
before this commit, many of the url is pointing to 17.0 after this commit, the url will point to 18.0 documentation link Forward-Port-Of: odoo/enterprise#72858
Original PR description
before this commit, many of the url is pointing to 17.0 after this commit, the url will point to 18.0 documentation link Forward-Port-Of: odoo/enterprise#72858
Before this commit, since the `full_time_required_hours` field is unset on the calendar of Aaron employee, the test `/planning:TestUi.test_01_ui` fails because no progressbar is displayed for that employee in the gantt view of `planning.slot` model, meaning the employee is not supposed to work. This commit sets `full_time_required_hours` on the calendar of `Aaron` employee to display the progressbar for that employee as it was expected before the rework of flexible hours for resources. run
Original PR description
Before this commit, since the `full_time_required_hours` field is unset on the calendar of Aaron employee, the test `/planning:TestUi.test_01_ui` fails because no progressbar is displayed for that employee in the gantt view of `planning.slot` model, meaning the employee is not supposed to work. This commit sets `full_time_required_hours` on the calendar of `Aaron` employee to display the progressbar for that employee as it was expected before the rework of flexible hours for resources. runbot-99111 Forward-Port-Of: odoo/enterprise#72419
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72770 Forward-Port-Of: odoo/enterprise#
Original PR description
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72770 Forward-Port-Of: odoo/enterprise#72586
https://github.com/odoo/odoo/pull/183823 Forward-Port-Of: odoo/enterprise#72074
Original PR description
https://github.com/odoo/odoo/pull/183823 Forward-Port-Of: odoo/enterprise#72074
The groups s codes for work entry types were wrong. this commit adds the right codes for the work entry types. task-4221186 Forward-Port-Of: odoo/enterprise#71448
Original PR description
The groups s codes for work entry types were wrong. this commit adds the right codes for the work entry types. task-4221186 Forward-Port-Of: odoo/enterprise#71448
## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. ## Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notic
Original PR description
## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax…
## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. ## Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notice when the taxes has has something in the [description] field it print `<p>[description]><p>`. ## Solution: - In the `account.tax` model, the description field was changed to an HTML field with this commit: https://github.com/odoo/odoo/commit/112c68a07b817e5e9a6c01e34a0fe7238b2eaa07 - Added `_get_description_plaintext` method to convert HTML content to plaintext using `html2plaintext`. This will also ensure compatibility for future changes to the description field. related community fix: https://github.com/odoo/odoo/pull/184053 opw-4104951 Forward-Port-Of: odoo/enterprise#72529 Forward-Port-Of: odoo/enterprise#68454
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document.
Original PR description
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document. When we send the message we create the attachment but the move does not have attachment_ids set yet, so we fail to assign the first one. In this phase we just need to link the xml as the pdf will be registered when assigned as main attachment of the move opw-4088910 Forward-Port-Of: odoo/enterprise#72518 Forward-Port-Of: odoo/enterprise#69085
The shared_sign_request_tour, attempts to open some template and then click on some sign item. However it fails when it tries to click on the sign item, because it's not found. This happened because the tour sometimes open the wrong sign template (one with no items). This commit aims to fix the issue by archiving other sign templates when testing this flow. fixes runbot-98036 Forward-Port-Of: odoo/enterprise#72477
Original PR description
The shared_sign_request_tour, attempts to open some template and then click on some sign item. However it fails when it tries to click on the sign item, because it's not found. This happened because the tour sometimes open the wrong sign template (one with no items). This commit aims to fix the issue by archiving other sign templates when testing this flow. fixes runbot-98036 Forward-Port-Of: odoo/enterprise#72477
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#72746 Forward-Port-Of: odoo/enterprise#71725
Original PR description
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#72746 Forward-Port-Of: odoo/enterprise#71725
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality check smart button is not displayed, while the SN is linked to a QC. opw-4189396 Forward-Port-Of: odoo/e
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked with SN
- Create a BoM:
- no need to component
- Add an operation “OP1” with steps
- Control by product
- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1
Problem:
The quality check smart button is not displayed, while the SN is linked to a QC.
opw-4189396
Forward-Port-Of: odoo/enterprise#72693The commit intends to add tests to newly introduced functionality of marketing automation where we added whatsapp. Forward-Port-Of: odoo/enterprise#71346
Original PR description
The commit intends to add tests to newly introduced functionality of marketing automation where we added whatsapp. Forward-Port-Of: odoo/enterprise#71346
- Some are out of date/module was added since the last batch export. - Some were incorrectly manually modified - Also some cleanup of the `code` comments Forward-Port-Of: odoo/enterprise#72821
Original PR description
- Some are out of date/module was added since the last batch export. - Some were incorrectly manually modified - Also some cleanup of the `code` comments Forward-Port-Of: odoo/enterprise#72821
Add a compound index on (`res_model`, `res_id`) to support domains searching documents based on those criteria, similarly to `ir_attachment_res_idx` on `ir.attachment`. Forward-Port-Of: odoo/enterprise#72824 Forward-Port-Of: odoo/enterprise#72426
Original PR description
Add a compound index on (`res_model`, `res_id`) to support domains searching documents based on those criteria, similarly to `ir_attachment_res_idx` on `ir.attachment`. Forward-Port-Of: odoo/enterprise#72824 Forward-Port-Of: odoo/enterprise#72426
When real time measure is not linked to a device (scale), no need to add the 'Take measure' label as the user must input a value Forward-Port-Of: odoo/enterprise#72763
Original PR description
When real time measure is not linked to a device (scale), no need to add the 'Take measure' label as the user must input a value Forward-Port-Of: odoo/enterprise#72763
Resolved issues and error corrections
This fix prevents an error that could occur when the customer credit field is added to an invoice form through Studio. It updates the sales invoice logic to use the current tax total value, keeping customized invoice views from crashing.
Original PR description
Currently, a traceback occurs when the user tries to add the `partner_credit` field to the form view of the `account.move` through the studio. Error:- ``` KeyError: 'amount_total' ``` This error is…
Currently, a traceback occurs when the user tries to add the `partner_credit` field to the form view of the `account.move` through the studio. Error:- ``` KeyError: 'amount_total' ``` This error is occurring because the `amount_total` was removed from the `tax_taotals` from the commit [1]. A major refactor was done to compute the tax_totals from [1] [1] https://github.com/odoo/odoo/commit/d0e7be7832672d476f1b289af52d3a425990d719 We can resolve this issue by taking the `total_amount_currency` from tax_totals Note:- However, the actual problem was the field and the compute method itself. Initially the field `partner_credit` was used for building the warning from [2] [2] https://github.com/odoo/odoo/commit/7bd93cc64b582cdd559a6b6f855c1950a992df68#diff-1e3bd6be3bfb83a37ec9fb800ce8b1c95afe0be90ff792874ae7299c320a2f6eR1383 But later it was removed from the commit [3] [3] https://github.com/odoo/odoo/pull/126575/commits/32954ca0ae54752073c7b5ae46793d1f2e34f0d1#diff-1e3bd6be3bfb83a37ec9fb800ce8b1c95afe0be90ff792874ae7299c320a2f6eL1416 So the field `partner_credit` was neither used in the Python side nor used in the XML side also. which is completely dead code and has never been executed. We should remove both the field and compute method in the master sentry-5987829118
The product demo import templates have been updated so they match the current product fields and sample data. This prevents users from running into errors when using the provided spreadsheet templates and adds a safeguard to keep them valid in future updates.
Original PR description
The demo import templates of the product module were not adapted to recent changes to fields and demo data. This commit makes sure the xls are valid, and adds a test to ensure they are adapted in the future when needed. Fixes #185430
The product import template has been corrected to use the current "Goods" product type instead of the outdated "consumable" value. This prevents import failures when users download the sample template and import it back into Odoo.
Original PR description
before this commit, in the import template of product the type is recorded as consumable, which is no longer valid and when user try to import into system the import will be valid * open import for product * export the import template * import it back, import wont work after this commit, the given sample template is update with Goods instead of consumable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates several help and documentation links so they open the Odoo 18.0 documentation instead of the older 17.0 pages. Users are less likely to land on outdated guidance when looking for product, website link, or localization documentation.
Original PR description
before this commit, many of the url is pointing to 17.0 after this commit, the url will point to 18.0 documentation link Enterprise: https://github.com/odoo/enterprise/pull/72858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A small typo in an automated test setup was corrected so invoice-related snail mail tests run reliably again. This helps maintain confidence that sending invoices by post still works for partners who do not have an email address.
Original PR description
Since pr https://github.com/odoo/odoo/commit/9e769e1b11f2 there was a typo, causing tests to break because value of country_id was missing .id at the end. This commit fixes the issue.
Selected course tags now keep their intended colors when learners filter courses, instead of appearing plain until hovered. This makes the course filtering experience clearer and more consistent with the main course listing page.
Original PR description
After this commit https://github.com/odoo/odoo/commit/b4a5bf03cd81ece2a7fd21a3c5a058ee2d3336fe , we have to hover on tags to see solid/bg colors. Here, the selected tag's color is 'primary' but due to hovering behavior, it will display similar to `o_color_0`, unless user hover on the tag. This PR modify selected tags colors to `tag.color` used in 'All courses' page Task-4274049
Fixed an issue that prevented users from downloading payment receipts in certain vendor payment setups. The receipt now uses the correct payment reference information, avoiding an error page and allowing accounting teams to retrieve receipts as expected.
Original PR description
1. Create a new Account called "Outstanding Payment". 2. Create a new Bank Journal and adde the new account in the Outgoing Payment tab. 3. Create a Vendor Bill, add partner details, product, date and confirm. 4. Process the payment using the newly created Bank Journal. 5. Opened the payment record. 6. Attempted to download the payment receipt. Traceback will raise ``` odoo.addons.base.models.ir_qweb.QWebException: Error while render the template KeyError: 'memo' Template: account.report_payment_receipt_document Path: /t/t/div[1]/table/tbody/t/t/tr[2]/td[3]/span Node: <span t-field="payment.move_id.memo"/> ``` It occurs because the field `memo` is defined on the payment and not on the move opw-4280508
This update adjusts several automated website and messaging test flows so they first move over page elements before clicking them. This helps ensure the elements are visible and ready, reducing false test failures without changing customer-facing functionality.
Original PR description
In this commit, we use "hover" action in run to ensure element are visible before clicking on it.[REF] brol 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
Spreadsheet pivots now avoid reloading data when users add or remove computed measures, because those changes do not require fetching data again. This improves responsiveness while still refreshing data when real source measures are added, removed, or changed.
Original PR description
Before this commit, the pivot was reloaded even when the user add or remove a computed measure, which does not require a new data fetch. With this commit, the data is only re-fetched only when the user makes some changes on the measures that require a new data fetch: - Add/remove a non-computed measure - Update the fieldName or aggregator of a non-computed measure Task: 4210672 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 website SEO optimization screen no longer crashes when a blog's name has been removed. This helps website editors continue managing SEO settings reliably even when blog details are incomplete.
Original PR description
Steps to reproduce: --- - Install the ``website_blog`` module - Click on ``Blog`` > Open editor > Click on blog name(eg: Travel) - Remove that blog name and Save Traceback: --- ``TypeErrornormalize() argument 2 must be str, not bool`` This error comes after this commit https://github.com/odoo/odoo/commit/25abac896f53240b08dd38a89110ec811132ee1d Previous Behaviour: --- When trying to open optimize SEO without a blog name at [1] we are getting ``record.display_name`` as false. [1]- https://github.com/odoo/odoo/blob/e4a4806e5c58c599815204a73c78a228ee230613/addons/website/controllers/main.py#L785-L786 sentry-5967410495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Half-day time off entries now show the correct duration in calendar and Gantt reports instead of being reduced to an incorrect "00 hours" label. This helps HR users read leave schedules accurately when employee names are hidden.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a half-day leave of any type allowing custom hours; 2. open All Time Off in Gantt view. Issue ----- Leave is displayed as "00 hours". Cause ----- PR #177570 changed the way leave hours are displayed, from decimal to HH:MM. With the `hide_employee_name` context value set, the name of `hr.leave.report.calendar` records was computed by splitting on `':'`, and taking the last part. Before the hour formatting change, this was everything after the employee name. After the formatting change, only the "MM" part remains. Solution -------- We can remove the `_fetch_query` override which updates names in cache only, and instead add a `_compute_display_name` override, in turn using the `removeprefix` method added in Python 3.9 to reliably strip the employee name. opw-4274365
This fix prevents an error when a website page title is cleared and the page properties are saved. Users can now save changes without seeing a traceback, improving reliability in the website editor.
Original PR description
When the user tries to save page properties without a Page Title, a traceback will appear. Steps to reproduce the error: - Go to Website > Site > Properties > Remove the Page Title > Save & Close…
When the user tries to save page properties without a Page Title,
a traceback will appear.
Steps to reproduce the error:
- Go to Website > Site > Properties > Remove the Page Title > Save & Close
Traceback:
```
TypeError: normalize() argument 2 must be str, not bool
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 70, in web_save
self.write(vals)
File "addons/website/models/website_page_properties.py", line 179, in write
write_result = super().write(vals)
File "odoo/models.py", line 4786, in write
fields[0].determine_inverse(real_recs)
File "odoo/fields.py", line 1478, in determine_inverse
determine(self.inverse, records)
File "odoo/fields.py", line 112, in determine
return needle(records, *args)
File "odoo/fields.py", line 724, in _inverse_related
target[field.name] = record_value[record]
File "odoo/models.py", line 7009, in __setitem__
return self._fields[key].__set__(self, value)
File "odoo/fields.py", line 1402, in __set__
records.write({self.name: write_value})
File "addons/website/models/website_page.py", line 158, in write
vals['key'] = self.env['website'].with_context(website_id=website_id).get_unique_key(self.env['ir.http']._slugify(vals['name']))
File "odoo/addons/base/models/ir_http.py", line 161, in _slugify
return cls._slugify_one(value, max_length=max_length)
File "odoo/addons/base/models/ir_http.py", line 154, in _slugify_one
uni = unicodedata.normalize('NFKD', value).encode('ascii', 'ignore').decode('ascii')
```
This error generates after this commit: https://github.com/odoo/odoo/commit/58705803a9e7ef0b0f5ff9e8b82d52ad1321b64a
https://github.com/odoo/odoo/blob/4b99aa4e48158ddc7cea8910c0f610e62778bc9c/addons/website/models/website_page.py#L158
When, user tries to save page properties without a page title,
``vals['name']`` will be False,
So, It will lead to the above traceback.
sentry-5989403584
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prZero-rated supplies under LUT will now appear correctly as exports without payment of tax in the GSTR spreadsheet. This fixes a reporting classification issue caused by unnecessary IGST tags, helping Indian localization tax reports better match expected GST treatment.
Original PR description
In GSTR spreadsheet the zero-rated supplies under lut are shown as `wopay` export type, earlier it was showing as `wpay` due to igst tags being applied on zero-rated lut taxes, that are unnecessary and as we don't need this items for gstr calculations hence igst tags are removed from this taxes. task-4263013
This change prevents an error when users edit and save email-related rich text fields in Safari on iOS, such as email signatures or quotation email subjects. It improves reliability for Safari users by ignoring a browser-unsupported formatting rule that could block saving.
Original PR description
Issue On Safari iOS, editing `html_mail` fields (such as "Email signature" in user profile or "Subject" in Quotation send by mail) throws an error: `@page is not a valid selector` at save. Change Add `@page` to the list of ignored selectors as it was done in commit 7b68c9eaf8ad94ecbcc3893bf6cc220b7e9b6636 as it is currently not supported by all browsers. opw-4256252
Fixes an issue in Manufacturing where clicking a subcontracting line in the bill of materials overview could show an error pop-up. Users can now expand subcontracting details smoothly, reducing interruptions when reviewing production setup.
Original PR description
When the user clicks on a subcontracting line in the BOM overview, an error is raised. This occurs because we are passing false when subcontracting lines are not folded, but a function is expected. The solution is to pass a function, which should be a void function when toggleFolded is false. Steps to Reproduce: 1. Go to the Manufacturing app. 2. Enable the Subcontracting feature in the Settings tab. 3. Navigate to the BoM overview in the Products tab. 4. Open a BoM that includes subcontracting. 5. Click to expand the subcontracting line. Previous Behaviour: An error pop-up appears. Current Behaviour: Opens without any error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents project scheduling tests from failing when the HR app is not installed. HR-dependent test coverage is moved to the HR-specific project module, keeping automated checks reliable without changing customer-facing behavior.
Original PR description
## [FIX] project_enterprise: avoid creating employee in test Before this commit, `:TestSmartSchedule.test_multi_users_tasks` test in `project_enterprise` module creates 2 employees but the problem is `hr` module is not in the dependencies of `project_enterprise` and so that test fails when `hr` is not installed. This commit adapts the test to make sure to not create any employees inside that test. ## [FIX] project_enterprise_hr: adds test_smart_schedule test Before this commit, the `test_multi_users_tasks` test defined in `/project_enterprise:TestSmartSchedule` failed when `hr` module is not installed since that test create 2 employees. This commit moves the test in `project_enterprise_hr` to make sure the test works as expected and we can create employee since `hr` is in the dependencies of `project_enterprise_hr` module. runbot-76567
Selecting a document no longer causes the control panel to visually flicker. The selection button now matches the height of neighboring buttons, creating a smoother and more stable experience for users.
Original PR description
Fix the flicker of the control panel when selecting a document. Remove the extra padding that was set around the current selection button so that its height matches the one of the other control panels buttons preventing the flicker. Task-4266281
This fix ensures Belgian payroll group sequence values are properly checked against the allowed maximum length. It prevents invalid sequence data from passing validation, reducing the risk of payroll export errors.
Original PR description
The check for the sequence of the group_s was always true because the length was not compared. Now it is compared to the max length of the sequence. task-4203261
Documentation links across several Odoo Enterprise modules have been corrected to point to the 18.0 documentation instead of the older 17.0 pages. This helps users access the right guidance for their current version and reduces confusion when following help links.
Original PR description
before this commit, many of the url is pointing to 17.0 after this commit, the url will point to 18.0 documentation link
Code cleanup and technical improvements
This change simplifies the internal structure used to run automated web tours by removing an extra conversion step. It should make the tour code easier for developers to understand and maintain, without changing the user-facing behavior of Odoo.
Original PR description
In this commit, we remove compileToMacro method from TourStepAutomatic class. The compileToMacro method complicates the understanding of how tours work. It is more obvious and above all simpler to directly return an object corresponding to the macro input (in TourAutomatic) rather than going through nested method calls. It also makes the TourStepAutomatic and TourAutomatic classes simpler and more understandable. (And this allows you to only have methods of less than 60 lines) 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
Documentation and clarification updates
This pull request records the contributor license agreement signature for rom10811. It is an administrative compliance update that helps ensure contributions can be accepted under Odoo's contribution rules.
Original PR description
Description of the issue/feature this PR addresses: CLA sign for rom10811 Current behavior before PR: CLA not signed Desired behavior after PR is merged: CLA signed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Whe the user clicks on a subcontracting line in the BOM overview, an error is raised. This occurs because we are passing false when subcontracting lines are not folded, but a function is expected. The solution is to pass a function, which should be a void function when toggleFolded is false. Steps to reproduce: 1. Go to the Manufacturing app. 2. Enable the Subcontracting feature in the Setting tab. 3. Navigate to the BoM overview in the Products tab. 4. Open a BoM that includes subcontrac
Original PR description
Whe the user clicks on a subcontracting line in the BOM overview, an error is raised. This occurs because we are passing false when subcontracting lines are not folded, but a function is expected. The solution is to pass a function, which should be a void function when toggleFolded is false. Steps to reproduce: 1. Go to the Manufacturing app. 2. Enable the Subcontracting feature in the Setting tab. 3. Navigate to the BoM overview in the Products tab. 4. Open a BoM that includes subcontracting. 5. Click to expand the subcontracting line. Previous behaviour: An error pop-up appears. Current behaviour: Opens without any error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185467
When typing '>:)' in the composer, it should be replaced by '😈'. The problem is that the emoji generator doesn't work with '<', '>' because the text is escaped and the '<', '>'is replaced by '<', '>'. In this case, the regrex doesn't match. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185332 Forward-Port-Of: odoo/odoo#185091
Original PR description
When typing '>:)' in the composer, it should be replaced by '😈'. The problem is that the emoji generator doesn't work with '<', '>' because the text is escaped and the '<', '>'is replaced by '<', '>'. In this case, the regrex doesn't match. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185332 Forward-Port-Of: odoo/odoo#185091
When the language is not in the context the report will always show the en_US version. opw-4220270 Description of the issue/feature this PR addresses: Current behavior before PR: - translation is bypassed Desired behavior after PR is merged: - report will be shown in the correct language --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184538
Original PR description
When the language is not in the context the report will always show the en_US version. opw-4220270 Description of the issue/feature this PR addresses: Current behavior before PR: - translation is bypassed Desired behavior after PR is merged: - report will be shown in the correct language --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184538
**Prior to this commit:** - While configuring a pricelist, if we don't select any website in the Website field, the placeholder let us think that it should be applied on 'All websites'. **Post this commit:** - The placeholder is renamed as 'Select a website' as the pricelist doesn't apply to any website when the field is empty. **Affected version:** saas-17.4~master **opw**-4256656 Forward-Port-Of: odoo/odoo#185045
Original PR description
**Prior to this commit:** - While configuring a pricelist, if we don't select any website in the Website field, the placeholder let us think that it should be applied on 'All websites'. **Post this commit:** - The placeholder is renamed as 'Select a website' as the pricelist doesn't apply to any website when the field is empty. **Affected version:** saas-17.4~master **opw**-4256656 Forward-Port-Of: odoo/odoo#185045
Before this commit, the sales team could be missing from an order captured as draft due to writing a false value. opw-4230882 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184949
Original PR description
Before this commit, the sales team could be missing from an order captured as draft due to writing a false value. opw-4230882 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184949
This commit fixes an issue where the dynamic placeholder popover would not fully close upon pressing escape or clicking on the cross when a relation field was selected. This is because its previous condition for changing state instead of closing was if it had some field path selected upon closing the model field selector popover. This would not handle well the case where a relation is selected before closing. The fix is therefore to specify inside calls to the close function of the model field s
Original PR description
This commit fixes an issue where the dynamic placeholder popover would not fully close upon pressing escape or clicking on the cross when a relation field was selected. This is because its previous condition for changing state instead of closing was if it had some field path selected upon closing the model field selector popover. This would not handle well the case where a relation is selected before closing. The fix is therefore to specify inside calls to the close function of the model field selector popover whether it closed because a final value was selected or not. task-4066184 Forward-Port-Of: odoo/odoo#184907 Forward-Port-Of: odoo/odoo#184838
Issue: ====== Empty inline code block isn't working as expected and produces issues in the following flows: First Flow: - Create a note - Add ` 2 times - Delete forward 2 times - The button send message is modified!! Second Flow: - Log a note in the chatter of the note - Open composer - Add ` 2 times - Delete forwart 2 times - Traceback Origin of the issue: ===================== After adding the {backtick} 2 times, it will have the following html `<p>{backtick}[]<code cla
Original PR description
Issue: ====== Empty inline code block isn't working as expected and produces issues in the following flows: First Flow: - Create a note - Add ` 2 times - Delete forward 2 times - The button send…
Issue:
======
Empty inline code block isn't working as expected and produces issues in
the following flows:
First Flow:
- Create a note
- Add ` 2 times
- Delete forward 2 times
- The button send message is modified!!
Second Flow:
- Log a note in the chatter of the note
- Open composer
- Add ` 2 times
- Delete forwart 2 times
- Traceback
Origin of the issue:
=====================
After adding the {backtick} 2 times, it will have the following html
`<p>{backtick}[]<code class="o_inline_code">{backtick}</code></p>` which
is not the expected behavior. now after delete forward we will have the
following html
`<p>{backtick}[]<code class="o_inline_code" data-oe-zws-empty-inline></code></p>`
now we delete forward again it will delete the inline block which
validate the following condition [1] which forces a deleteForward in the
parent element at offset one which is basically here
`<p>{backtick}[]<p>` which now will reach this part of code [2] and the
`findNode` will return a node outside the editable because we didn't
specify the `root` element as a stopping condition.
Solution:
=========
- First we fix the spec of the inline code block which should do nothing
in case there is no content inside it.
- We add the root as stopping condition while generating the path.
[1]: https://github.com/odoo/odoo/blob/16.0/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L125-L143
[2]: https://github.com/odoo/odoo/blob/d0828eecf60f7c8622d6875b8651eb663bc7d695/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L214-L241
opw-4254182
Forward-Port-Of: odoo/odoo#183567Issue: ===== FontSize isn't being applied on table selection. Steps to reproduce the issue: ============================= - Create a new to do - Add a table - Add content in some cells - Select from the middle of the content of the first cell to the middle of the content of the last cell - Apply font size - Nothing happens Origin of the issue: ==================== When we have `useResponsiveFontSizes` enabled, we first set the fontSize with undefined and then we set the font
Original PR description
Issue: ===== FontSize isn't being applied on table selection. Steps to reproduce the issue: ============================= - Create a new to do - Add a table - Add content in some cells - Select from the middle of the content of the first cell to the middle of the content of the last cell - Apply font size - Nothing happens Origin of the issue: ==================== When we have `useResponsiveFontSizes` enabled, we first set the fontSize with undefined and then we set the fontSizeClassName, but in the first execCommand we trigger `historyStep` event. The event is handled by the `html_field` and it will check if the field is dirty. In the process of checking we call `getValue` of `Wysiwyg`. `getValue` will run `cleanForSave` on the editor which will deselect tables. Solution: ========= We reset the selection after the first execCommand. opw-4237983 Forward-Port-Of: odoo/odoo#184104
Changing bootstrap versions caused a change in how the color for the alert-link class was being chosen which broke something with pdf reports. A change was then made to fix pdf reports but this ended up breaking alert-links elsewhere in Odoo and the light mode colors for alert-links were being used in dark mode. This change moves the styling to a report specific scss file to resolve the issue in the backend. Here is the aforementioned change: https://github.com/odoo/odoo/pull/178824
Original PR description
Changing bootstrap versions caused a change in how the color for the alert-link class was being chosen which broke something with pdf reports. A change was then made to fix pdf reports but this ended up breaking alert-links elsewhere in Odoo and the light mode colors for alert-links were being used in dark mode. This change moves the styling to a report specific scss file to resolve the issue in the backend. Here is the aforementioned change: https://github.com/odoo/odoo/pull/178824 opw-[4211334](https://www.odoo.com/web#id=4211334&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#182692
**[FIX] l10n_in: Remove Enterprise Widget from Indian Electronic Waybill** **Description of the issue/feature this PR addresses:** System shows Enterprise Widget on Indian Electronic Waybill module. Although Indian Electronic Waybill is available in community addons . **Impacted versions:** * 17.0 * 18.0 **Steps to Reproduce :** - Install l10n_in module. - Now Go to the invoicing --> Configuration --> Setting. - See the Enterprise Widget is on Indian Electronic Waybill. **Curr
Original PR description
**[FIX] l10n_in: Remove Enterprise Widget from Indian Electronic Waybill** **Description of the issue/feature this PR addresses:** System shows Enterprise Widget on Indian Electronic Waybill module. Although Indian Electronic Waybill is available in community addons . **Impacted versions:** * 17.0 * 18.0 **Steps to Reproduce :** - Install l10n_in module. - Now Go to the invoicing --> Configuration --> Setting. - See the Enterprise Widget is on Indian Electronic Waybill. **Current behaviour before PR:** Enterprise Widget Should not show on Indian Electronic Waybill as it is available in community addons. **Desired behaviour after PR is merged:** After this PR merge, System will allow to install Indian Electronic Waybill module in community version. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184401
The `move.reversed_move_id` field only represents the credit note that the user has manually created to revert a move, entirely or partially, but it doesn't take into consideration all moves reconciled through other means. We now use the method `move._get_reconciled_invoices()` which goes through all the partials to retrieve them instead. This enables also the reconciliation with the outstanding credits case to be covered. Closed 16.0 PR: odoo/odoo#119132 Task [link](https://www.odoo
Original PR description
The `move.reversed_move_id` field only represents the credit note that the user has manually created to revert a move, entirely or partially, but it doesn't take into consideration all moves reconciled through other means. We now use the method `move._get_reconciled_invoices()` which goes through all the partials to retrieve them instead. This enables also the reconciliation with the outstanding credits case to be covered. Closed 16.0 PR: odoo/odoo#119132 Task [link](https://www.odoo.com/odoo/project/967/tasks/3281816) task-3281816 Forward-Port-Of: odoo/odoo#184783
Steps to reproduce: Make a regular allocation for a time off type that can be taken in hours for an employee that has a working schedule other than standard 40h/week, and click save. The number of hours is updated to an amount different to what was entered. The issue is that https://github.com/odoo/odoo/pull/163711 changes the computation of number of hours to only work with the standard `HOURS_PER_DAY` without considering the employee's schedule, meanwhile `_compute_number_of_days` still
Original PR description
Steps to reproduce: Make a regular allocation for a time off type that can be taken in hours for an employee that has a working schedule other than standard 40h/week, and click save. The number of hours is updated to an amount different to what was entered. The issue is that https://github.com/odoo/odoo/pull/163711 changes the computation of number of hours to only work with the standard `HOURS_PER_DAY` without considering the employee's schedule, meanwhile `_compute_number_of_days` still takes the employee's schedule into account, causing an inconsistency leading to the bug. This commit, makes the computation of days and hours consistent, so at least the amount entered is kept. opw-4190998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180630
Steps to reproduce: - Drop the "Team" snippet and toggle it to grid mode. - Change the grid items padding with the "Padding (Y, X)" option. => The `o_we_padding_highlight` class used to show the padding preview is also added on the inner row of the grid items. This happens because the `data-apply-to` attribute of this option targets the `.row` elements in general, instead of only the grid mode one (so having the `o_grid_mode` class). This commit fixes this issue by changing this attribut
Original PR description
Steps to reproduce: - Drop the "Team" snippet and toggle it to grid mode. - Change the grid items padding with the "Padding (Y, X)" option. => The `o_we_padding_highlight` class used to show the padding preview is also added on the inner row of the grid items. This happens because the `data-apply-to` attribute of this option targets the `.row` elements in general, instead of only the grid mode one (so having the `o_grid_mode` class). This commit fixes this issue by changing this attribute, by patching the template in JS as a stable fix. Note that in above versions, the padding option changed so this fix will not be needed (but other grid options will need a similar fix). task-4247543 Forward-Port-Of: odoo/odoo#185201 Forward-Port-Of: odoo/odoo#183219
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached. ### Fix: Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering. Setting `drag_and_drop` tour in Monthly Calendar v
Original PR description
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on…
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached. ### Fix: Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering. Setting `drag_and_drop` tour in Monthly Calendar view to avoid issues caused by potential `drag_and_drop` behaviour changes. In Monthly Calendar view, some days from previous and following months are visible, with a maximum of 6 before (Feb 23, see Mar 2025) and 14 after (Mar 14, see Feb 2026). Initial date being set in the backend, it does not have to respect those limitations. Changes operated in the frontend are bound to these and must be set between 15 and 22 included with the current selector. runbot-error-65494 Forward-Port-Of: odoo/odoo#185196 Forward-Port-Of: odoo/odoo#166502
If the bank account number is not in a valid format, it is rejected by `NAV`. When that happened we returned a `(None) None: None` error message, which is not very useful. This was due to an error in xml namespace when looking for the error message. Now, we return the proper error message. We also check that the bank account number is in a valid format before sending it to `NAV` and **warn** the user. The user is still free to send the document anyway. Task-id: 4254627 --- I confirm
Original PR description
If the bank account number is not in a valid format, it is rejected by `NAV`. When that happened we returned a `(None) None: None` error message, which is not very useful. This was due to an error in xml namespace when looking for the error message. Now, we return the proper error message. We also check that the bank account number is in a valid format before sending it to `NAV` and **warn** the user. The user is still free to send the document anyway. Task-id: 4254627 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184470
* STEP TO REPRODUCE: create a new uom category and add a new line -> Save. Then delete one line (uom_ids) -> raise UserError because the system force an uom category need to have at least one reference unit. * Fix by allowing to delete uom categ when it only has one single line of reference (by first delete the line and then delete the category), just like behaviour in v15 when we just make a user warning and still allow user to delete it Related forum issue: https://www.odoo.com/forum/
Original PR description
* STEP TO REPRODUCE: create a new uom category and add a new line -> Save. Then delete one line (uom_ids) -> raise UserError because the system force an uom category need to have at least one reference unit. * Fix by allowing to delete uom categ when it only has one single line of reference (by first delete the line and then delete the category), just like behaviour in v15 when we just make a user warning and still allow user to delete it Related forum issue: https://www.odoo.com/forum/help-1/unit-of-measure-categories-archive-option-255227 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#173990
This is a complement of previous fix: https://github.com/odoo/odoo/commit/792773296fce27340bf866fef8a6f6e8969b682e Add the company of the move in the context as it is possible that the company of the move and the current company are different. opw-4227241 Related enterprise PR: https://github.com/odoo/enterprise/pull/71725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185204 Forward-Port-Of: odoo/odoo#1850
Original PR description
This is a complement of previous fix: https://github.com/odoo/odoo/commit/792773296fce27340bf866fef8a6f6e8969b682e Add the company of the move in the context as it is possible that the company of the move and the current company are different. opw-4227241 Related enterprise PR: https://github.com/odoo/enterprise/pull/71725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185204 Forward-Port-Of: odoo/odoo#185096
We improved in 17.3/17.4 the Customer Invoice form view, and one of the changes where hiding the Payment Reference field. See https://github.com/odoo/odoo/commit/112c68a07b817e5e9a6c01e34a0fe7238b2eaa07 The rationale was: as it's most often generated by Odoo, let's not clutter the interface with a field that is left open most of the time. While this is true, in some cases people need to manage them by hand, for example when they import invoices, or they use specific formats not yet handled by
Original PR description
We improved in 17.3/17.4 the Customer Invoice form view, and one of the changes where hiding the Payment Reference field. See https://github.com/odoo/odoo/commit/112c68a07b817e5e9a6c01e34a0fe7238b2eaa07 The rationale was: as it's most often generated by Odoo, let's not clutter the interface with a field that is left open most of the time. While this is true, in some cases people need to manage them by hand, for example when they import invoices, or they use specific formats not yet handled by Odoo. This commit restores the field in the Other Info tab for those cases. Task: 4276812 Forward-Port-Of: odoo/odoo#185036
Steps to reproduce: ==== - Create a quotation and confirm it. - Open Point of Sale. - Load the order in POS. - Choose option Apply a down payment(percentage). - Insert 50. - Do payment and again place new order. - Select the same Quotation and do same 50% down payment. Issue: ==== - Next time value should be calculated from due balance not from initial total amount of the quotation. Fix: ==== - Instead of total_amount , now amount_unpaid is used. task- 4231244 Forward-Port-
Original PR description
Steps to reproduce: ==== - Create a quotation and confirm it. - Open Point of Sale. - Load the order in POS. - Choose option Apply a down payment(percentage). - Insert 50. - Do payment and again place new order. - Select the same Quotation and do same 50% down payment. Issue: ==== - Next time value should be calculated from due balance not from initial total amount of the quotation. Fix: ==== - Instead of total_amount , now amount_unpaid is used. task- 4231244 Forward-Port-Of: odoo/odoo#185255 Forward-Port-Of: odoo/odoo#182542
Delete the ad site, this site is pornographic 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
Original PR description
Delete the ad site, this site is pornographic 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
Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notice w
Original PR description
Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions…
Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notice when the taxes has has something in the [description] field it print `<p>[description]><p>`. Solution: - In the `account.tax` model, the description field was changed to an HTML field with this commit: https://github.com/odoo/odoo/commit/112c68a - Added `_get_description_plaintext` method to convert HTML content to plaintext using `html2plaintext`. This will also ensure compatibility for future changes to the description field. - related enterprise fix: https://github.com/odoo/enterprise/pull/68454 opw-4104951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184053
As the portal user, change your profile picture to a svg image, then show it via the normal /web/image URL. The downloaded picture lacks a valid content-type header. Related stored attachment fields were served via the method `Stream.from_binary_field` instead of `Stream.from_attachment`, only the latter is capable of copying the attachment mimetype on the stream. --- Also gave a shot at making the `odoo-bin --test-tags webserver:TestHttpStaticWebServer` test green again. Forward-Port-
Original PR description
As the portal user, change your profile picture to a svg image, then show it via the normal /web/image URL. The downloaded picture lacks a valid content-type header. Related stored attachment fields were served via the method `Stream.from_binary_field` instead of `Stream.from_attachment`, only the latter is capable of copying the attachment mimetype on the stream. --- Also gave a shot at making the `odoo-bin --test-tags webserver:TestHttpStaticWebServer` test green again. Forward-Port-Of: odoo/odoo#184667 Forward-Port-Of: odoo/odoo#177105
Bug introcued by this commit: https://github.com/odoo/odoo/pull/174984/commits/7bcfc3a1107650deff9dd8af02a3717304cb7d4e Steps to reproduce the bug: - Create a storable product “P1” tracked by serial number - update the qty with SN1 - Create a delivery order with SN1 - Validate it - go to the product and come back to the delivery - click on detailed operation in the move line Problem: “Unnamed” is displayed instead of the display_name of the quant opw-4279953 opw-4277630 opw-42
Original PR description
Bug introcued by this commit: https://github.com/odoo/odoo/pull/174984/commits/7bcfc3a1107650deff9dd8af02a3717304cb7d4e Steps to reproduce the bug: - Create a storable product “P1” tracked by serial number - update the qty with SN1 - Create a delivery order with SN1 - Validate it - go to the product and come back to the delivery - click on detailed operation in the move line Problem: “Unnamed” is displayed instead of the display_name of the quant opw-4279953 opw-4277630 opw-4276882 opw-4276058 opw-4252901 Forward-Port-Of: odoo/odoo#184920
Before this commit: Steps 1) Switch to DE company 2) Upload invoice using corrupted PDF (size = 0 KB) 3) Delete that invoice => It shows an error with a traceback File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 17, in <lambda> and guess_mimetype(attachment.raw) in ( File "/data/build/odoo/odoo/tools/mimetypes.py", line 156, in _odoo_guess_mimetype if bin_data.startswith(signature): AttributeError: 'bool' object has no attribute 'startswith' After this commit:
Original PR description
Before this commit: Steps 1) Switch to DE company 2) Upload invoice using corrupted PDF (size = 0 KB) 3) Delete that invoice => It shows an error with a traceback File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 17, in <lambda> and guess_mimetype(attachment.raw) in ( File "/data/build/odoo/odoo/tools/mimetypes.py", line 156, in _odoo_guess_mimetype if bin_data.startswith(signature): AttributeError: 'bool' object has no attribute 'startswith' After this commit: Invoices in l10n_de with corrupted attachments will be deleted without errors screen recording: https://drive.google.com/file/d/1TMjkwYbLZwEXyLfbSzjmDaO6jOrRk2RO/view?usp=sharing opw-4115496 Forward-Port-Of: odoo/odoo#183768
Using a computed field that perform external API calls to decide about when to hide UI elements is problematic. If the external API is unreachable this will raise an exception each time users try to open the form view. If the API is slow this will also cause general slow downs for users. Finally during upgrades this causes unnecessary failures because the upgrade process is run without external internet access. This is partial revert of odoo/odoo@edf1a7d This issue blocks multiple up
Original PR description
Using a computed field that perform external API calls to decide about when to hide UI elements is problematic. If the external API is unreachable this will raise an exception each time users try to open the form view. If the API is slow this will also cause general slow downs for users. Finally during upgrades this causes unnecessary failures because the upgrade process is run without external internet access. This is partial revert of odoo/odoo@edf1a7d This issue blocks multiple upgrades to 17.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184151
The `use_create_lots` field was missing in the parent view after this https://github.com/odoo/odoo/pull/137031/commits/ecc6a3c0776501ca79604af21fd5515f74f6b7e8#diff-7a1e0a179b7361b04b4bb165dbfc18fabd2fc972ff190fbf21144db03f9b86b1L139 , causing a silent failure in the `options` condition for allowing users to create new lots/serial numbers. As a result, users were unable to add serial numbers during receipt creation because the condition `options="{'create': [('parent.use_create_lots', '=', True)
Original PR description
The `use_create_lots` field was missing in the parent view after this…
The `use_create_lots` field was missing in the parent view after this https://github.com/odoo/odoo/pull/137031/commits/ecc6a3c0776501ca79604af21fd5515f74f6b7e8#diff-7a1e0a179b7361b04b4bb165dbfc18fabd2fc972ff190fbf21144db03f9b86b1L139 , causing a silent failure in the `options` condition for allowing users to create new lots/serial numbers. As a result, users were unable to add serial numbers during receipt creation because the condition `options="{'create': [('parent.use_create_lots', '=', True)]}"` was never met.
Steps to reproduce the error:
1. Create a new product with lot/serial number tracking.
2. Create a receipt for that product.
3. Try to add serial numbers to the receipt.
The expected behavior is to be able to add serial numbers, but users were blocked from doing so due to the missing field.
To resolve this, the `use_create_lots` field has been added to the parent view, ensuring that the condition for allowing lot creation works as expected.
opw-4150626
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#184431**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter will be posted in all of the sale order's pickings. **Expected behavior:** The chatter should only be posted in the picking which was actually validated. **Steps to reproduce:** *Install delivery_dhl and l10n_be_hr_payroll* *Swap to My Belgian Company* *Duplicate the My Belgian Compan
Original PR description
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter…
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter will be posted in all of the sale order's pickings. **Expected behavior:** The chatter should only be posted in the picking which was actually validated. **Steps to reproduce:** *Install delivery_dhl and l10n_be_hr_payroll* *Swap to My Belgian Company* *Duplicate the My Belgian Company partner record, giving it new unique values where necessary (VAT, address, etc.)* 1. Create a new sale order to the copied Belgian company 2. Add some storable product and add DHL EU shipping to the order (only DHL connector working) 3. Confirm the order, and validate the delivery 4. Back on the sale order, add another order line and save 5. Validate the new delivery, see that the delivery chatter is posted on both deliveries **Cause of the issue:** The message is currently logged on `sale_id.picking_ids`. **Fix:** Change the line in question to only log the message on the currently iterated over picking, as well as any relevant, previously created ones (e.g., in a multistep route context). opw-4059145 Forward-Port-Of: odoo/enterprise#72730 Forward-Port-Of: odoo/enterprise#71441
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72770 Forward-Port-Of: odoo/enterprise#
Original PR description
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72770 Forward-Port-Of: odoo/enterprise#72586
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#72746 Forward-Port-Of: odoo/enterprise#71725
Original PR description
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096 Forward-Port-Of: odoo/enterprise#72746 Forward-Port-Of: odoo/enterprise#71725
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality check smart button is not displayed, while the SN is linked to a QC. opw-4189396 Forward-Port-Of: odoo/e
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked with SN
- Create a BoM:
- no need to component
- Add an operation “OP1” with steps
- Control by product
- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1
Problem:
The quality check smart button is not displayed, while the SN is linked to a QC.
opw-4189396
Forward-Port-Of: odoo/enterprise#72693## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. ## Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notic
Original PR description
## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax…
## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. ## Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notice when the taxes has has something in the [description] field it print `<p>[description]><p>`. ## Solution: - In the `account.tax` model, the description field was changed to an HTML field with this commit: https://github.com/odoo/odoo/commit/112c68a07b817e5e9a6c01e34a0fe7238b2eaa07 - Added `_get_description_plaintext` method to convert HTML content to plaintext using `html2plaintext`. This will also ensure compatibility for future changes to the description field. related community fix: https://github.com/odoo/odoo/pull/184053 opw-4104951 Forward-Port-Of: odoo/enterprise#68454
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document.
Original PR description
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document. When we send the message we create the attachment but the move does not have attachment_ids set yet, so we fail to assign the first one. In this phase we just need to link the xml as the pdf will be registered when assigned as main attachment of the move opw-4088910 Forward-Port-Of: odoo/enterprise#69085
Change the checkbox label of stacked charts from `stacked linechart` to `stacked line chart` in the chart configuration panel. Same for bar charts. Also removed padding between `stacked` and `cumulative` checkboxes in the line chart panel. Task: [3978443](https://www.odoo.com/web#id=3978443&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#64336
Original PR description
Change the checkbox label of stacked charts from `stacked linechart` to `stacked line chart` in the chart configuration panel. Same for bar charts. Also removed padding between `stacked` and `cumulative` checkboxes in the line chart panel. Task: [3978443](https://www.odoo.com/web#id=3978443&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#64336
This update resolves a bug where the mail-chatter dropzone remained open after dragging a document to a folder. The fix removes a technical restriction that was preventing the dropzone from closing, improving the user experience when moving documents.
Original PR description
Steps to reproduce: 1. select a document 2. open chatter 3. drag(preview part) and drop to the others folder 4. the mail-chatter-dropzone remains open Technical Reason: Removing the unnecessary stop propagation on the search panel's document drop event as it was preventing it from being caught by the window keeping the chatter drop zone open. After this commit: The mail-chatter-dropzone will be closed after being moved to drag documents to the folders. Task-4268738
This update fixes an issue where timesheet hour calculations were inaccurate due to using UTC time zones. By adjusting the calculation to reflect the user's local calendar time zone, the system now correctly determines under/overtime hours, ensuring accurate timesheet reporting. This improves the reliability of timesheet data.
Original PR description
Steps ----- - Install timesheet_grid - Set monday as the first day of the week in the language settings - Set the timezone of the user's working schedule to a more advanced timezone, e.g. UTC+10 - Go to Timesheets and add some hours on monday -> The under/over time is calculated relative to a lower number of hours than the real number of working hours for that day. Cause ----- `get_daily_working_hours` uses UTC's start/end of day for the start and end of the period, causing some working hours near the start/end of the period to be missed. opw-4163183
A recent change in Belgium's time zone rules caused a test to fail. This fix ensures the test consistently uses UTC time, eliminating discrepancies caused by timezone offsets. This prevents inaccurate test results and ensures the reliability of our project management features.
Original PR description
Before this commit, the test `test_editing_task_planned_date` was written by using the belgium timezone but this test starts failing after the end of the summer time in belgium timezone since inside that test, the timezone used is the one used of the current calendar set on the company and/or the timezone set on the current user, that is the belgium one. And so, due to the change of the hours in belgium timezone to now use "winter time" the offset between the `datetime.now` with belgium timezone and the one using utc timezone is no longer 2 hours but 1 hour. Because of that the assets are totally wrong because the expected results are fixed and do not take into account the offset could change. This commit makes sure the test uses only utc as timezone to avoid using offset between 2 timezones since the asserts are fixed and not dynamic according to the offset between 2 timezones. runbot-104873
This update corrects a visual issue in the Odoo Studio application where the 'previous' button in the navigation bar was incorrectly positioned. This ensures a consistent and user-friendly experience when creating new applications within Studio. The fix improves the overall usability of the Studio interface.
Original PR description
Before this commit currently when creating a new app using Studio the previous button icon in the navbar appears in the wrong direction After this commit The previous button icon should appear in the right direction Task - 3845561 Forward-Port-Of: odoo/enterprise#61835
This update resolves an issue where a line was incomplete when creating applications using the Odoo Studio. The commit ensures that all necessary fields are correctly populated during app creation, improving the user experience and preventing data inconsistencies. This change was part of a larger effort to enhance the Studio's functionality.
Original PR description
Before this commit: while creating the app for the 'Suggested features for your new model' title the line is not completed. After this commit: the line should be completed. Task:-3845561 Forward-Port-Of: odoo/enterprise#61824
This update fixes a potential issue where communication text after processing could incorrectly include a forward slash. The code has been reorganized to improve reusability and testability, and the function is now used across multiple payment modules. Deprecated functions have been removed to streamline the system.
Original PR description
This commit aims to fix an issue in the sanitize_communication function and move its logic to the account_batch_payment module to improve reusability and testability. The function trims the communication text after removing the '/' characters. However, if the communication text contains '/' and is truncated, the '/' could end up at the end of the string (see tests for more examples). The solution is to remove the '/' after truncating the text. Additionally, the sanitize_communication function has been moved to the account_batch_payment module, since this module is a dependency for both account_sepa and account_sepa_direct_debit, these two modules can now use it as well. The functions sanitize_communication and _sanitize_communication have been marked as deprecated and will be removed in the master branch. opw-4220421 Forward-Port-Of: odoo/enterprise#71552
This update resolves a technical issue that caused tracebacks when creating GST return periods without specifying a month or quarter. The system now gracefully handles missing month/quarter data, preventing errors and ensuring smoother GST return period creation. This improves the reliability of the Odoo Enterprise system for Invoicing reports.
Original PR description
Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without…
Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without selecting a month will raise a traceback. Reason: - While calculating the start_date and end_date of the quarterly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.month), year=int(record.year))` If there is no month, then int(record.month) will return 0 and The month should be between 1 and 12, so it will raise an error. - While calculating the start_date and end_date of the monthly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.quarter), year=int(record.year))` If there is no quarter, then int(record.quarter) will return 0 and The month should be between 1 and 12, so it will raise an error. After this commit: - The start_date and end_date will not be calculated if a month or quarter is not defined for the monthly or quarterly return periods. Traceback - https://pastebin.com/LyKUDrH5 Task-4243468 Forward-Port-Of: odoo/enterprise#71883