Wednesday, November 20, 2024
92 changes
9 changes
Miscellaneous changes
Steps to reproduce: - Install Accounting > Settings > Enable 'Analytic Accounting' - Project App > New > Project Settings > Edit Analytic plan - Change Plan from 'Projects' to any other (except Internal) - Manufacturing > Operations > Manufacturing Orders > New - Product: 'Table Top' - Miscellaneous tab > Analytic distribution: <Project account> - Confirm > Produce All > Set quantities & Validate - Project > ':' Menu > Project Updates (Dashboard in 18.0+) - The cost of materials ($160)
Original PR description
Steps to reproduce: - Install Accounting > Settings > Enable 'Analytic Accounting' - Project App > New > Project Settings > Edit Analytic plan - Change Plan from 'Projects' to any other (except…
Steps to reproduce: - Install Accounting > Settings > Enable 'Analytic Accounting' - Project App > New > Project Settings > Edit Analytic plan - Change Plan from 'Projects' to any other (except Internal) - Manufacturing > Operations > Manufacturing Orders > New - Product: 'Table Top' - Miscellaneous tab > Analytic distribution: <Project account> - Confirm > Produce All > Set quantities & Validate - Project > ':' Menu > Project Updates (Dashboard in 18.0+) - The cost of materials ($160) is not deducted in Project costs Analytic distributions include different categories for each plan, this is reflected in DB with a different column for each plan, account_id/x_plan2_id/x_plan3_id/... which contain the project's analytic account. In version 18.0 and above we allow each project to have several analytic accounts (for the project, department, ...) but prior to that we relied on plan_id to differentiate the project account category. When checking for analytic lines to populate the project updates we check the `account_id`, meaning only lines with projects having analytic plan 'Projects' would pass that filter domain. We instead want to grab the account_id from any of the plan columns. opw-4282092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187275
Steps to reproduce: - Calendar > New > Tick 'Recurrent' - 'Until' => 'Number of repetitions' or 'Forever' - Set meeting start time in 5 mins - Add reminder => Notification - 15 Minutes > Save The notification is not sent, this is due to the use of 'until' to fetch the last event date of recurrent meetings despite that field only being set if the recrrence type is 'End date'. We want to check that date to avoid sending notifications for past meetings, but 'Number of Repetitions' recursions
Original PR description
Steps to reproduce: - Calendar > New > Tick 'Recurrent' - 'Until' => 'Number of repetitions' or 'Forever' - Set meeting start time in 5 mins - Add reminder => Notification - 15 Minutes > Save The notification is not sent, this is due to the use of 'until' to fetch the last event date of recurrent meetings despite that field only being set if the recrrence type is 'End date'. We want to check that date to avoid sending notifications for past meetings, but 'Number of Repetitions' recursions use a count instead of a date, and 'Forever' obviously doesn't need a date. Using the meeting end date instead should do the trick since it will always be in the future at the moment we want to send the reminder and it should never go over the last event date since no meeting record will be created after the recurrence ends anyway. opw-4247282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187423
**Steps to reproduce:** - Create a PDF report for the stock.picking model - Use the template stock.label_transfer_template_view_pdf. - When saving the report, the mentioned error occurred. ```py odoo.addons.base.models.ir_qweb.QWebException: Error while render the template AttributeError: 'stock.picking' object has no attribute 'move_lines' Template: stock.label_transfer_template_view_pdf Path: /t/t/div/t[2]/t[2] Node: <t t-foreach="picking.move_ids" t-as="move"/> ``` - [Ref](https:
Original PR description
**Steps to reproduce:** - Create a PDF report for the stock.picking model - Use the template stock.label_transfer_template_view_pdf. - When saving the report, the mentioned error occurred. ```py…
**Steps to reproduce:** - Create a PDF report for the stock.picking model - Use the template stock.label_transfer_template_view_pdf. - When saving the report, the mentioned error occurred. ```py odoo.addons.base.models.ir_qweb.QWebException: Error while render the template AttributeError: 'stock.picking' object has no attribute 'move_lines' Template: stock.label_transfer_template_view_pdf Path: /t/t/div/t[2]/t[2] Node: <t t-foreach="picking.move_ids" t-as="move"/> ``` - [Ref](https://github.com/odoo/odoo/pull/78732) were move_lines has been renamed to move_ids. - [Ref](https://github.com/odoo/odoo/pull/80434) were product_uom_qty has been renamed to reserved_uom_qty. **Desired behavior after PR is merged:** - Can create a report for stock.picking model  OPW - [4239654](https://www.odoo.com/odoo/project/70/tasks/4239654) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187427 Forward-Port-Of: odoo/odoo#184046
This PR fixes an issue about the pager buttons having a wrong `border-radius` in RTL languages. Prior to this PR, the icons were defined at the button level. On top of being unusual, this had a side-effect. In RTL languages, we use a CSS `transform: rotate(180deg);` on our directional icons,in order to flip their direction and match the RTL or LTR. While this works totally fine, having the icon sets on the button directly means the whole button will be flipped, meaning the border-radius wi
Original PR description
This PR fixes an issue about the pager buttons having a wrong `border-radius` in RTL languages. Prior to this PR, the icons were defined at the button level. On top of being unusual, this had a…
This PR fixes an issue about the pager buttons having a wrong `border-radius` in RTL languages. Prior to this PR, the icons were defined at the button level. On top of being unusual, this had a side-effect. In RTL languages, we use a CSS `transform: rotate(180deg);` on our directional icons,in order to flip their direction and match the RTL or LTR. While this works totally fine, having the icon sets on the button directly means the whole button will be flipped, meaning the border-radius will be inverted. To prevent this behaviour, we simply need to use a `<i/>` tag for both icons, which will allow them to be flipped without affecting the button design. | 17.0 | This PR | |--------|--------| | <img width="159" alt="image" src="https://github.com/user-attachments/assets/2afc13b3-0b4b-4baf-a306-2196a3c83867"> | <img width="159" alt="image" src="https://github.com/user-attachments/assets/a405e167-6a0f-4a49-a15d-4e36735d95f5"> | task-4345233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187741
step to reproduce: 1. create a db in 16.0 with appointment and account_payment module 2. create ``User-defined default`` (ir_default): Settings -> Technical -> User-defined Defaults - Field = Unit of Measure (product.template) - Default Value (JSON format) = 3 (pick any id that is not in the same category as `uom.product_uom_unit`) 2. upgrade db to 17.0 version below mentioned traceback will raised because appointment_account_payment is auto install. ``` Traceback (most recent call last):
Original PR description
step to reproduce: 1. create a db in 16.0 with appointment and account_payment module 2. create ``User-defined default`` (ir_default): Settings -> Technical -> User-defined Defaults - Field = Unit of…
step to reproduce:
1. create a db in 16.0 with appointment and account_payment module
2. create ``User-defined default`` (ir_default): Settings -> Technical -> User-defined Defaults
- Field = Unit of Measure (product.template)
- Default Value (JSON format) = 3 (pick any id that is not in the same category as `uom.product_uom_unit`)
2. upgrade db to 17.0 version below mentioned traceback will raised because appointment_account_payment is auto install.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 480, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 227, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 627, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/appointment_account_payment/data/product_data.xml:8
The default Unit of Measure and the purchase Unit of Measure must be in the same category.
View error context:
'-no context-'
```
why this traceback is raised because here in default values of [``uom_po_id``](https://github.com/odoo/odoo/blob/834e8a8789d1d451f62ae1e841845baf7d3931a4/addons/product/models/product_template.py#L36) getting default value of uom_id due to that other catefory uom_id is coming and [validation](https://github.com/odoo/odoo/blob/834e8a8789d1d451f62ae1e841845baf7d3931a4/addons/product/models/product_template.py#L456)
error raised and db got blocked
opw-4313919
upg-2182151
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#187663UserWarning: unsupported operand type(s) for "==": 'res.country()' == '233' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187821
Original PR description
UserWarning: unsupported operand type(s) for "==": 'res.country()' == '233' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187821
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app > New > Enable 'Billable' in the project's settings - New Task > Set any Customer - Sales Order Item > Search More > New > Add product then save - Click 'Sales Order' button Coupled with https://github.com/odoo/enterprise/pull/73492 You'll see in the chatter that the confirmation email
Original PR description
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app…
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app > New > Enable 'Billable' in the project's settings - New Task > Set any Customer - Sales Order Item > Search More > New > Add product then save - Click 'Sales Order' button Coupled with https://github.com/odoo/enterprise/pull/73492 You'll see in the chatter that the confirmation email is sent before the product is added to the sales order, resulting in a $0 quotation document being sent to the customer. This happens because we confirm the SO at the same time as we create it (After pressing the New button). Instead we would rather confirm the SO on save, after the order line creation. The SO confirmation is necessary because we don't want people to work on tasks/projects that are still in quotation since they could hypothetically still be cancelled. opw-4190402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183586
When confirming a BILL via Project's Updates, the generated payment terms line will have the analytic account of the project assigned Version: 17.0+ Steps to reproduce: - Have a project (i.e. Renovations) - Create a Purchase Order - Add on the line the analytic account of the project - Go to Projects Kanban view - Open Project 3 dots menu > Reporting > Project Updates - Open the created PO, Create Bill Issue: Analytic account will be assigned to the payment term line opw-4193509
Original PR description
When confirming a BILL via Project's Updates, the generated payment terms line will have the analytic account of the project assigned Version: 17.0+ Steps to reproduce: - Have a project (i.e. Renovations) - Create a Purchase Order - Add on the line the analytic account of the project - Go to Projects Kanban view - Open Project 3 dots menu > Reporting > Project Updates - Open the created PO, Create Bill Issue: Analytic account will be assigned to the payment term line opw-4193509 Forward-Port-Of: odoo/odoo#187612
When our own bank is used as a payment means, it shouldn't be populated in the OIOUBL XML. When using Peppol, the XML would ignore the endpoint that is set in the electronic invoicing settings, the <cbc:EndpointID> should be the defined Peppol endpoint and the schemeID should be 'GLN'. task-4017019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171945
Original PR description
When our own bank is used as a payment means, it shouldn't be populated in the OIOUBL XML. When using Peppol, the XML would ignore the endpoint that is set in the electronic invoicing settings, the <cbc:EndpointID> should be the defined Peppol endpoint and the schemeID should be 'GLN'. task-4017019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171945
33 changes
Enhancements to existing features
This update modernizes how several Odoo apps define extra database indexes, helping keep data access reliable and easier to maintain. The change is internal and should not alter day-to-day user workflows, but it supports smoother performance and future upgrades.
Original PR description
Use `model.Index` for additional indexes. odoo/odoo#187538
The mobile-related test suites for web and HR mobile have been updated to use the newer testing framework. This improves maintainability and reliability of internal quality checks without changing day-to-day user workflows.
Original PR description
task-4028335
The Mexican e-invoicing setup has been cleaned up so the relevant fields are added consistently across all accounting moves, not just customer invoices. This reduces configuration gaps and makes the view structure easier to maintain going forward.
Original PR description
The 3 fields were only added to the out_invoice view while it should have been on all moves. As we were in stable, we had to add a view inheriting each of the different move view. Now, we should remerge them and inherit the right view.
Resolved issues and error corrections
This fix adds missing test dependencies for Helpdesk Timesheet and Sales Timesheet Enterprise after related model changes. It helps keep automated checks stable, reducing the risk of disruptions in future updates.
Original PR description
[*] sale_timesheet_enterprise Purpose of this commit: Following the changes in PR https://github.com/odoo/odoo/pull/187029 the removal of certain model definitions caused test cases in the specified modules to fail. This commit resolves the issue by adding the necessary model dependencies. Community PR: https://github.com/odoo/odoo/pull/187029 Part of task-3818666
The payroll sales commission tests now calculate expected commissions from the sales order total instead of fixed product prices. This prevents unrelated price list settings from causing false test failures, improving reliability for payroll commission validation.
Original PR description
If a pricelist matches the test product, the commission will be affected. This is one more repeat of odoo/odoo@abe8e38ccc18cfba77317d3fdaf4a066b5f69b79: it's possible for a module to set up a universally applicable pricelist (like `pos_pricer` which sets a 20% discount on everything). In the presence of such a module, tests with hard-coded "output" prices will fail. A common workaround is to disable all pricelists when creating the test, but in this case it seems reasonably easy (and correct) to use the SO's total amount as computation basis.
Code cleanup and technical improvements
The internal file layout of multiple Point of Sale related modules has been reorganized to match the newer structure. This helps keep development and maintenance consistent across country-specific, payment, restaurant, IoT, and self-ordering POS features without introducing intended functional changes for business users.
Original PR description
Reorganization of all pos submodules to follow its new file structure Here is the list of all reorganized modules : - community: l10n_ar_pos, l10n_co_pos, l10n_es_edi_tbai_pos, l10n_es_pos, l10n_gcc_pos, l10n_in_pos, pos_adyen, pos_discount, pos_epson_printer, pos_event, pos_hr, pos_loyalty, pos_mercado_pago, pos_online_payment, pos_paytm, pos_razorpay, pos_restaurant, pos_restaurant_adyen, pos_sale, pos_self_order_epson_printer, pos_six, pos_sms, pos_stripe, pos_viva_wallet - enterprise: l10n_cl_edi_pos, l10n_de_pos_cert, l10n_ec_edi_pos, l10n_mx_edi_pos, l10n_pe_edi_pos, pos_avatax, pos_iot, pos_iot_six, pos_preparation_display, pos_restaurant_appointment, pos_self_order_iot, pos_settle_due, whatsapp_pos community PR: https://github.com/odoo/odoo/pull/186724 task-id: 4290514
Product category demo data has been simplified across several business apps, making sample data easier to maintain and understand. The update also improves how default accounts are selected based on each company's localization, helping accounting behavior better match local settings.
Original PR description
This commit clean category data and demo data to have flat catagory and improve related logic to get default accounts based on company localization from company record. task-3941328 Co-authored-by: Dev Reshamiya <dere@odoo.com> Co-authored-by: Kartik Chavda <kcv@odoo.com>
This update modernizes how automated product tours detect visible items during testing. It helps keep test behavior aligned with the current platform tools, reducing false positives and improving reliability without changing day-to-day user workflows.
Original PR description
In this commit, we replace the use of _legacyIsVisible by the visible option of hoot which refers to isVisible function of hoot-dom.js. This change implies changes in a few tours. For information, _legacyIsVisible accepts elements with a width of 0 or a length of 0 (which is a bit absurd) while isVisible does not, which implies the changes where we just add :not(:visible) to the trigger. The other main modifications implies tours where you have to hover the trigger to then see the element you want to click on. task~3974087 https://github.com/odoo/odoo/pull/175964
This update standardizes internal Point of Sale JavaScript method names to a consistent camelCase style across POS and related localization modules. It should not change how users work with the system, but it improves code consistency and maintainability for future updates.
Original PR description
In this commit: -------------------- - Renamed all js methods in point_of_sale and all related modules of point_of_sale to camelCase from snake_case. Related PR: https://github.com/odoo/odoo/pull/185252 Task: 4269182
Miscellaneous changes
This PR aims to increase the contrast between the default and the `focus` state of our `btn-primary`. | 17.0 | This PR | |--------|--------| | <img width="729" alt="image" src="https://github.com/user-attachments/assets/19c29432-4467-46bf-b240-41017d435c09"> | <img width="717" alt="image" src="https://github.com/user-attachments/assets/1efc15cc-6e10-460b-9040-4088cf3a98e0"> | Prior to this PR, the color was not dark enough to grant enough visual feedback on focus. This can be solve quic
Original PR description
This PR aims to increase the contrast between the default and the `focus` state of our `btn-primary`. | 17.0 | This PR | |--------|--------| | <img width="729" alt="image" src="https://github.com/user-attachments/assets/19c29432-4467-46bf-b240-41017d435c09"> | <img width="717" alt="image" src="https://github.com/user-attachments/assets/1efc15cc-6e10-460b-9040-4088cf3a98e0"> | Prior to this PR, the color was not dark enough to grant enough visual feedback on focus. This can be solve quickly by tweaking the value directly. task-3382308 Forward-Port-Of: odoo/enterprise#71793
commit [1] removes the hard-coded description on appointment calendar events. We still want to use the "attendee description" on crm leads as questions are not easily accessible from there. [1] 8b9a1a4462453bf64e7bc1307ededd0d127a27fa Forward-Port-Of: odoo/enterprise#74161
Original PR description
commit [1] removes the hard-coded description on appointment calendar events. We still want to use the "attendee description" on crm leads as questions are not easily accessible from there. [1] 8b9a1a4462453bf64e7bc1307ededd0d127a27fa Forward-Port-Of: odoo/enterprise#74161
## [FIX] l10n_be_reports: 281.50 and exchange diff The aim of this commit is to prevent a Zero devision error by excluding irrelevant 'zeroed' exchange difference. Context: Some misc entry with a 0 balance and some amount_currency might be present and taken into account for the computation. Such moves have an `amount_total_signed` equal to 0 leading to the zeroDivisionError issue in the query computation. Before the commit: When having such entry considered by the query, creating th
Original PR description
## [FIX] l10n_be_reports: 281.50 and exchange diff The aim of this commit is to prevent a Zero devision error by excluding irrelevant 'zeroed' exchange difference. Context: Some misc entry with a 0 balance and some amount_currency might be present and taken into account for the computation. Such moves have an `amount_total_signed` equal to 0 leading to the zeroDivisionError issue in the query computation. Before the commit: When having such entry considered by the query, creating the 325.50 form leads to a traceback. After the commit: Those irrelevant moves are ignored and the process carry on smoothly. task-id: None - Issue spotted on next ## [FIX] l10n_be_reports: 281.50, no 0-0-0-0-0 form The aim of this commit is to avoid generating a 281.50 form if there isn't any amounts to fill in the form. task-id: None - Dicussed with TSB Forward-Port-Of: odoo/enterprise#74142 Forward-Port-Of: odoo/enterprise#73842
In the PoS restaurant if you marked a line as skipChange not to send it on the preparation display, then add the same product to the order and send it to the preparation display. At this point everything would be correct, only one of the product would be one the pdis. But if you add another different product and send it to the pdis, it would also bring back the one that was marked as skip change. Steps to reproduce: ------------------- * Setup a preparation display for a PoS restaurant * O
Original PR description
In the PoS restaurant if you marked a line as skipChange not to send it on the preparation display, then add the same product to the order and send it to the preparation display. At this point…
In the PoS restaurant if you marked a line as skipChange not to send it on the preparation display, then add the same product to the order and send it to the preparation display. At this point everything would be correct, only one of the product would be one the pdis. But if you add another different product and send it to the pdis, it would also bring back the one that was marked as skip change. Steps to reproduce: ------------------- * Setup a preparation display for a PoS restaurant * Open PoS and add product A to the order * Double click on the order line to mark it as skip change * Add the same product to the order and click on the order button * At this point the preparation display should only show one product A * Add another different product B to the order * Click on the order button > Observation: The preparation display shows the product B and a second product A Why the fix: ------------ Instead of filtering based on the product we filter directly based on the line UUID that is unique and should avoid any further errors opw-4322597 Forward-Port-Of: odoo/enterprise#73826
Before this commit, some things were unclear. The mobile view was not working as expected and expired sign items were displayed in the thank you dialog. Refusing sign request would not cancel them. Moreover this commit fix the sign tests. This commit aims to fix an issue with test_archived_requests_dont_send_reminders. Previously the test was trying to archive a record by performing a direct write command, but since we have a designated action for archiving sign requests, it should be use
Original PR description
Before this commit, some things were unclear. The mobile view was not working as expected and expired sign items were displayed in the thank you dialog. Refusing sign request would not cancel them.…
Before this commit, some things were unclear. The mobile view was not working as expected and expired sign items were displayed in the thank you dialog. Refusing sign request would not cancel them. Moreover this commit fix the sign tests. This commit aims to fix an issue with test_archived_requests_dont_send_reminders. Previously the test was trying to archive a record by performing a direct write command, but since we have a designated action for archiving sign requests, it should be used. Another issue is that when we archive a sign request, its state is set to 'canceled', and for canceled sign requests we cannont update the validity, however the test was trying to update the validity (as a way of jumping to the future). But this is not the correct way of doing it, since we shouldn't change the validity if state is canceled. To fix the issue, a mock_datetime_and_now is introduced. Note: this is the backport of https://github.com/odoo/enterprise/pull/73156 task: 4294860 Forward-Port-Of: odoo/enterprise#74082
Before this commit, amount_to_invoice was computed in the cron when the invoice was created as it depends on qty_invoiced. Unfortunately, the compute would be triggered and the ORM would try to write on the sale.order record at the same time than the cron would continue his job. it would end up with concurrent updates. This commit ensure that the compute method is inhibited during the cron and is triggered at the end of it. task 4216148 Forward-Port-Of: odoo/enterprise#74078
Original PR description
Before this commit, amount_to_invoice was computed in the cron when the invoice was created as it depends on qty_invoiced. Unfortunately, the compute would be triggered and the ORM would try to write on the sale.order record at the same time than the cron would continue his job. it would end up with concurrent updates. This commit ensure that the compute method is inhibited during the cron and is triggered at the end of it. task 4216148 Forward-Port-Of: odoo/enterprise#74078
This re-adds the possibility for a user with approval rights, but no accounting rights to reset an expense to draft after it has been refused/approved. opw-4328933 Forward-Port-Of: odoo/enterprise#73902
Original PR description
This re-adds the possibility for a user with approval rights, but no accounting rights to reset an expense to draft after it has been refused/approved. opw-4328933 Forward-Port-Of: odoo/enterprise#73902
The "Predial Account" column appeared in all signed invoices, regardless of whether the invoice lines included rental products with a predial account. This resulted in a non-organized layout with an empty column for most invoices. Steps to reproduce: 1. Install the l10n_mx_edi module. 2. Create and sign an invoice with any product and customer. Expected behavior: The "Predial Account" column should only be displayed when the invoice contains products with a predial account. Actual be
Original PR description
The "Predial Account" column appeared in all signed invoices, regardless of whether the invoice lines included rental products with a predial account. This resulted in a non-organized layout with an empty column for most invoices. Steps to reproduce: 1. Install the l10n_mx_edi module. 2. Create and sign an invoice with any product and customer. Expected behavior: The "Predial Account" column should only be displayed when the invoice contains products with a predial account. Actual behavior: The "Predial Account" column is displayed in all invoices, even when it's empty. opw-4233358 Forward-Port-Of: odoo/enterprise#72364
This commit allows the mock server to properly handle 'property' and 'property_definition' fields in tests. Community: https://github.com/odoo/odoo/pull/187269 Task: [4058174](https://www.odoo.com/odoo/project.task/4058174) Forward-Port-Of: odoo/enterprise#73851
Original PR description
This commit allows the mock server to properly handle 'property' and 'property_definition' fields in tests. Community: https://github.com/odoo/odoo/pull/187269 Task: [4058174](https://www.odoo.com/odoo/project.task/4058174) Forward-Port-Of: odoo/enterprise#73851
As we immediatly call button_done on the wworkorder, the start_date is greater than the end_date which raises a user error. So we start the workorder before setting it to done Forward-Port-Of: odoo/enterprise#74139
Original PR description
As we immediatly call button_done on the wworkorder, the start_date is greater than the end_date which raises a user error. So we start the workorder before setting it to done Forward-Port-Of: odoo/enterprise#74139
In this commit, we simplify steps of the tour that check there are no add buttons in readonly mode. Forward-Port-Of: odoo/enterprise#74073
Original PR description
In this commit, we simplify steps of the tour that check there are no add buttons in readonly mode. Forward-Port-Of: odoo/enterprise#74073
This commit adds the missing neutralization necessary for the l10n_uk_hmrc module introduced in [1]. [1]: https://github.com/odoo/enterprise/pull/66766 Forward-Port-Of: odoo/enterprise#74036
Original PR description
This commit adds the missing neutralization necessary for the l10n_uk_hmrc module introduced in [1]. [1]: https://github.com/odoo/enterprise/pull/66766 Forward-Port-Of: odoo/enterprise#74036
The pricelist rule is now returned by the configurator methods, to be able to deduce the right strikethrough price. See also odoo/odoo#187436 Forward-Port-Of: odoo/enterprise#73993
Original PR description
The pricelist rule is now returned by the configurator methods, to be able to deduce the right strikethrough price. See also odoo/odoo#187436 Forward-Port-Of: odoo/enterprise#73993
This commit fixes two issues with the `lot_id` field in the move line form view in the Barcode app for the manufacturing operations. 1. The `lot_id` field was displayed when no product was selected. 2. The `lot_id` field was not displayed for by-product lines created at the creation of the MO. The first issue was there because the compute fields to determine if we want to hide `lot_id` and/or `lot_name` were false by default. The second issue was there because those fields depend of the
Original PR description
This commit fixes two issues with the `lot_id` field in the move line form view in the Barcode app for the manufacturing operations. 1. The `lot_id` field was displayed when no product was selected. 2. The `lot_id` field was not displayed for by-product lines created at the creation of the MO. The first issue was there because the compute fields to determine if we want to hide `lot_id` and/or `lot_name` were false by default. The second issue was there because those fields depend of the line's picking code which depends of the line's picking type which depend of the line's `production_id`. The issue is by-product lines has no `production_id` set. Forward-Port-Of: odoo/enterprise#73241
Issue: In the Chilean POS localization, the checkbox contained in the invoice button is always checked. This is confusing, since it seems the option is selected even when it isn't. Cause: By default, the checkbox depends on the order's "is_to_invoice" return value. In the Chilean POS, the "to_invoice" value is set to true by default and never updated, so "is_to_invoice" always returns true. Clicking on the invoice button only updates the value of the "invoice_type" field. Solution: Repl
Original PR description
Issue: In the Chilean POS localization, the checkbox contained in the invoice button is always checked. This is confusing, since it seems the option is selected even when it isn't. Cause: By default, the checkbox depends on the order's "is_to_invoice" return value. In the Chilean POS, the "to_invoice" value is set to true by default and never updated, so "is_to_invoice" always returns true. Clicking on the invoice button only updates the value of the "invoice_type" field. Solution: Replace the checkbox with one that uses the "invoice_type" field through the "isFactura" function. Ticket: opw-4298996 Forward-Port-Of: odoo/enterprise#73444
Currently, a traceback occurs when the user tries to send the `partner ledger` report after uninstalling the `account_followup`. To reproduce this issue: 1) Install `Accounting` 2) Uninstall `account_followup` 3) Open the `partner ledger` report from the reporting 4) Click the `send` button and then `send & print` button Error:- ``` 'res.partner' object has no attribute '_get_partner_account_report_attachment' ``` The `_get_partner_account_report_attachment` method is define
Original PR description
Currently, a traceback occurs when the user tries to send the `partner ledger` report after uninstalling the `account_followup`. To reproduce this issue: 1) Install `Accounting` 2) Uninstall…
Currently, a traceback occurs when the user tries to send the `partner ledger` report after uninstalling the `account_followup`. To reproduce this issue: 1) Install `Accounting` 2) Uninstall `account_followup` 3) Open the `partner ledger` report from the reporting 4) Click the `send` button and then `send & print` button Error:- ``` 'res.partner' object has no attribute '_get_partner_account_report_attachment' ``` The `_get_partner_account_report_attachment` method is defined in `account_followup` and is referenced in `account_reports`. https://github.com/odoo/enterprise/blob/6100796466f356053dde87110c80812c2dcba3ba/account_followup/models/res_partner.py#L295 When the user uninstalls the `followup` it leads to the above traceback when the below line of code executes. https://github.com/odoo/enterprise/blob/6100796466f356053dde87110c80812c2dcba3ba/account_reports/wizard/account_report_send.py#L250 We can resolve this issue by moving the code from `account_followup` to `account_reports`. As we can see that `account_followup` depends on `account_reports`. sentry-6069400574 Forward-Port-Of: odoo/enterprise#74064
This was forgotten in this bugfix : https://github.com/odoo/enterprise/commit/4d548d2240c85eebe004595cd65e0fbb6a76a39b We don't fix it before 17.4 because of this revert https://github.com/odoo/enterprise/pull/73495 Forward-Port-Of: odoo/enterprise#73763 Forward-Port-Of: odoo/enterprise#73496
Original PR description
This was forgotten in this bugfix : https://github.com/odoo/enterprise/commit/4d548d2240c85eebe004595cd65e0fbb6a76a39b We don't fix it before 17.4 because of this revert https://github.com/odoo/enterprise/pull/73495 Forward-Port-Of: odoo/enterprise#73763 Forward-Port-Of: odoo/enterprise#73496
Steps to reproduce: - Sign app > Upload PDF > Add a 'Signature' field > Send > Cancel - In mailhog open the email > Click 'Sign Document' - Redirected to 404 as expected - Traceback '$(...).zoomOdoo is not a function' Original PR: https://github.com/odoo/odoo/pull/186241 JQuery is loaded twice, from `web.assets_frontend asset` (With zoomOdoo) and from `web.assets_frontend_lazy` (Without zoomOdoo). When redirecting to website 404 through a cancelled sign request we attempt to use zoomOd
Original PR description
Steps to reproduce: - Sign app > Upload PDF > Add a 'Signature' field > Send > Cancel - In mailhog open the email > Click 'Sign Document' - Redirected to 404 as expected - Traceback '$(...).zoomOdoo is not a function' Original PR: https://github.com/odoo/odoo/pull/186241 JQuery is loaded twice, from `web.assets_frontend asset` (With zoomOdoo) and from `web.assets_frontend_lazy` (Without zoomOdoo). When redirecting to website 404 through a cancelled sign request we attempt to use zoomOdoo with the latter causing this error. The option to cancel sign requests is available in saas-17.4 and above only. opw-4261794 Forward-Port-Of: odoo/enterprise#73375
task-4246523 Forward-Port-Of: odoo/enterprise#72701
Original PR description
task-4246523 Forward-Port-Of: odoo/enterprise#72701
A traceback may occur when the user tries to upload a vendor bill. Where the invoice has an Indian company and a rounding error. Error:- ``` KeyError: 'groups_by_subtotal' ``` This is because of the major refactor done from the below commit to calculate the tax_totals in the `account.tax` https://github.com/odoo/odoo/commit/73d585a85b093db07e4eb5541aaa03e74af5fd62 Initially, we have a `groups_by_subtotal` in tax_totals, but after the refactor we return subtotals containing `
Original PR description
A traceback may occur when the user tries to upload a vendor bill. Where the invoice has an Indian company and a rounding error. Error:- ``` KeyError: 'groups_by_subtotal' ``` This is because of the major refactor done from the below commit to calculate the tax_totals in the `account.tax` https://github.com/odoo/odoo/commit/73d585a85b093db07e4eb5541aaa03e74af5fd62 Initially, we have a `groups_by_subtotal` in tax_totals, but after the refactor we return subtotals containing `tax_groups`. The code has been adjusted according to the above commit by take the maximum `tax_group` based on `tax_amount_currency` and added the `fixed_round_error` to resolve this issue. sentry-5963987892 Forward-Port-Of: odoo/enterprise#71976
Reproduce: 1. Configure a default filter on Documents so that not all documents are visible 2. Select a document that does not match this default filter 3. Copy the url of this document (copy url when it is selected) 4. Paste in navigation bar / refresh page 5. You do not end up on the document because the default filter still applied This commit prevents loading default filters when we come from such URLs, not otherwise (refresh the page after deselecting the document in the folder).
Original PR description
Reproduce: 1. Configure a default filter on Documents so that not all documents are visible 2. Select a document that does not match this default filter 3. Copy the url of this document (copy url when it is selected) 4. Paste in navigation bar / refresh page 5. You do not end up on the document because the default filter still applied This commit prevents loading default filters when we come from such URLs, not otherwise (refresh the page after deselecting the document in the folder). Task-4342960 Forward-Port-Of: odoo/enterprise#74028
This PR contains the following commits: >[FIX] mrp_mps: non-default period changes - hide Order buttons: When the date type shown (year, month, week, day) is different from the one defined in the settings, we hide the order buttons. - disable max_to_replenish_qty: `max_to_replenish_qty` should only be applied for the period defined in the settings. Otherwise we have situation where a limit of 15 per month is applied for a whole year. - make replenish input cells readonly: When showing a
Original PR description
This PR contains the following commits: >[FIX] mrp_mps: non-default period changes - hide Order buttons: When the date type shown (year, month, week, day) is different from the one defined in the…
This PR contains the following commits: >[FIX] mrp_mps: non-default period changes - hide Order buttons: When the date type shown (year, month, week, day) is different from the one defined in the settings, we hide the order buttons. - disable max_to_replenish_qty: `max_to_replenish_qty` should only be applied for the period defined in the settings. Otherwise we have situation where a limit of 15 per month is applied for a whole year. - make replenish input cells readonly: When showing a bigger period type than the one selected in the settings (e.g. year > week), the replenish input fields are made readonly. This is because there's a loss of precision when showing bigger period and changing values may have unintended consequences that way. Also remove the colors on the replenish cells when in readonly. >[IMP] mrp_mps: more tests Adding more tests for various cases in MPS. Also, do `_get_date_range` in `setUpClass` for the month periods since it is the default. Remove all `_get_date_range` apart from when the default period has been changed in the settings. >[FIX] mrp_mps: use real dates with lead times When a bom has a lead time, we want to use the real date to compute the indirect demand forecast of the components in the MPS. Currently when showing the MPS in a period other than 'day', Odoo will do the sum of all forecast records for each period and base its calculation on the 1st day of the period. E.g. for the month of January, it will do the sum of all forecasts of that month then calculate lead times based on the 1st of January. > indirect_demand_qty > > Jan-25: 1000 > > Feb-25: 500 This causes issues with lead times when selecting bigger periods. This fix ensures that the forecasts are stored per date: > demand_qty_dict > > Jan-25 > > > 01-01-25: 200 > > > 01-07-25: 500 > > > 01-23-25: 300 > > Feb-25 > > > ... That way, when calculating lead times, it uses the real date for each forecast instead of the 1st day of the period shown. task 4172967 Forward-Port-Of: odoo/enterprise#72073
We have to await for `_initiatePaymentFlow()` completion to ensure we correctly got the result of the transaction route. Forward-Port-Of: odoo/enterprise#74023 Forward-Port-Of: odoo/enterprise#73974
Original PR description
We have to await for `_initiatePaymentFlow()` completion to ensure we correctly got the result of the transaction route. Forward-Port-Of: odoo/enterprise#74023 Forward-Port-Of: odoo/enterprise#73974
[REF] web_tour: remove MacroEngine class In this commit, we remove the MacroEngine class which duplicates the Macro class. Forward-Port-Of: odoo/enterprise#73792
Original PR description
[REF] web_tour: remove MacroEngine class In this commit, we remove the MacroEngine class which duplicates the Macro class. Forward-Port-Of: odoo/enterprise#73792
43 changes
Enhancements to existing features
A new automated test checks that non-admin users can access quotation documents as expected. This helps prevent future issues where regular sales users might be blocked from viewing or using quote documents.
Original PR description
This commit add test case to check quotation document access with non admin user to ensure user proparly able to access document without any issue. opw-4290856
Resolved issues and error corrections
This fixes a small visual alignment issue in the visitor live chat window. The avatar and conversation name now line up more cleanly, making the chat header look more polished and consistent.
Original PR description
In the backend, the avatar and conversation name is a clickable button to show more thread actions. When this is clickable, there's some spacing to align avatar nicely. In livechat from visitor perspective, however, the avatar was not spaced properly. This come from avatar and conversation name not being clickable to show more actions, because all actions are available in quick on the right side of header. This commit adds some spacing at beginning of header content of chat window when there's no actions menu, to compensate with the padding of the actions menu button. Before / After <img width="361" alt="Screenshot 2024-11-20 at 15 07 07" src="https://github.com/user-attachments/assets/0cbf75af-df85-4509-8ec3-31ed0893025b"> <img width="363" alt="Screenshot 2024-11-20 at 15 06 49" src="https://github.com/user-attachments/assets/2197a159-a64e-4b80-a5df-cd1b8fe3d578">
Task records will no longer show duplicate update messages when a linked customer name changes. This keeps project communication logs clearer and avoids unnecessary noise for users reviewing task activity.
Original PR description
Before this commit, the `partner_name` was tracked in `project.task` model because `name` of `res.partner` model is tracked and so the related setup will keep the value set on `name` field of `res.partner` to also make the related field tracked. This commit removes the tracking on the related field in task since it was not expected. Moreover, we will get a duplicated tracking message with `partner_id` field which is also tracked in `project.task` model.
The Discuss sidebar counter bubbles now keep their rounded shape even when channel or conversation names are long. This prevents the notification count from looking squeezed, improving readability and polish in the messaging interface.
Original PR description
This commit sets the `flex-shrink` of the counter element to `0` so it won't be reduced when a sidebar item has a long name. We can also remove the `min-width` from `o-discuss-badge` as all `.o-discuss-badge` cases use `.badge` which has a `min-width: 2.7ch`.
Worldline payments can now correctly recognize additional statuses returned during validation. This prevents valid in-progress or declined payments from being misclassified, reducing payment follow-up issues for customers and staff.
Original PR description
Adding missing payment statuses: 'REDIRECTED', 'PENDING_CAPTURE' and 'CAPTURE_REQUESTED' as 'pending' states, 'REJECTED_CAPTURE' as 'declined' state as those statuses can effectively be received from Worldline.
The website's rounded box header now keeps proper spacing on mobile screens. This prevents header content from touching the border, improving the appearance and readability of mobile pages.
Original PR description
This PR aims to fix a spacing issue within the `rounded box` header template, which has no spacing in mobile, making the first and last element stick to the border of the header. To fix that behavior, we simply need to set a `padding` utility class on Mobile as well. - task-3608124 - extracted from https://github.com/odoo/odoo/pull/171050 | 18.0 | This PR | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mentions in Odoo Discuss now display correctly on Safari when messages span multiple lines. This prevents overlapping text, making conversations easier to read and improving the visual reliability of the messaging interface.
Original PR description
Before this commit, rendering of `@`mentions in Discuss on Safari was bigger than line height, which results in unintended UI overlap. This is mostly visible and problematic when 2 successive text…
Before this commit, rendering of `@`mentions in Discuss on Safari was bigger than line height, which results in unintended UI overlap. This is mostly visible and problematic when 2 successive text lines have mentions in the same horizontal range. This happens because discuss mentions are `<a>` and anchor links have `display: inline`. As a reminder, `inline` does not respect top/bottom padding and margin of element in its container so this is very likely prone to overlap vertically with sibling nodes. `inline-block`, on the other hand, take vertical padding and margin into account so it doesn't overlap. If the element takes more space, then siblings are pushed accordingly. This commit fixes the issue by setting `display: inline-block` to all discuss mentions, so that there's no risk of overlap in multi-line especially on Safari. Before / After <img width="520" alt="Screenshot 2024-11-20 at 12 54 31" src="https://github.com/user-attachments/assets/c1888680-e579-4573-930b-69bdf400f8e8"> <img width="523" alt="Screenshot 2024-11-20 at 12 54 12" src="https://github.com/user-attachments/assets/acfdfe8c-b6ef-49cc-8baf-816cf3058516">
This fix prevents an error when collaboration details for another editor are unavailable. It helps keep the HTML editor stable during shared editing sessions instead of interrupting users with a crash.
Original PR description
The `getPeerMetadata` function can return a falsy value and that was not taken into account.
This fixes an issue where users working in right-to-left languages could not see the table picker in Firefox. It restores access to table insertion in the HTML editor, improving reliability for affected language users.
Original PR description
Issue: ====== Table picker doesn't appear in rtl language in firefox Steps to reproduce the issue: ============================= - Make sure you use rtl lang - Create a new todo - Try to add table -…
Issue: ====== Table picker doesn't appear in rtl language in firefox Steps to reproduce the issue: ============================= - Make sure you use rtl lang - Create a new todo - Try to add table - Table picker doesn't appear Origin of the issue: ==================== The case of `left < 0` was handled wrong. They can both be handled by the sane formule. When left > 0 it will be like this: `|---left---||---width---||---right---|` `|-----------------window-------------|` So here `right = window-left-width` And when left < 0 it will be like this `|---width-----||---right------------------------ |` `|---left---| |` ` |-----------------window--------------|` And here `right = window - left - width` (left here is < 0) task-4282549 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 accounting screen now shows the secured entry status only when an entry is already secured or its journal is configured to secure posted entries with a hash. This prevents users from seeing a misleading status indicator just because they have access to inalterability features.
Original PR description
Before this **PR**: Since the visibility of the status bar for secured entries was controlled by the security group 'Show Inalterability Features', once assigned to a user, it would make the status bar visible indefinitely, regardless of whether the "Secure Posted Entries with Hash" option was activated or not. After this **PR**: The status bar for secured entries is now displayed only for entries that are already secured or belong to journals where the "Secure Posted Entries with Hash" option is enabled. **task**-4314073
The Unfollow action in messages now uses the correct icon setup, preventing a broken or incorrect icon from appearing. This keeps the messaging interface visually consistent and easier for users to understand.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/184552 Commit above fixed an issue with `.oi` icon not showing correctly. To fix the issue, it puts the appropriate prefix `.fa` and `.oi` in the icon of the message action. The "Unfollow" message action was not properly adapted, which results in buggy icon due to missing `.fa`. This commit adds `.fa` in its icon definition similarly to how all message actions that use a font awesome icon should do.
Translation has been forgotten in the forward port of the following PR: https://github.com/odoo/odoo/pull/187686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Translation has been forgotten in the forward port of the following PR: https://github.com/odoo/odoo/pull/187686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The UK CIS reporting module no longer loads test code during regular startup. This keeps testing logic separate from normal business use, reducing unnecessary processing and avoiding potential setup issues.
Original PR description
Tests should not be imported in module init. The import is done when tests are enabled.
Uninstalling the Sign app after signing a document now also removes related activity reminders that would otherwise point to deleted records. This prevents users from seeing confusing missing-record errors after removing the app.
Original PR description
The issue: When uploading and signing a document, then uninstalling the Sign module, the following error message appears: `Missing Record Record does not exist or has been deleted. (Record: documents.document(42,), User: 2)` How to reproduce the issue: - Install Sign and Documents modules - Upload a PDF document and click on sign - Go to Apps and uninstall Sign When signing a document from `documents.document`, its `res_model` is set to `sign.template`, and a `mail.activity` is created for validation. On uninstalling Sign, all records with `res_model = 'sign.template'` are removed, but not in `mail.activity`. This happens because deletion occurs via cascade (`sign.template` -> `attachment.id` -> `documents.document`), meaning that`unlink` from `documents.document`is not called. opw-4283568
When an appointment creates a CRM lead, the lead now keeps the attendee-provided description. This helps sales teams see important appointment answers directly on the lead, where they are easier to use during follow-up.
Original PR description
commit [1] removes the hard-coded description on appointment calendar events. We still want to use the "attendee description" on crm leads as questions are not easily accessible from there. [1] 8b9a1a4462453bf64e7bc1307ededd0d127a27fa task-4347415
The Belgian payroll process now skips freelancers when allocating paid time off. This prevents incorrect leave allocations for workers who should not receive employee time off entitlements.
This fix prevents document updates or upgrades from failing when certain document tags are missing. It makes the Documents module more reliable during setup and migration by avoiding errors from optional setup records.
Original PR description
The server actions refer to document tags added in this version. Since the records have the `forcecreate=0` flag, the might not exist, triggering an error. To reproduce: - Create a fresh db in 18. - Delete any referenced tag in the file (eg `documents.documents_tag_inbox`) - Update documents This error will also happen during upgrades from previous versions if the old record to be renamed is missing. ``` ValueError: External ID not found in the system: documents.documents_tag_inbox ```
This change ensures manufacturing work orders are marked as started before they are completed. It prevents an incorrect date sequence that could block users with an error when finishing work orders immediately.
Original PR description
As we immediatly call button_done on the wworkorder, the start_date is greater than the end_date which raises a user error. So we start the workorder before setting it to done
Code cleanup and technical improvements
The payroll work entry export process has been reorganized to make its data structures clearer and easier to maintain. This is an internal improvement that should help future updates for Belgian payroll export providers be safer and more consistent, without changing day-to-day user workflows.
Original PR description
This Refactor aims to make the work entry export more readable and easier to maintain by defining explicit classes for each work entry data structure with explicit way to use them defined by their respective classes task-4244397
Documentation and clarification updates
This pull request adds a signed individual contributor agreement for jamesbcn. It is an administrative legal update that helps confirm contribution eligibility and does not change product behavior.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
When our own bank is used as a payment means, it shouldn't be populated in the OIOUBL XML. When using Peppol, the XML would ignore the endpoint that is set in the electronic invoicing settings, the <cbc:EndpointID> should be the defined Peppol endpoint and the schemeID should be 'GLN'. task-4017019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171945
Original PR description
When our own bank is used as a payment means, it shouldn't be populated in the OIOUBL XML. When using Peppol, the XML would ignore the endpoint that is set in the electronic invoicing settings, the <cbc:EndpointID> should be the defined Peppol endpoint and the schemeID should be 'GLN'. task-4017019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171945
step to reproduce: 1. create a db in 16.0 with appointment and account_payment module 2. create ``User-defined default`` (ir_default): Settings -> Technical -> User-defined Defaults - Field = Unit of Measure (product.template) - Default Value (JSON format) = 3 (pick any id that is not in the same category as `uom.product_uom_unit`) 2. upgrade db to 17.0 version below mentioned traceback will raised because appointment_account_payment is auto install. ``` Traceback (most recent call last):
Original PR description
step to reproduce: 1. create a db in 16.0 with appointment and account_payment module 2. create ``User-defined default`` (ir_default): Settings -> Technical -> User-defined Defaults - Field = Unit of…
step to reproduce:
1. create a db in 16.0 with appointment and account_payment module
2. create ``User-defined default`` (ir_default): Settings -> Technical -> User-defined Defaults
- Field = Unit of Measure (product.template)
- Default Value (JSON format) = 3 (pick any id that is not in the same category as `uom.product_uom_unit`)
2. upgrade db to 17.0 version below mentioned traceback will raised because appointment_account_payment is auto install.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 480, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 227, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 627, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/appointment_account_payment/data/product_data.xml:8
The default Unit of Measure and the purchase Unit of Measure must be in the same category.
View error context:
'-no context-'
```
why this traceback is raised because here in default values of [``uom_po_id``](https://github.com/odoo/odoo/blob/834e8a8789d1d451f62ae1e841845baf7d3931a4/addons/product/models/product_template.py#L36) getting default value of uom_id due to that other catefory uom_id is coming and [validation](https://github.com/odoo/odoo/blob/834e8a8789d1d451f62ae1e841845baf7d3931a4/addons/product/models/product_template.py#L456)
error raised and db got blocked
opw-4313919
upg-2182151
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#187825
Forward-Port-Of: odoo/odoo#187663When modifying an existing order in the PoS the sales team would be unset. Steps to reproduce: ------------------- * Open a table and add some items to it * Leave the table and go back on it 2 times * Validate the order > Observation: Go on the sale report and group by sale team, your order will appear under the "None" section Why the fix: ------------ We make sure that when we write on the order we will the values of the crm team defined on the pos config opw-4232473 --- I co
Original PR description
When modifying an existing order in the PoS the sales team would be unset. Steps to reproduce: ------------------- * Open a table and add some items to it * Leave the table and go back on it 2 times * Validate the order > Observation: Go on the sale report and group by sale team, your order will appear under the "None" section Why the fix: ------------ We make sure that when we write on the order we will the values of the crm team defined on the pos config opw-4232473 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184585
This re-adds the possibility for a user with approval rights, but no accounting rights to reset an expense to draft after it has been refused/approved. opw-4328933 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#187397
Original PR description
This re-adds the possibility for a user with approval rights, but no accounting rights to reset an expense to draft after it has been refused/approved. opw-4328933 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#187397
Description of the issue this PR addresses: Current behavior before PR: I. Pasting content within `blockquote` and `pre` elements resulted in each node being converted into separate `blockquote` or `pre` elements. II. When pasting the clipboard content as plain text (CTRL+SHIFT+V) inside a `PRE` element would convert each line break into a new paragraph. III. When text with a url is pasted within a pre tag the text is converted to a link. Desired behavior after PR is merged: I. `bl
Original PR description
Description of the issue this PR addresses: Current behavior before PR: I. Pasting content within `blockquote` and `pre` elements resulted in each node being converted into separate `blockquote` or…
Description of the issue this PR addresses: Current behavior before PR: I. Pasting content within `blockquote` and `pre` elements resulted in each node being converted into separate `blockquote` or `pre` elements. II. When pasting the clipboard content as plain text (CTRL+SHIFT+V) inside a `PRE` element would convert each line break into a new paragraph. III. When text with a url is pasted within a pre tag the text is converted to a link. Desired behavior after PR is merged: I. `blockquote` and `pre` should be considered like wrappers, allowing paragraph-related elements to be pasted inside them. II. When pasting the clipboard content as plain text within `pre`, every new line should be pasted within the `pre` tag. III. When text with a url is pasted within a pre tag it should not convert it to a link. IV. The `pre` tag does not have automatic word-wrapping or line-breaks as it is intended to keep the formatting of the text. This commit ensures that long text within `pre` tags does not overflow. task-4154465 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187312 Forward-Port-Of: odoo/odoo#178965
When confirming a BILL via Project's Updates, the generated payment terms line will have the analytic account of the project assigned Version: 17.0+ Steps to reproduce: - Have a project (i.e. Renovations) - Create a Purchase Order - Add on the line the analytic account of the project - Go to Projects Kanban view - Open Project 3 dots menu > Reporting > Project Updates - Open the created PO, Create Bill Issue: Analytic account will be assigned to the payment term line opw-4193509
Original PR description
When confirming a BILL via Project's Updates, the generated payment terms line will have the analytic account of the project assigned Version: 17.0+ Steps to reproduce: - Have a project (i.e. Renovations) - Create a Purchase Order - Add on the line the analytic account of the project - Go to Projects Kanban view - Open Project 3 dots menu > Reporting > Project Updates - Open the created PO, Create Bill Issue: Analytic account will be assigned to the payment term line opw-4193509 Forward-Port-Of: odoo/odoo#187612
*: pos_sale, pos_loyalty, pos_restaurant, pos_event Before all lines was sent to the backend to be processed, if the backend had a line that wasn't sent by the frontend, it was removed from the order. Now the frontend sends only modified lines to the backend, if a line is deleted from the frontend, it will be deleted from the backend too. But the backend doesn't remove lines that weren't sent by the frontend. This change was made to avoid losing information when the backend delete a lin
Original PR description
*: pos_sale, pos_loyalty, pos_restaurant, pos_event Before all lines was sent to the backend to be processed, if the backend had a line that wasn't sent by the frontend, it was removed from the order. Now the frontend sends only modified lines to the backend, if a line is deleted from the frontend, it will be deleted from the backend too. But the backend doesn't remove lines that weren't sent by the frontend. This change was made to avoid losing information when the backend delete a line that wasn't sent by the frontend. Cherry-picked from bdd57e0576ad2c061494676325a26644a8427c5e Forward-Port-Of: odoo/odoo#187268
The aim of this PR is to reduce the number of queries executed when opening the Replenishment View of the Inventory module. The following ideas were implemented ### Usage of `filtered` instead of a continue inside compute functions. `filtered` sets the _prefetch_ids to the records that matches the condition. This reduces the size of the expanded recordset whose computed field value needs to be recomputed. ### Batch `orderpoint._quantity_in_progress` The method `_quantity_in_progress`
Original PR description
The aim of this PR is to reduce the number of queries executed when opening the Replenishment View of the Inventory module. The following ideas were implemented ### Usage of `filtered` instead of a…
The aim of this PR is to reduce the number of queries executed when opening the Replenishment View of the Inventory module.
The following ideas were implemented
### Usage of `filtered` instead of a continue inside compute functions.
`filtered` sets the _prefetch_ids to the records that matches the condition. This reduces the size of the expanded recordset whose computed field value needs to be recomputed.
### Batch `orderpoint._quantity_in_progress`
The method `_quantity_in_progress` is designed to be used on a recordset. Calling it once before the for loop in
`stock_orderpoint.py:_compute_qty_to_order_computed` speeds up the whole compute function.
### Introduce a rule cache in `orderpoint._compute_rules`
A product without stock.rules have no impact on the call to `product_id._get_rules_from_locations`. It's only used to search on stock.rule in `procurement.group._search_rule`. We can therefore partition the orderpoints between orderpoints whose products have and don't have route_ids. This saves calls to `product_id._get_rules_from_locations` because now it only depends on (orderpoint.location_id, orderpoint.route_id) which have more hits than (orderpoint.product_id, orderpoint.location_id, orderpoint.route_id).
### Add preliminary checks to `_compute_days_to_order`
In both mrp and purchase_stock, `_compute_days_to_order` does some computations when the rule_ids' action is 'manufacture' and 'buy' respectively. This forces the computation of rule_ids on all orderpoints in self. Adding some precheck and prefiltering on self reduces the size of the recordset that needs the value of rule_ids.
### Introduce `_search_rule_for_warehouses`
Introduce a new method, `_search_rule_for_warehouses`. It's kind of batched version of `_search_rule` that works for multiple
location_dest_ids and warehouse_ids. It is designed to be called by `_get_rule`.
This method uses a _read_group to group the stock.rules by (location_dest_id, warehouse_id, route_id). It then constructs
a dict mappin (location_dest_id, route_id) -> warehouse_id -> stock.rule. This is done because when bool(warehouse_id) in parameter is False, any existing rule matching the location_dest_id, route_id is fine. When bool(warehouse_id) in parameter is True, the candidate stock.rules.warehouse must be equal to the parameter or False.
`_get_rule` is also revamped to find the correct stock.rule among the candidates. It first goes through the location hierarchy, starting from location_id, to build the rule_domain. Then, using the result of `_search_rule_for_warehouses`, it goes through the hierarchy again in the while loop, breaking at the first valid stock.rule found.
`_search_rule` is kept as is in case of overriding.
----
### Benchmark:
Customer saas-17.4 database with 10 000 active orderpoints and 140 active stock.rules.
Requests when opening Replenishment: run + search_panel_select_range + web_search_read
#### Before PR:
Number of queries: 90569 + 90471 + 90497 = 271 352 queries
Timings: 1min30 + 2min40 + 1min30 = 5min40
#### After PR:
Number of queries: 36819 + 36744 + 36767 = 110 330 queries
Timings: 43s + 1min20s + 54s = 2min57
Queries reduction: 250%
Speedup: 192%
NB: Should this PR be merged, it will be backported to 17.0 with some modifications.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182407This PR fixes an issue about the pager buttons having a wrong `border-radius` in RTL languages. Prior to this PR, the icons were defined at the button level. On top of being unusual, this had a side-effect. In RTL languages, we use a CSS `transform: rotate(180deg);` on our directional icons,in order to flip their direction and match the RTL or LTR. While this works totally fine, having the icon sets on the button directly means the whole button will be flipped, meaning the border-radius wi
Original PR description
This PR fixes an issue about the pager buttons having a wrong `border-radius` in RTL languages. Prior to this PR, the icons were defined at the button level. On top of being unusual, this had a…
This PR fixes an issue about the pager buttons having a wrong `border-radius` in RTL languages. Prior to this PR, the icons were defined at the button level. On top of being unusual, this had a side-effect. In RTL languages, we use a CSS `transform: rotate(180deg);` on our directional icons,in order to flip their direction and match the RTL or LTR. While this works totally fine, having the icon sets on the button directly means the whole button will be flipped, meaning the border-radius will be inverted. To prevent this behaviour, we simply need to use a `<i/>` tag for both icons, which will allow them to be flipped without affecting the button design. | 17.0 | This PR | |--------|--------| | <img width="159" alt="image" src="https://github.com/user-attachments/assets/2afc13b3-0b4b-4baf-a306-2196a3c83867"> | <img width="159" alt="image" src="https://github.com/user-attachments/assets/a405e167-6a0f-4a49-a15d-4e36735d95f5"> | task-4345233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187741
## Problem: When generating sorting URLs, the `post` dictionary only contains a single selected attribute. This is due to `request.params` only passing the first `attrib` parameter during dispatch, even though there can be multiple. ## Solution: Modify the `post` dictionary to store attributes as a list before passing it to the `_shop_get_query_url_kwargs` method. This ensures that all selected attributes are preserved and properly passed to the `keep` query parameters. ## Steps to repro
Original PR description
## Problem: When generating sorting URLs, the `post` dictionary only contains a single selected attribute. This is due to `request.params` only passing the first `attrib` parameter during dispatch, even though there can be multiple. ## Solution: Modify the `post` dictionary to store attributes as a list before passing it to the `_shop_get_query_url_kwargs` method. This ensures that all selected attributes are preserved and properly passed to the `keep` query parameters. ## Steps to reproduce: - Go to `/shop`. - Apply multiple attribute filters (ensure more than one attribute is selected). - Change the sorting option. - Only the first selected attribute is applied in the filter. opw-4244895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187694 Forward-Port-Of: odoo/odoo#183927
The Turkish National Identification Number (NIN) consists of 11 digits in the format NNNNNNNNNNN where the last two digits are check digits. The Vergi Kimlik Numarasi (VKN) is a 10-digit number in the format NNNNNNNNNN. The Vergi Kimlik Numaras is the Turkish tax identification number used for businesses and certain foreign individuals. task: 4282883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187524 Forward
Original PR description
The Turkish National Identification Number (NIN) consists of 11 digits in the format NNNNNNNNNNN where the last two digits are check digits. The Vergi Kimlik Numarasi (VKN) is a 10-digit number in the format NNNNNNNNNN. The Vergi Kimlik Numaras is the Turkish tax identification number used for businesses and certain foreign individuals. task: 4282883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187524 Forward-Port-Of: odoo/odoo#185884
Steps to reproduce: - Calendar > New > Tick 'Recurrent' - 'Until' => 'Number of repetitions' or 'Forever' - Set meeting start time in 5 mins - Add reminder => Notification - 15 Minutes > Save The notification is not sent, this is due to the use of 'until' to fetch the last event date of recurrent meetings despite that field only being set if the recrrence type is 'End date'. We want to check that date to avoid sending notifications for past meetings, but 'Number of Repetitions' recursions
Original PR description
Steps to reproduce: - Calendar > New > Tick 'Recurrent' - 'Until' => 'Number of repetitions' or 'Forever' - Set meeting start time in 5 mins - Add reminder => Notification - 15 Minutes > Save The notification is not sent, this is due to the use of 'until' to fetch the last event date of recurrent meetings despite that field only being set if the recrrence type is 'End date'. We want to check that date to avoid sending notifications for past meetings, but 'Number of Repetitions' recursions use a count instead of a date, and 'Forever' obviously doesn't need a date. Using the meeting end date instead should do the trick since it will always be in the future at the moment we want to send the reminder and it should never go over the last event date since no meeting record will be created after the recurrence ends anyway. opw-4247282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187423
Description of the issue/feature this PR addresses: Updated the code to make sure that the context object includes the current context. This change makes it easier to use all the relevant context-specific info in the process. Current behavior before PR: Currently, it only adds the warehouse information to the context variable. Desired behavior after PR is merged: The context object will include the warehouse information and the current context, ensuring that all necessary context
Original PR description
Description of the issue/feature this PR addresses: Updated the code to make sure that the context object includes the current context. This change makes it easier to use all the relevant context-specific info in the process. Current behavior before PR: Currently, it only adds the warehouse information to the context variable. Desired behavior after PR is merged: The context object will include the warehouse information and the current context, ensuring that all necessary context data is properly included when making the call. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187229 Forward-Port-Of: odoo/odoo#178546
`BLOCK` button in the workcenter blocking wizard should be in lowercase --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187384
Original PR description
`BLOCK` button in the workcenter blocking wizard should be in lowercase --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187384
When adding a rules in loyalty program that had a product set, if you try to refund an order containing this product you would get an error Steps to reproduce: ------------------- * Create a loyalty program with a rules that has product_ids set to any product. * Open PoS and make an order with the product set on the loyalty program * Validate the order * Try to refund the order > Observation: You get an error saying you cannot refund giftcards or eWallets Why the fix: -----------
Original PR description
When adding a rules in loyalty program that had a product set, if you try to refund an order containing this product you would get an error Steps to reproduce: ------------------- * Create a loyalty program with a rules that has product_ids set to any product. * Open PoS and make an order with the product set on the loyalty program * Validate the order * Try to refund the order > Observation: You get an error saying you cannot refund giftcards or eWallets Why the fix: ------------ This was happening because `trigger_product_ids` is related to `rule_ids.product_ids`. And when checking if a product is a giftcard or eWallet we first checked that `trigger_product_ids` was set. Now we only check the type of the program linked to a product. opw-4206226 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187231 Forward-Port-Of: odoo/odoo#184319
fiscalyear_last_day and fiscalyear_last_month can be defined in order to use fiscal years not aligned on the civil calendar. In enterprise, it works fine (it's overridden there to add functionalities), however, community forgot to make use of these fields, even though they are declared in it. Forward-Port-Of: odoo/odoo#187645 Forward-Port-Of: odoo/odoo#187250
Original PR description
fiscalyear_last_day and fiscalyear_last_month can be defined in order to use fiscal years not aligned on the civil calendar. In enterprise, it works fine (it's overridden there to add functionalities), however, community forgot to make use of these fields, even though they are declared in it. Forward-Port-Of: odoo/odoo#187645 Forward-Port-Of: odoo/odoo#187250
The aim of this commit is to allow detection of tax report that still need to be send easily by putting back the tax report to be sent activity that was deleted by commit 7bace07feea5 It also make sure those activities exists before using them to ensure the feature works even without updating the module. Context: The deletion of that activity makes this detection much harder and removes the possibility to know if was sent or not. Before the commit: It is impossible to know if a tax re
Original PR description
The aim of this commit is to allow detection of tax report that still need to be send easily by putting back the tax report to be sent activity that was deleted by commit 7bace07feea5 It also make sure those activities exists before using them to ensure the feature works even without updating the module. Context: The deletion of that activity makes this detection much harder and removes the possibility to know if was sent or not. Before the commit: It is impossible to know if a tax report has been sent or not. After the commit: The tax report to be sent can be found easily by looking for the tax report to be sent activity. We can assume the tax report was sent once the activity has been deleted. task-id: 4292304 Forward-Port-Of: odoo/enterprise#73615
This PR aims to increase the contrast between the default and the `focus` state of our `btn-primary`. | 17.0 | This PR | |--------|--------| | <img width="729" alt="image" src="https://github.com/user-attachments/assets/19c29432-4467-46bf-b240-41017d435c09"> | <img width="717" alt="image" src="https://github.com/user-attachments/assets/1efc15cc-6e10-460b-9040-4088cf3a98e0"> | Prior to this PR, the color was not dark enough to grant enough visual feedback on focus. This can be solve quic
Original PR description
This PR aims to increase the contrast between the default and the `focus` state of our `btn-primary`. | 17.0 | This PR | |--------|--------| | <img width="729" alt="image" src="https://github.com/user-attachments/assets/19c29432-4467-46bf-b240-41017d435c09"> | <img width="717" alt="image" src="https://github.com/user-attachments/assets/1efc15cc-6e10-460b-9040-4088cf3a98e0"> | Prior to this PR, the color was not dark enough to grant enough visual feedback on focus. This can be solve quickly by tweaking the value directly. task-3382308 Forward-Port-Of: odoo/enterprise#71793
This re-adds the possibility for a user with approval rights, but no accounting rights to reset an expense to draft after it has been refused/approved. opw-4328933 Forward-Port-Of: odoo/enterprise#73902
Original PR description
This re-adds the possibility for a user with approval rights, but no accounting rights to reset an expense to draft after it has been refused/approved. opw-4328933 Forward-Port-Of: odoo/enterprise#73902
## [FIX] l10n_be_reports: 281.50 and exchange diff The aim of this commit is to prevent a Zero devision error by excluding irrelevant 'zeroed' exchange difference. Context: Some misc entry with a 0 balance and some amount_currency might be present and taken into account for the computation. Such moves have an `amount_total_signed` equal to 0 leading to the zeroDivisionError issue in the query computation. Before the commit: When having such entry considered by the query, creating th
Original PR description
## [FIX] l10n_be_reports: 281.50 and exchange diff The aim of this commit is to prevent a Zero devision error by excluding irrelevant 'zeroed' exchange difference. Context: Some misc entry with a 0 balance and some amount_currency might be present and taken into account for the computation. Such moves have an `amount_total_signed` equal to 0 leading to the zeroDivisionError issue in the query computation. Before the commit: When having such entry considered by the query, creating the 325.50 form leads to a traceback. After the commit: Those irrelevant moves are ignored and the process carry on smoothly. task-id: None - Issue spotted on next ## [FIX] l10n_be_reports: 281.50, no 0-0-0-0-0 form The aim of this commit is to avoid generating a 281.50 form if there isn't any amounts to fill in the form. task-id: None - Dicussed with TSB Forward-Port-Of: odoo/enterprise#74142 Forward-Port-Of: odoo/enterprise#73842
This commits makes the redirect button label mandatory when there is a specified redirect URL. It also improves the hiding of the redirect label field when there is no redirect URL specified. task-4174120 Forward-Port-Of: odoo/enterprise#74003 Forward-Port-Of: odoo/enterprise#69866
Original PR description
This commits makes the redirect button label mandatory when there is a specified redirect URL. It also improves the hiding of the redirect label field when there is no redirect URL specified. task-4174120 Forward-Port-Of: odoo/enterprise#74003 Forward-Port-Of: odoo/enterprise#69866
### Steps to reproduce: - Create a delivery order for 5 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend (for instance by clicking the external link arrow next to the location). - Come back to the record #### > The line now displayed a 1/1 but does not records what remains: 0/4. ### Cause of the Issue: Setting a quantity of 1 on the move line will trigger a write call on the related stock move line to update
Original PR description
### Steps to reproduce: - Create a delivery order for 5 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend (for instance by…
### Steps to reproduce: - Create a delivery order for 5 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend (for instance by clicking the external link arrow next to the location). - Come back to the record #### > The line now displayed a 1/1 but does not records what remains: 0/4. ### Cause of the Issue: Setting a quantity of 1 on the move line will trigger a write call on the related stock move line to update its quantity. However, when you leave the barcode, even thought it will save these change, it will not split the move in 2 for the barcode app to be able to rely on the backend data to generate a correct sate of the record. Threfore, when you come back to the record, the main component will be regenerated from the backend values of the `get_barcode_data`: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L76-L80 And will onlydisplay the "1/1" line that was reported fromt he back end. ### Fix: The `split_uncompleted_moves` method taking care of splitting the moves for barcode data compatibility: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/models/stock_move.py#L9-L11 is already called when you exit the barcode via the exit button: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L228-L231 https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/models/barcode_picking_model.js#L762-L765 These were added by commit 2eb6465e4f18c701efdf28ea4b8f95f3119d3db8 However, it should IMO be called every time you leave the app that is just before destroying the component. Furthermore, note that it will only split the moves if a save happend (which is the expacted behavior). opw-4232106 --- Forward-Port-Of: odoo/enterprise#73664 Forward-Port-Of: odoo/enterprise#72453
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component - Add a component to be consumed in that operation #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on hte shopfloor. ### Cause of the issue: The only moves that are visible on "MrpDisplayRecord"'s are the move that are in `manual_consumption = T
Original PR description
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component -…
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component - Add a component to be consumed in that operation #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on hte shopfloor. ### Cause of the issue: The only moves that are visible on "MrpDisplayRecord"'s are the move that are in `manual_consumption = True` see: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L188-L191 However, when a product is added via the `action_add_component` > `add_product`, the `manual_consumption` of the move is computed as if it was added to the MO without being linked to a `bom_line_id`: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/wizard/additional_product.py#L36-L46 https://github.com/odoo/odoo/blob/2d652f42f63c2501b1a9feb7a4830ea3d7d05f51/addons/mrp/models/mrp_production.py#L1198 As a result the move_raw is added as a manual_consumption = False. ### Note: Thank to Commit eb751b5f861b25205dbb0b0fb90ddcdbbcd10f55 , the issue is not reproducible in 18.0 anymore. This was soved in the same manner: https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L36-L38 https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L107-L114 opw-4199156 Forward-Port-Of: odoo/enterprise#72569 Forward-Port-Of: odoo/enterprise#71803
7 changes
New functionality added to Odoo
This update adds the ability to include additional data columns in the account partner ledger report queries. Specifically, a new function allows for the addition of the 'date' field, providing more detailed information within the report. This improves the reporting capabilities for financial analysis.
Original PR description
### After this PR
You can add new column to the account partner ledger
Example:
```
def _get_additional_column_aml_query_values(self):
res = super()._get_additional_column_aml_query_values()
res +="account_move_line.date as date,"
return res
```Resolved issues and error corrections
This update resolves an issue where duplicate keyboard shortcuts were preventing users from accessing key actions within the Subscription module. The fix ensures that different actions have unique shortcuts, improving usability and preventing workflow disruptions. This change focuses on the 'Upsell' and 'Close' buttons.
Original PR description
**Issue:** Two different actions have the same shortcut making one action impossible to reach. **Expected:** Different actions should have different keyboard shortcuts. **Steps to reproduce:** - Activate Subscription app; - Open an existing subscription; - Press `ALT` (`CTRL` on MacOS) to display all shortcuts and look at the `UPSELL` and `CLOSE` buttons. **Cause:** The same `data-hotkey` has been used for both buttons. **Fix:** Change the `UPSELL` button shortcut to `ALT+E` (`CTRL+E` on MacOS) as for Odoo 17. opw-4306179 Forward-Port-Of: odoo/enterprise#73548
This update addresses a test failure within the Web Studio module, which is a key component of Odoo's website customization tools. The fix was triggered by a recent change from the Odoo community, ensuring continued stability and functionality for users building and managing their online storefronts.
Original PR description
This is a fix for failing test after the change introduced in the corrosponding community [PR] task-4240730 [PR]: https://github.com/odoo/odoo/pull/183129
This update resolves an issue where a key test failed when the 'pos_preparation_display' module wasn't present. The test has been moved to the correct module, ensuring consistent and reliable testing of the self-order POS functionality. This improves the overall stability of the system.
Original PR description
The test `test_self_order_preparation_disabling_preparation_display` in `test_self_order_common` does not work when the `pos_preparation_display` module is not installed. This is because there is no warning message when `pos_preparation_display` is absent. This commit changes the test location to the module `pos_self_order_preparation_display`.
This update resolves a technical issue that could cause errors in the generation of financial reports for Belgium. Specifically, it avoids division-by-zero errors when dealing with entries that have zero balances and currency amounts. The fix ensures reports are generated accurately and reliably.
Original PR description
## [FIX] l10n_be_reports: 281.50 and exchange diff The aim of this commit is to prevent a Zero devision error by excluding irrelevant 'zeroed' exchange difference. Context: Some misc entry with a 0 balance and some amount_currency might be present and taken into account for the computation. Such moves have an `amount_total_signed` equal to 0 leading to the zeroDivisionError issue in the query computation. Before the commit: When having such entry considered by the query, creating the 325.50 form leads to a traceback. After the commit: Those irrelevant moves are ignored and the process carry on smoothly. task-id: None - Issue spotted on next ## [FIX] l10n_be_reports: 281.50, no 0-0-0-0-0 form The aim of this commit is to avoid generating a 281.50 form if there isn't any amounts to fill in the form. task-id: None - Dicussed with TSB Forward-Port-Of: odoo/enterprise#73842
This update fixes a technical error that prevented users from configuring TaxCloud within the invoicing system. The issue stemmed from a problem accessing data related to CartItemsResponse, which has now been resolved. This ensures TaxCloud functionality is reliably available for US customers.
Original PR description
**Steps to reproduce:** - Edit \__init__.py file of account_taxcloud module to allow its installation - Install sale_account_taxcloud and industry_fsm_stock - In Invoicing settings, configure TaxCloud credentials - Configure TaxCloud fiscal position: * Country: United States * Detect Automatically: [enabled] - Go to "Field Service" - Create a new Task: * Title: [anything] * Customer: [a US customer] (e.g. Deco Addict) - Click on "Products" smart button - Add a product - Click on the task name in the breadcrumb to go back to the task **Issue:** A traceback is raised while trying to access CartItemResponse property of the None value of CartItemsResponse. opw-4199902
This update adjusts the color contrast of primary buttons in the Odoo Enterprise application. Previously, the focus state wasn't visually distinct enough, making it harder for users to easily identify which buttons were active. This change ensures better usability and accessibility by providing clear visual feedback when buttons receive focus.
Original PR description
This PR aims to increase the contrast between the default and the `focus` state of our `btn-primary`. | 17.0 | This PR | |--------|--------| | <img width="729" alt="image" src="https://github.com/user-attachments/assets/19c29432-4467-46bf-b240-41017d435c09"> | <img width="717" alt="image" src="https://github.com/user-attachments/assets/1efc15cc-6e10-460b-9040-4088cf3a98e0"> | Prior to this PR, the color was not dark enough to grant enough visual feedback on focus. This can be solve quickly by tweaking the value directly. task-3382308