Tuesday, October 15, 2024
99 changes
17 changes
Miscellaneous changes
Steps to reproduce ================== - Install web_studio,account_accountant - Enable Analytic accounts in Accounting - Navigate to Accounting > Analytic items - Open studio - Toggle show invisible - Edit the label of the last column => Xpath `/tree/field[17]` has no match Cause of the issue ================== - x_plan_* fields are dynamically added in get_views - Studio receives those fields and expect them to be part of the original arch. It assigns xpaths to them - When
Original PR description
Steps to reproduce ================== - Install web_studio,account_accountant - Enable Analytic accounts in Accounting - Navigate to Accounting > Analytic items - Open studio - Toggle show invisible - Edit the label of the last column => Xpath `/tree/field[17]` has no match Cause of the issue ================== - x_plan_* fields are dynamically added in get_views - Studio receives those fields and expect them to be part of the original arch. It assigns xpaths to them - When making an edit, studio create an inheriting view that is applied before the x_plan fields are added. => Xpaths do not match Solution ======== When in studio, don't add x_plan_* fields opw-4210657 Forward-Port-Of: odoo/odoo#183509
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White' variant to 0. - Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants. **Issue:** - The base_unit_price for product variants was not being displayed when the base_unit_price of one variant wa
Original PR description
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White'…
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White' variant to 0. - Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants. **Issue:** - The base_unit_price for product variants was not being displayed when the base_unit_price of one variant was set to 0. This caused the price to disappear for all variants in the template, even when other variants had valid base_unit_price values. **Cause:** The condition in the template was relying on a falsy check, which incorrectly evaluated 0 as a falsy value and prevented the display of base_unit_price for all variants, including those with valid prices. **Fix:** The condition in the template was updated to check for the existence of base_unit_price explicitly using if condition effectively. This ensures that even when base_unit_price is 0, it will still be displayed, while preventing the field from disappearing for other variants. Affected Version: 17.0~master opw-4061530 Forward-Port-Of: odoo/odoo#183281
Forward-Port-Of: odoo/odoo#183000
Original PR description
Forward-Port-Of: odoo/odoo#183000
The check is comparing an empty recordset to False, which is not equal. Credits to @JZorko https://github.com/odoo/odoo/pull/171478 task-no Forward-Port-Of: odoo/odoo#183545
Original PR description
The check is comparing an empty recordset to False, which is not equal. Credits to @JZorko https://github.com/odoo/odoo/pull/171478 task-no Forward-Port-Of: odoo/odoo#183545
Before this commit, only the distribution for Invoices had the modulo 390 tax grids. This commit will add the tax grid of the modelo 390 for credit node. They are the exact opposite has the one on the invoice. task: 4180225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180029
Original PR description
Before this commit, only the distribution for Invoices had the modulo 390 tax grids. This commit will add the tax grid of the modelo 390 for credit node. They are the exact opposite has the one on the invoice. task: 4180225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180029
Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we forgot some use cases opw-4072691 Forward-Port-Of: odoo/odoo#183347 Forward-Port-Of: odoo/odoo#182791
Original PR description
Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we forgot some use cases opw-4072691 Forward-Port-Of: odoo/odoo#183347 Forward-Port-Of: odoo/odoo#182791
Before this PR: - The state field on the res_company form is not automatically populated based on the entered GST number - On the res_company and res_partner, even if there is a mismatch between the GST number and state no warning is shown After this PR: - The state field on the res_company form now automatically populates based on the entered GST number - A validation check is implemented for both res_company and res_partner forms. Users will receive a warning if there's a discrepancy be
Original PR description
Before this PR: - The state field on the res_company form is not automatically populated based on the entered GST number - On the res_company and res_partner, even if there is a mismatch between the GST number and state no warning is shown After this PR: - The state field on the res_company form now automatically populates based on the entered GST number - A validation check is implemented for both res_company and res_partner forms. Users will receive a warning if there's a discrepancy between the GST number and the corresponding state. Task ID - 4055948 Forward-Port-Of: odoo/odoo#178910
A frequent issue is the GC cron times-out when deleting attachments, due to a lack of index on the Fkey `message_main_attachment_id`, forcing Postgres to do a `Seq.Scan` on potentially really large tables to check if it needs to set the Fkey to `NULL`. Therefor we add the missing index. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183302
Original PR description
A frequent issue is the GC cron times-out when deleting attachments, due to a lack of index on the Fkey `message_main_attachment_id`, forcing Postgres to do a `Seq.Scan` on potentially really large tables to check if it needs to set the Fkey to `NULL`. Therefor we add the missing index. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183302
opw-4224602 Forward-Port-Of: odoo/odoo#183559
Original PR description
opw-4224602 Forward-Port-Of: odoo/odoo#183559
This PR contains three small commits: [FIX] hw_posbox_homepage: make homepage responsive The new OWL IoT homepage is currently not responsive on mobile due to a missing HTML meta tag. This PR adds that tag as well as tweaking the width to not be cutoff on small screens. [FIX] hw_posbox_homepage: show error messages The IoT box returns error messages when connecting to a server fails. The new OWL homepage currently does not show these or any other sign of failure, instead just
Original PR description
This PR contains three small commits: [FIX] hw_posbox_homepage: make homepage responsive The new OWL IoT homepage is currently not responsive on mobile due to a missing HTML meta tag. This PR adds…
This PR contains three small commits: [FIX] hw_posbox_homepage: make homepage responsive The new OWL IoT homepage is currently not responsive on mobile due to a missing HTML meta tag. This PR adds that tag as well as tweaking the width to not be cutoff on small screens. [FIX] hw_posbox_homepage: show error messages The IoT box returns error messages when connecting to a server fails. The new OWL homepage currently does not show these or any other sign of failure, instead just seeming unresponsive. This PR now shows the error messages again, as well as disabling the 'Connect' button while loading. [FIX] hw_posbox_homepage: allow new IoT connection tokens This change backports the URL helpers from 18.0, and modifies the homepage controller to allow the new type of IoT token. The result of this is that IoT boxes on v17 can connect to v18 databases via the token. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183169
Issue: ====== webp images doesn't appear in outlook Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover block and replace the background image with a .webp one - Add text-image block and replace the image with a .webp one - Test it and open the email with outlook desktop - The images doesn't appear in the email. Solution: ========= We replace the .webp images when converting inline. For image elements: we just create another img
Original PR description
Issue: ====== webp images doesn't appear in outlook Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover block and replace the background image with a .webp one - Add text-image block and replace the image with a .webp one - Test it and open the email with outlook desktop - The images doesn't appear in the email. Solution: ========= We replace the .webp images when converting inline. For image elements: we just create another img element with the png version. For background-image: we create the png image and we replace the url of background-image style with the dataURL of the canvas. opw-3776054 Forward-Port-Of: odoo/odoo#177216
This commit will add an underscore to a dict key to avoid any problem that might arise in the future. no task id Related commit: https://github.com/odoo/odoo/commit/2f2f5f63e8d0ab9729bffa25192a7ef9a2da5fb9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183531
Original PR description
This commit will add an underscore to a dict key to avoid any problem that might arise in the future. no task id Related commit: https://github.com/odoo/odoo/commit/2f2f5f63e8d0ab9729bffa25192a7ef9a2da5fb9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183531
Steps ----- - Install Employees app. - Have a user with "Settings" Administration rights and no "Employees" rights. - Open an employee profile, open "Work Information" tab and click on an employee in the organizational tree. ** Access error for `message_main_attachment_id` field ** Cause ----- We are checking if the user has access rights on the employee https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L294 and redirecting to th
Original PR description
Steps ----- - Install Employees app. - Have a user with "Settings" Administration rights and no "Employees" rights. - Open an employee profile, open "Work Information" tab and click on an employee in the organizational tree. ** Access error for `message_main_attachment_id` field ** Cause ----- We are checking if the user has access rights on the employee https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L294 and redirecting to the private employee if that's the case. However, this does't guarantee that the user has the `hr.group_hr_user` group necessary to access some fields that were added with `groups="hr.group_hr_user"` https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L122 opw-4096073 Forward-Port-Of: odoo/odoo#182726
Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the to
Original PR description
Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the toolbar. Solution: ========= Revert the old fix and instead we ignore any `keydown` event when the transform container is in the dom (which means we are currently transforming an image). task-4235140 [1]: https://github.com/odoo/odoo/commit/463c248e291a53c80365ae606c7cf39e13cd290b Forward-Port-Of: odoo/odoo#182723
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, t
Original PR description
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page -…
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, the problem corrects itself on the second refresh. - Could not reproduce on the runbot but could do it locally and on Odoo.SH (in 16.0) and on `odoo.com` free database (18.0). This issue was already discussed more than a year ago (https://github.com/odoo/odoo/pull/110207) but was finally closed without being merged. The problem can now be fully reproduced while previously, it was a bit blurry. 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#182640
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure you have 0 units in stock - Create and confirm a sale order with 2 lines: - 1 x P1 - 1 x P2 > A delivery and 2 purchase order were created (one for each product) - Cancel the purchase orderfor P2 (it will not work with P1 hehe) - Go back to the SO and decrease the qty of P2 to 0 ###
Original PR description
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure…
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure you have 0 units in stock - Create and confirm a sale order with 2 lines: - 1 x P1 - 1 x P2 > A delivery and 2 purchase order were created (one for each product) - Cancel the purchase orderfor P2 (it will not work with P1 hehe) - Go back to the SO and decrease the qty of P2 to 0 #### > A return is created from patner to stock instead of updating the P2 move of the delivery ### Cause of the issue: When the sale order was confirmed the moves created for the delivery were both used the same procurment group and their `procure_method` was set to `make_to_order`. When the purchase order for P2 is cancelled, the delivery move associated with the related sol is cancelled and its `procure_method` is set to `make_to_stock` here: https://github.com/odoo/odoo/blob/c424fded8660de628bfcf3937806cc72c8410434/addons/purchase_stock/models/purchase.py#L148 Then, when you decrease the qty of the SOL from 0 to 1, a procurement for -1 unit of P2 will be created and run by the `_action_launch_stock_rule`. A negative move will then be created and confirm with a `procure_method`: `make_to_stock` here: https://github.com/odoo/odoo/blob/c424fded8660de628bfcf3937806cc72c8410434/addons/stock/models/stock_rule.py#L275-L277 Because the `procure_method` used at the creation of the negative move is determined from the `procure_method` of the first move related to the procurement group with a positive qty (here the P1 move): https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_rule.py#L257-L260 As such, the negative P2 move will have a different `procure_method` than the positive P2 move and they will not be merged here: https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_move.py#L1384 ### Fix: The fix proposed in commit 65d5e7900f41aa7f65159f8f4cdb0c6638eaf8ca and introducing the lines: https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_rule.py#L257-L260 works perfectly fine in most situtations but should considers only the moves related to the procurment group that concerns the same product to also work in the above case. opw-4214369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183120 Forward-Port-Of: odoo/odoo#182802
30 changes
Enhancements to existing features
The planning time-off module's automated tests were moved to a newer testing framework. This helps keep future maintenance more reliable without changing day-to-day user behavior.
Original PR description
Purpose of this PR: This PR aims to convert QUnit tests which rely on mail/test_utils to hoot. Part of task: 3818666
52 changes
Enhancements to existing features
Developers can now adjust which website content containers are monitored for third-party iframe blocking through a dedicated website method instead of changing hard-coded logic. This keeps consent protection behavior intact while making customer-specific website customizations cleaner and safer to maintain.
Original PR description
Commit [958b41c4] added support to prevent 3rd-party iframes from loading without proper consent. As some iframes are built client-side, preventing them from loading required getting their container by their class. Those classes are stored in a set. Allowing any user to update that set does not make sense, but to make it possible for developers to update it through custos, this commit retrieves it from a method on the Website model instead of hard-coding it in the middle of a function. [958b41c4]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1 task-4045932
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Description of the issue/feature this PR addresses: When a new account is added and the chart is loaded for the child company before the parent, the account will be created for both companies Current behavior before PR: Desired behavior after PR is merged: see also https://github.com/odoo/enterprise/pull/71421
Original PR description
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Description of the issue/feature this PR addresses: When a new account is added and the chart is loaded for the child company before the parent, the account will be created for both companies Current behavior before PR: Desired behavior after PR is merged: see also https://github.com/odoo/enterprise/pull/71421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182706
The accounting reports tests now set the country before applying country-based availability rules. This keeps the test process aligned with the latest validation requirements and helps prevent avoidable failures during development.
Original PR description
In the community PR, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643
This update standardizes the names, categories, and short descriptions of service-related Odoo modules. It makes app listings clearer and more consistent for users browsing project, timesheet, helpdesk, field service, and planning features.
Original PR description
Cleaning of the name, category and summary of every module linked to services applications (project, timesheet, helpdesk, field service, planning) taskid:3524126
This update aligns internal Python class names with their corresponding Odoo model names across accounting-related modules. It improves code consistency and maintainability without changing day-to-day business workflows.
Original PR description
see: https://github.com/odoo/odoo/pull/178200
Resolved issues and error corrections
This fix ensures companies are listed in the expected order in account reports, with the main company shown before its branches. This helps keep report results consistent and avoids confusion when reviewing multi-company data.
Original PR description
Companies will be returned main first then branches. reshuffling the expected results
Miscellaneous changes
PoS receipt should show fiskaly information but they are not shown Steps to reproduce: ------------------- * Setup you db with fiskaly * Start a PoS and sell any product > Observation: The receipt doesn't contain any information opw-4216415 Forward-Port-Of: odoo/enterprise#71779
Original PR description
PoS receipt should show fiskaly information but they are not shown Steps to reproduce: ------------------- * Setup you db with fiskaly * Start a PoS and sell any product > Observation: The receipt doesn't contain any information opw-4216415 Forward-Port-Of: odoo/enterprise#71779
1. Create Vendor bill and register payment 2. Create credit note for the vendor bill 4. Open the CABA entry created from vendor bill 5. Reverse Entry 6. Check DIOT report Issue: DIOT report shows negative line, but it not allowed CABA Entries should not be reverted, as the reversal generate a document with negative tax grid. They will revert automatically after the original document is reset to draft. opw-4142232 Forward-Port-Of: odoo/enterprise#71414 Forward-Port-Of: odoo/enterprise#
Original PR description
1. Create Vendor bill and register payment 2. Create credit note for the vendor bill 4. Open the CABA entry created from vendor bill 5. Reverse Entry 6. Check DIOT report Issue: DIOT report shows negative line, but it not allowed CABA Entries should not be reverted, as the reversal generate a document with negative tax grid. They will revert automatically after the original document is reset to draft. opw-4142232 Forward-Port-Of: odoo/enterprise#71414 Forward-Port-Of: odoo/enterprise#70223
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period. Forward-Port-Of: odoo/enterprise#71780 Forward-Port-Of: odoo/enterprise#71642
Original PR description
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period. Forward-Port-Of: odoo/enterprise#71780 Forward-Port-Of: odoo/enterprise#71642
Steps to reproduce: - Any project > Gantt view > Add any groupby filter The weekends are no longer greyed out like they were without the filter. This happens because _gantt_unavailablities in this module defers calls to the super() method which is empty unless the field is user_id. This makes sense since we don't want to get unavailability by employee if the tasks are not sorted by user, we could however use company leaves instead of leaving every day as available under other filters. opw
Original PR description
Steps to reproduce: - Any project > Gantt view > Add any groupby filter The weekends are no longer greyed out like they were without the filter. This happens because _gantt_unavailablities in this module defers calls to the super() method which is empty unless the field is user_id. This makes sense since we don't want to get unavailability by employee if the tasks are not sorted by user, we could however use company leaves instead of leaving every day as available under other filters. opw-4237953 Forward-Port-Of: odoo/enterprise#71841
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integr
Original PR description
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integrations so the constraint should only show for journal entries of this type. opw-4151193 Forward-Port-Of: odoo/enterprise#71833 Forward-Port-Of: odoo/enterprise#71543
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object to the strptime function of datetime which in reality it needs to receive a string object instead. This raises a TypeError Since the objective is to set a string date, we convert the date_order into a string date using strftime function from datetime mod
Original PR description
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda…
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object to the strptime function of datetime which in reality it needs to receive a string object instead. This raises a TypeError Since the objective is to set a string date, we convert the date_order into a string date using strftime function from datetime module - Install 'Sales' application and 'l10n_mx_edi' module - In a company with mexican localization selected go to Sales > Quotations and create a new Order - Select a contact with the Addenda Autozone selected - Confirm it and create the corresponding invoice - Confirm the invoice and generate the CFDI 2. Traceback with invoice that have multiple sale order linked. In attribute t-att-PODATE for the Autozone Addenda is not expecting a recordset when initializing the value of sale_id, this causes a ValueError: expected singleton error when retrieving value of date_order when we create a invoice for multiple sale orders Initialize sale_id with the first order retrieved to use it task-no Forward-Port-Of: odoo/enterprise#71939 Forward-Port-Of: odoo/enterprise#71875
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Forward-Port-Of: odoo/enterprise#71953 Forward-Port-Of: odoo/enterprise#71421
Original PR description
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Forward-Port-Of: odoo/enterprise#71953 Forward-Port-Of: odoo/enterprise#71421
…checkout _* = website_sale_renting, website_sale_stock_renting Added the 'tourUtils.confirmOrder(),' to fix the tour. Forward-Port-Of: odoo/enterprise#71618
Original PR description
…checkout _* = website_sale_renting, website_sale_stock_renting Added the 'tourUtils.confirmOrder(),' to fix the tour. Forward-Port-Of: odoo/enterprise#71618
Before this commit the following error was observed: File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 112, in test_subscription_invoice_automate self.assertInvoicePaid(self.invoice) File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 66, in assertInvoicePaid self.assertEqual(invoice.amount_paid, invoice.amount_total, "Amount should match") AssertionError: 1206.3700000
Original PR description
Before this commit the following error was observed:
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 112, in test_subscription_invoice_automate
self.assertInvoicePaid(self.invoice)
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 66, in assertInvoicePaid
self.assertEqual(invoice.amount_paid, invoice.amount_total, "Amount should match")
AssertionError: 1206.3700000000001 != 1206.37 : Amount should match
Runbot errors: 100947, 100946, 100945, 100944, 100944
Forward-Port-Of: odoo/enterprise#71894
Forward-Port-Of: odoo/enterprise#71843When invoicing an order from the PoS the invoice was not signed by the government before rendering the pdf of the invoice. This lead to a missing QR Code on the invoice. Steps to reproduce: ------------------- * Install l10n_pe_edi_pos module * Open the PoS * Make an order and invoice it > Observation: The invoice should contains a QR Code attesting that the document has been signed by the government but it's not Why the fix: ------------ The issue was that the invoice was sent to
Original PR description
When invoicing an order from the PoS the invoice was not signed by the government before rendering the pdf of the invoice. This lead to a missing QR Code on the invoice. Steps to reproduce: ------------------- * Install l10n_pe_edi_pos module * Open the PoS * Make an order and invoice it > Observation: The invoice should contains a QR Code attesting that the document has been signed by the government but it's not Why the fix: ------------ The issue was that the invoice was sent to the government after the invoice was rendered. To fix it we make the call to the government manually instead of waiting for the CRON to send it. We also cancel the CRON for this specific invoice so that it is not called twice. This is based on what is done here : https://github.com/odoo/odoo/blob/647197c0eae7ef786fa3d1aeafeafd1d14fe0fae/addons/l10n_es_pos_tbai/models/pos_order.py#L18-L29 opw-4165399 Forward-Port-Of: odoo/enterprise#71926 Forward-Port-Of: odoo/enterprise#70583
Issue: When a sale order made from the website with a pickup point (for instance using a sendcloud delivery method) is confirmed, a new partner is created to mix the data of the partner making the order and the address of the pickup point. If the partner is named Bob, this new partner will be named Bob, Bob. It woul dbe much clearer if he was named: Bob, pickup point name. opw-4181787 Forward-Port-Of: odoo/enterprise#71674 Forward-Port-Of: odoo/enterprise#71567
Original PR description
Issue: When a sale order made from the website with a pickup point (for instance using a sendcloud delivery method) is confirmed, a new partner is created to mix the data of the partner making the order and the address of the pickup point. If the partner is named Bob, this new partner will be named Bob, Bob. It woul dbe much clearer if he was named: Bob, pickup point name. opw-4181787 Forward-Port-Of: odoo/enterprise#71674 Forward-Port-Of: odoo/enterprise#71567
Description of the issue this commit addresses: Since recently, the <[X] To Pay> and <[X] Late> buttons don't send the user to an account.move.line model view anymore but to an account.move model one but when that change was made, the computation of the number of items on the dashboard was not changed so it was still counting the amount of account.move. line there was in the account.move items that were shown in the view resulting in wrong totals. --- Steps to reproduce: 1. Install a
Original PR description
Description of the issue this commit addresses: Since recently, the <[X] To Pay> and <[X] Late> buttons don't send the user to an account.move.line model view anymore but to an account.move model one…
Description of the issue this commit addresses:
Since recently, the <[X] To Pay> and <[X] Late> buttons don't send the user to an account.move.line model view anymore but to an account.move model one but when that change was made, the computation of the number of items on the dashboard was not changed so it was still counting the amount of account.move. line there was in the account.move items that were shown in the view resulting in wrong totals.
---
Steps to reproduce:
1. Install account
2. Create new Vendor Bill with a split payment term ("30% now, Balance 60 Days" for example) on today's date for Bill Date.
3. Go to the dashboard, click the <[X] To Pay> button.
4. the amount of moves in the view that is opened with the button is one above the value of "X" in the button.
This is due to using a split payment term that creates two installment for a single vendor bill hence counting one more aml than there are moves.
---
Desired behavior after this commit is merged:
The right amount of To Pay and Late moves is shown at all times.
---
Note on the fix:
The fix for this issue is in the community PR of the bundle, the fix modifies a method which was overriden in enterprise and this PR addresses the override to match with the new version of the method.
---
Community PR: https://github.com/odoo/odoo/pull/181535
No task
Forward-Port-Of: odoo/enterprise#70725…ountant *: account_reports, account_online_synchronization Configuration steps on empty Bank, Misc journals should not be shown for users that do not have the Administrator/Accountant rights. They don't have the necessary rights to execute those actions anyway. This commit hide the configuration steps for non-accountant users. task-4149584 Forward-Port-Of: odoo/enterprise#71210
Original PR description
…ountant *: account_reports, account_online_synchronization Configuration steps on empty Bank, Misc journals should not be shown for users that do not have the Administrator/Accountant rights. They don't have the necessary rights to execute those actions anyway. This commit hide the configuration steps for non-accountant users. task-4149584 Forward-Port-Of: odoo/enterprise#71210
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create thread._message_auto_subscribe(create_values, followers_existing_policy='update') File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscr
Original PR description
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File…
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed:
``py
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create
thread._message_auto_subscribe(create_values, followers_existing_policy='update')
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscribe
res = self._message_auto_subscribe_followers(updated_values, def_ids)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/enterprise/sale_subscription/models/account_move.py", line 76, in _message_auto_subscribe_followers
if salesperson and user_id == salesperson.id and user_id != self.env.user.id:
^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.users(56, 60)
```
Forward-Port-Of: odoo/enterprise#71478
Forward-Port-Of: odoo/enterprise#71188**Current behavior:** If you have a production opened in barcode and consume part of a component line to produce part of the final product, leave the transfer, then re-open it and confirm -> create the backorder, the resulting backorder will have split the remaining raw moves in an unintuitive manner. **Expected behavior:** The backorder should have one move for the remaining component quantity. **Steps to reproduce:** 1. Create a production for 10 of some final product consuming 1
Original PR description
**Current behavior:** If you have a production opened in barcode and consume part of a component line to produce part of the final product, leave the transfer, then re-open it and confirm -> create…
**Current behavior:**
If you have a production opened in barcode and consume part of a
component line to produce part of the final product, leave the
transfer, then re-open it and confirm -> create the backorder,
the resulting backorder will have split the remaining raw moves
in an unintuitive manner.
**Expected behavior:**
The backorder should have one move for the remaining component
quantity.
**Steps to reproduce:**
1. Create a production for 10 of some final product consuming 10
some component -> Confirm
2. Open the production in barcode, add 5 of the final product to
its line and 5 of the component to its line -> exit the
transfer view
3. Reopen the production and validate it -> create backorder
4. Open the backorder to see the odd split of the component
product's moves
**Cause of the issue:**
When creating the backorder we normally expect each component
product to be encapsulated by a single line- so the split that
occurs when we leave the transfer initially without validating
which creates 2 moves for the same product means we get 2 moves
for the component for half of the remaining quantity for that
component.
**Fix:**
Incomplete barcode lines for production transfers should get
split into additional move lines as opposed to moves.
opw-4148050
Forward-Port-Of: odoo/enterprise#71636
Forward-Port-Of: odoo/enterprise#69149Various v18 bugfixes for MRP before the feature freeze. Current behaviour: 1. Entering the Shop Floor from a WO searches the WOs in that workcenter by state by default. 2. The timer field is blank if the WO is in ready or pending states. 3. The month substring in the weekly MPS display column header shows the month of the starting date if the given period straddles two months. Desired behaviour: 1. Entering the Shop Floor from a WO reflects the same behaviour as entering from MO, which i
Original PR description
Various v18 bugfixes for MRP before the feature freeze. Current behaviour: 1. Entering the Shop Floor from a WO searches the WOs in that workcenter by state by default. 2. The timer field is blank if the WO is in ready or pending states. 3. The month substring in the weekly MPS display column header shows the month of the starting date if the given period straddles two months. Desired behaviour: 1. Entering the Shop Floor from a WO reflects the same behaviour as entering from MO, which is the suppression of the default filter. (Depends on #68419) 2. 'Pending' text is displayed if the WO is in pending state. 3. It shows the month of the end date instead. Task ID: [4154879](https://www.odoo.com/odoo/966/tasks/4154879) Forward-Port-Of: odoo/enterprise#69897
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an a
Original PR description
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an accounting report as XLSX file, we add a column for the account codes on the very left of the sheet. This looks a bit weird and is not the most important information to have as a first column. In this commit, we move the column to the right so the name of the line will be first, followed by the account code (if applicable). We also add a column name for the account codes. task-3986483 Forward-Port-Of: odoo/enterprise#71866 Forward-Port-Of: odoo/enterprise#67111
Hide temporarily withhold subtotals widget in withhold wizard and form view There is an JS error about account-tax-totals-field-for-withhold widget Forward-Port-Of: odoo/enterprise#71806
Original PR description
Hide temporarily withhold subtotals widget in withhold wizard and form view There is an JS error about account-tax-totals-field-for-withhold widget Forward-Port-Of: odoo/enterprise#71806
- Replicate error in runbot v18: 1. Create a Vendor Bill with partner 'Instituto Ecuatoriano de Seguridad Social' 2. Add a reimbursement line with all the fields set up 3. Press the save button - Solution: Call the method _round_base_lines_tax_details before the _get_tax_totals_summary method to add the raw base amount in the base lines dictionary - Screenshot 18.0 runbot  Forward-Port-Of: od
Original PR description
- Replicate error in runbot v18: 1. Create a Vendor Bill with partner 'Instituto Ecuatoriano de Seguridad Social' 2. Add a reimbursement line with all the fields set up 3. Press the save button - Solution: Call the method _round_base_lines_tax_details before the _get_tax_totals_summary method to add the raw base amount in the base lines dictionary - Screenshot 18.0 runbot  Forward-Port-Of: odoo/enterprise#71705
In v18 I installed the EC localization and the first EC company was created. I try to create the second EC company. Cannot create and I get the following error Solution Use `@template` annotation to create journals in l10n_ec_edi Additionally, we call the method `_l10n_ec_configure_default_withhold_accounts` in load() to set accounts by default  Forward-Port-Of: odoo/enterprise#71495
Original PR description
In v18 I installed the EC localization and the first EC company was created. I try to create the second EC company. Cannot create and I get the following error Solution Use `@template` annotation to create journals in l10n_ec_edi Additionally, we call the method `_l10n_ec_configure_default_withhold_accounts` in load() to set accounts by default  Forward-Port-Of: odoo/enterprise#71495
…sales Steps to reproduce:: [l10n_fr] - create a customer, BE Company; delivery adress USA - create an invoice for the customer - Go to EC Sales Report Issue: The transaction is displayed Solution: When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries opw-4131299 Forward-Port-Of: odoo/enterprise#69960
Original PR description
…sales Steps to reproduce:: [l10n_fr] - create a customer, BE Company; delivery adress USA - create an invoice for the customer - Go to EC Sales Report Issue: The transaction is displayed Solution: When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries opw-4131299 Forward-Port-Of: odoo/enterprise#69960
Error is generated because ``applicant_id`` field is used to create record of ``hr.candidate.skill`` model. Error: ``ValueError: Invalid field 'applicant_id' on model 'hr.candidate.skill'`` https://github.com/odoo/enterprise/blob/0c7c006dcd0ba53ff9a7aa8ca2446794505a6916/hr_recruitment_extract/models/hr_candidate.py#L60-L61 Here, ``applicant_id`` field is used instead of ``candidate_id`` field. sentry-5983999720 Forward-Port-Of: odoo/enterprise#71789
Original PR description
Error is generated because ``applicant_id`` field is used to create record of ``hr.candidate.skill`` model. Error: ``ValueError: Invalid field 'applicant_id' on model 'hr.candidate.skill'`` https://github.com/odoo/enterprise/blob/0c7c006dcd0ba53ff9a7aa8ca2446794505a6916/hr_recruitment_extract/models/hr_candidate.py#L60-L61 Here, ``applicant_id`` field is used instead of ``candidate_id`` field. sentry-5983999720 Forward-Port-Of: odoo/enterprise#71789
https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 changed how the chatter is added to a view and updated the codebase except for this module. This commit fixes this. Forward-Port-Of: odoo/enterprise#71878
Original PR description
https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 changed how the chatter is added to a view and updated the codebase except for this module. This commit fixes this. Forward-Port-Of: odoo/enterprise#71878
Partner Ledgers can be sent to Partners by email which is usually signed by the `followup_responsible` user, however, `_get_followup_responsible` is defined in `account_followup` which may not be installed. To solve this dependency issue, we define the method in `account_reports`, and the method in `account_followup` now extends it. No task - issue identified by marketing team upon review of the email template. Forward-Port-Of: odoo/enterprise#71923
Original PR description
Partner Ledgers can be sent to Partners by email which is usually signed by the `followup_responsible` user, however, `_get_followup_responsible` is defined in `account_followup` which may not be installed. To solve this dependency issue, we define the method in `account_reports`, and the method in `account_followup` now extends it. No task - issue identified by marketing team upon review of the email template. Forward-Port-Of: odoo/enterprise#71923
This task was created to modify the demo data for Argentina, to avoid using real partner information. latam-task-1239 adhoc-task-41734 Forward-Port-Of: odoo/enterprise#71471 Forward-Port-Of: odoo/enterprise#71230
Original PR description
This task was created to modify the demo data for Argentina, to avoid using real partner information. latam-task-1239 adhoc-task-41734 Forward-Port-Of: odoo/enterprise#71471 Forward-Port-Of: odoo/enterprise#71230
This update aligns the accounting app with a related platform change that prevents accidental changes or deletions of analytic entries tied to journal items. It helps preserve the integrity of accounting data while still allowing approved system processes to make necessary updates.
Original PR description
Adapt to community PR, which add a context key requirement in order to delete an analytic item related to a journal item. Community PR: odoo/odoo#182608 task-3977961
Resolved issues and error corrections
This fixes account code availability checks so codes mapped from other companies no longer incorrectly block new accounts. Businesses using multiple companies can reuse valid account codes in the intended company without unnecessary setup conflicts.
Original PR description
In #181352, we relaxed the constraint that prevented accounts from being mapped to an account code in a company the account doesn't belong to, if there already exists an account in that company that already has that code. That constraint was annoying because it meant that mapping an account to a code in a different company would "reserve" that code in the other company's CoA. When we relaxed that constraint, we forgot to modify '_search_new_account_codes' such that the previously-reserved codes would now be available for new accounts. This commit fixes that. task-none
Discount descriptions on sales orders now display more clearly with the updated product description layout. This helps sales teams and customers better understand applied discounts without confusing or poorly formatted text.
Original PR description
c3e98851d9b509e97fbcc78616ff5580222425d1 introduced a new widget for products' descriptions on SO. This commit aims to fine-tune the behavior of discount description to better fit the new display.
The message action label was shortened from “Copy Message Link” to “Copy Link” in mail and live chat. This makes the interface cleaner and easier to scan without changing the underlying behavior.
Original PR description
Shorter is better. Part of Task-4260440 
The Italian electronic invoicing direct debit flow now identifies payments more accurately after a status change in Odoo. This prevents already paid transactions from being missed when determining the payment method, reducing errors in Italian payment reporting.
Original PR description
When computing the payment method, we searched for `in_process` but now we consider them `paid`, so we're just checking for `not draft` payments instead. Related PR: odoo/odoo#178235 Runbot link: https://runbot.odoo.com/web#id=76193&model=runbot.build.error&menu_id=405 runbot-76193
Quotation template users are now prevented from uploading unsupported file types in the quote builder. This avoids confusing upload failures and system errors when non-PDF files are selected.
Original PR description
Currently, an exception was generated when the user uploaded a non-pdf file in Quate Builder of quotation templates. error: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte` This commit will fix the above issue by preventing uploading non-supported files that were uploaded by users. sentry-5962839786
This fix prevents the point of sale from failing when a product does not have an Indian HSN code set. Cashiers can add such products to orders normally, reducing interruptions during sales.
Original PR description
Before this commit, adding a product without the l10n_in_hsn_code field to an order would cause an error, as the system expected this field to be a string. opw-4254621 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where extra browser launch settings could be lost when fullscreen or kiosk mode was enabled. It helps hardware-connected browser sessions open with the intended options and restores fullscreen behavior in Firefox.
Original PR description
Before this PR, the `Browser` helper class used a `chromium_additional_args` variable to keep track of extra command line arguments. However, it's contents were overwritten by the `fullscreen()` and `enable_kiosk_mode()` functions, causing the additional arguments to be lost. This PR removes the variable and instead constructs the argument list when `open_browser` is called. It also fixes fullscreen mode in Firefox by restoring a keypress call that was removed in v18. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The To-Do form view now expands to use the available screen height, matching the experience users already have with task forms. This also fixes related resizing behavior for rich text fields when records are saved or changed with the pager, making editing more consistent.
Original PR description
Before this commit, the height of the form view does not really take the whole space available in the screen as it is the case in the form view of task. This commit makes sure the height of the form view in To-Do app takes the whole screen height as task form view.
Employees on flexible-hour schedules now get a single work entry when their attendance spans lunch. This prevents inflated or fragmented work records and keeps payroll-related time tracking aligned with actual attendance.
Original PR description
Steps --- * Create a flexible hours working schedule * Create a running contract for some employee that uses this schedule * `work_entry_source = 'attendance'` * Create an attendance overlapping lunch for the employee * (e.g 10:00 -> 20:00) * => 2 work entries are generated. But we want only one (10 - 20). * 10 - 12 * 13 - 20
Restaurant point of sale users can now print a bill for an order that has not yet been sent without triggering an error. The change prevents the system from trying to update an order in the backend before it has been fully created there, avoiding an interruption during service.
Original PR description
Steps to reproduce : -------------------------- - Install the pos_restaurant module. - Open session and add something to order. - Don't order them and try to print the bill. Issue : -------- - There will be a traceback as it was trying to update order at backend. Cause : --------- - The order is still draft and have string_id so we can't update it. Fix : ------ - Only update if order is created at backend and have integer id.
Exported journal reports in PDF format now include appropriate side margins. This prevents content from running to the edge of the page, making printed or shared reports easier to read and more professional.
Original PR description
Before this commit, when we export the journal report as a pdf, the side of the content were extended to the side of the page. This commit adds a css property to set margin to the content of the page. task-4260189
Manufacturing users can now post work-in-progress accounting entries even when a work order has been started but its time tracking has not yet been ended. This avoids a blocking error and helps keep manufacturing accounting actions usable during normal operations.
Original PR description
before this commit, if user tries to open/generate WIP entry for manufacturing without recording the end time in the time tracking inside the work order a traceback is shown to user * create a manufacturing order that generate work order * in the work orders generated, start a work order * now click on POST WIP accounting entry from action * traceback is shown after this commit, no traceback wont be shown in the above scenario
This fix updates checkout test flows so rental orders correctly reach the delivery step before confirmation. It helps ensure the online rental checkout experience is validated reliably and reduces the risk of unnoticed checkout issues.
Original PR description
…checkout _* = website_sale_renting, website_sale_stock_renting Added the 'tourUtils.confirmOrder(),' to fix the tour.
Miscellaneous changes
Forward-Port-Of: odoo/odoo#183427 Forward-Port-Of: odoo/odoo#183367
Original PR description
Forward-Port-Of: odoo/odoo#183427 Forward-Port-Of: odoo/odoo#183367
With this commit, the test test_ui is imported and runs smoothly. task-4143417 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#183386 Forward-Port-Of: odoo/odoo#181761
Original PR description
With this commit, the test test_ui is imported and runs smoothly. task-4143417 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#183386 Forward-Port-Of: odoo/odoo#181761
Before this PR: - The state field on the res_company form is not automatically populated based on the entered GST number - On the res_company and res_partner, even if there is a mismatch between the GST number and state no warning is shown After this PR: - The state field on the res_company form now automatically populates based on the entered GST number - A validation check is implemented for both res_company and res_partner forms. Users will receive a warning if there's a discrepancy be
Original PR description
Before this PR: - The state field on the res_company form is not automatically populated based on the entered GST number - On the res_company and res_partner, even if there is a mismatch between the GST number and state no warning is shown After this PR: - The state field on the res_company form now automatically populates based on the entered GST number - A validation check is implemented for both res_company and res_partner forms. Users will receive a warning if there's a discrepancy between the GST number and the corresponding state. Task ID - 4055948 Forward-Port-Of: odoo/odoo#183585 Forward-Port-Of: odoo/odoo#178910
Issue 1: Previously, the chart was being overlapped by the navigation on smaller screen sizes. This commit fixes the issue by limiting the max-width for navigations and also hiding the button text for smaller screens. Issue 2: Previously, after a certain amount of data, the bar colors defaulted to black as the dataIndex exceeded the colors array. This commit fixes the issue by using the modulo operation on dataIndex with the colors array to repeat the colors, and also added additional color
Original PR description
Issue 1: Previously, the chart was being overlapped by the navigation on smaller screen sizes. This commit fixes the issue by limiting the max-width for navigations and also hiding the button text for smaller screens. Issue 2: Previously, after a certain amount of data, the bar colors defaulted to black as the dataIndex exceeded the colors array. This commit fixes the issue by using the modulo operation on dataIndex with the colors array to repeat the colors, and also added additional colors referenced from reporting. Task-4089537 Forward-Port-Of: odoo/odoo#183315 Forward-Port-Of: odoo/odoo#175704
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, t
Original PR description
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page -…
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, the problem corrects itself on the second refresh. - Could not reproduce on the runbot but could do it locally and on Odoo.SH (in 16.0) and on `odoo.com` free database (18.0). This issue was already discussed more than a year ago (https://github.com/odoo/odoo/pull/110207) but was finally closed without being merged. The problem can now be fully reproduced while previously, it was a bit blurry. 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#182640
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#183664 Forward-Port-Of: odoo/odoo#182859
Original PR description
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#183664 Forward-Port-Of: odoo/odoo#182859
This commit will add an underscore to a dict key to avoid any problem that might arise in the future. no task id Related commit: https://github.com/odoo/odoo/commit/2f2f5f63e8d0ab9729bffa25192a7ef9a2da5fb9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183531
Original PR description
This commit will add an underscore to a dict key to avoid any problem that might arise in the future. no task id Related commit: https://github.com/odoo/odoo/commit/2f2f5f63e8d0ab9729bffa25192a7ef9a2da5fb9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183531
Version: saas-17.4 Issue: When only one delivery method is available, the checkout process skips the delivery page and redirects directly to payment, which confuses users. Fix: Removed the redundant `can_skip_delivery_step` logic. - Updated `shop_checkout` to always go through the delivery step if the order has deliverable products. - Now checking `order_sudo._has_deliverable_products()` to determine if delivery selection is needed. - Orders with non-deliverable products skip the
Original PR description
Version: saas-17.4 Issue: When only one delivery method is available, the checkout process skips the delivery page and redirects directly to payment, which confuses users. Fix: Removed the redundant `can_skip_delivery_step` logic. - Updated `shop_checkout` to always go through the delivery step if the order has deliverable products. - Now checking `order_sudo._has_deliverable_products()` to determine if delivery selection is needed. - Orders with non-deliverable products skip the delivery step and go directly to payment. The delivery page will now be displayed regardless of the number of delivery methods, improving user experience by allowing them to review their delivery details before payment. Forward-Port-Of: odoo/odoo#182269
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the highlighted text > The text highlight options are shown. - Select a text without any option > The highlight options remain displayed. Starting from [1], we allow using text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors
Original PR description
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the…
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the highlighted text > The text highlight options are shown. - Select a text without any option > The highlight options remain displayed. Starting from [1], we allow using text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. Another fix (from [2]) was added later to exceptionally authorize the editor's creation for "invisible" elements in translate mode, with a small adaptation on `_activateSnippet()` to prevent activating invisible snippets when their related sidebar buttons are clicked. This code unintentionally leads to keeping the old editors created for a text snippet when switching to another one in the DOM. To fix this behaviour, we still need to ensure existing editors are destroyed so we only create the ones we need in translate mode. [1]: https://github.com/odoo/odoo/commit/3a149e36f7e6deaf156a7ee35e654aad61cf2e5d [2]: https://github.com/odoo/odoo/commit/67efd1d98072f36caf9c473e97984631eb6bc8a3 task-3975683 Forward-Port-Of: odoo/odoo#182813 Forward-Port-Of: odoo/odoo#168642
Before this commit, the IOT was using an old system to render pages on the IOT box. This commit refactors the homepage to use the new owl system. taskId: 4134163 Forward-Port-Of: odoo/odoo#181716 Forward-Port-Of: odoo/odoo#177895
Original PR description
Before this commit, the IOT was using an old system to render pages on the IOT box. This commit refactors the homepage to use the new owl system. taskId: 4134163 Forward-Port-Of: odoo/odoo#181716 Forward-Port-Of: odoo/odoo#177895
Issue: ====== webp images doesn't appear in outlook Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover block and replace the background image with a .webp one - Add text-image block and replace the image with a .webp one - Test it and open the email with outlook desktop - The images doesn't appear in the email. Solution: ========= We replace the .webp images when converting inline. For image elements: we just create another img
Original PR description
Issue: ====== webp images doesn't appear in outlook Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover block and replace the background image with a .webp one - Add text-image block and replace the image with a .webp one - Test it and open the email with outlook desktop - The images doesn't appear in the email. Solution: ========= We replace the .webp images when converting inline. For image elements: we just create another img element with the png version. For background-image: we create the png image and we replace the url of background-image style with the dataURL of the canvas. opw-3776054 Forward-Port-Of: odoo/odoo#177216
opw-4224602 Forward-Port-Of: odoo/odoo#183559
Original PR description
opw-4224602 Forward-Port-Of: odoo/odoo#183559
When installing Event via the Apps menu, you actually install website_event (and therefore Website). This means that the next action the user has to take is installing a theme. In the case of a demo setup, the cron for the mail scheduler of Event will launch immediately post-install and will run for a rather long time, preventing any other module from installing (because module installations are blocked whilst a cron is running). This means that after installing the Website event in a d
Original PR description
When installing Event via the Apps menu, you actually install website_event (and therefore Website). This means that the next action the user has to take is installing a theme. In the case of a demo setup, the cron for the mail scheduler of Event will launch immediately post-install and will run for a rather long time, preventing any other module from installing (because module installations are blocked whilst a cron is running). This means that after installing the Website event in a demo setup, the user is the prevented from finishing the website setup until the cron is finished. This commit introduces a 'grace period' of 15min until the cron first runs, making it possible to finish the website setup right away. Forward-Port-Of: odoo/odoo#182668 Forward-Port-Of: odoo/odoo#182488
A frequent issue is the GC cron times-out when deleting attachments, due to a lack of index on the Fkey `message_main_attachment_id`, forcing Postgres to do a `Seq.Scan` on potentially really large tables to check if it needs to set the Fkey to `NULL`. Therefor we add the missing index. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183302
Original PR description
A frequent issue is the GC cron times-out when deleting attachments, due to a lack of index on the Fkey `message_main_attachment_id`, forcing Postgres to do a `Seq.Scan` on potentially really large tables to check if it needs to set the Fkey to `NULL`. Therefor we add the missing index. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183302
To avoid confusion, the field previously labeled as 'Purchase Order' has been renamed to 'Purchase Order Warning'. This clarifies that the field relates to triggering purchase warnings, not managing purchase orders themselves. This change only affects the field label, ensuring consistency in user expectations without altering the filter content or behavior. OPW-4141054 Forward-Port-Of: odoo/odoo#180176
Original PR description
To avoid confusion, the field previously labeled as 'Purchase Order' has been renamed to 'Purchase Order Warning'. This clarifies that the field relates to triggering purchase warnings, not managing purchase orders themselves. This change only affects the field label, ensuring consistency in user expectations without altering the filter content or behavior. OPW-4141054 Forward-Port-Of: odoo/odoo#180176
The check is comparing an empty recordset to False, which is not equal. Credits to @JZorko https://github.com/odoo/odoo/pull/171478 task-no Forward-Port-Of: odoo/odoo#183545
Original PR description
The check is comparing an empty recordset to False, which is not equal. Credits to @JZorko https://github.com/odoo/odoo/pull/171478 task-no Forward-Port-Of: odoo/odoo#183545
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
Original PR description
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
On mobile, whwen a domain is selected in the SearchPanel, there is a red dot that indicates there is a domain applied. This red dot is useless because we actually see that the domain is selected. This commit removes it. task-4246980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183507 Forward-Port-Of: odoo/odoo#183136
Original PR description
On mobile, whwen a domain is selected in the SearchPanel, there is a red dot that indicates there is a domain applied. This red dot is useless because we actually see that the domain is selected. This commit removes it. task-4246980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183507 Forward-Port-Of: odoo/odoo#183136
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly added block; 6. set filter to "Recently Viewed Products"; 7. save; 8. change an attribute of the current product; 9. use the added carousel to go back to the previous variant. Issue ----- Nothing happens. Cause ----- Commit 016a72bae9c3 changed the event listener on website_sale
Original PR description
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly…
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly added block; 6. set filter to "Recently Viewed Products"; 7. save; 8. change an attribute of the current product; 9. use the added carousel to go back to the previous variant. Issue ----- Nothing happens. Cause ----- Commit 016a72bae9c3 changed the event listener on website_sale from `hashchange` to `popevent` with a check on the event's `state?.newURL` attribute. Issue is that this will always be `undefined`, as there's no logic in place to push or replace states[^1] when viewing products. Solution -------- Revert the change, and have the listener trigger on `hashchange` events[^2] again. > [!Note] > In the future we could consider moving away from using the URL hash property[^3] for storing product attribute ids to a more conventional practice, as was intended by the commit that made this change. opw-4150284 [^1]: https://developer.mozilla.org/en-US/docs/Web/API/PopStateEvent/state [^2]: https://developer.mozilla.org/en-US/docs/Web/API/Window/hashchange_event [^3]: https://developer.mozilla.org/en-US/docs/Web/API/URL/hash Forward-Port-Of: odoo/odoo#183373 Forward-Port-Of: odoo/odoo#183210
Forward-Port-Of: odoo/odoo#183000
Original PR description
Forward-Port-Of: odoo/odoo#183000
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White' variant to 0. - Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants. **Issue:** - The base_unit_price for product variants was not being displayed when the base_unit_price of one variant wa
Original PR description
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White'…
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White' variant to 0. - Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants. **Issue:** - The base_unit_price for product variants was not being displayed when the base_unit_price of one variant was set to 0. This caused the price to disappear for all variants in the template, even when other variants had valid base_unit_price values. **Cause:** The condition in the template was relying on a falsy check, which incorrectly evaluated 0 as a falsy value and prevented the display of base_unit_price for all variants, including those with valid prices. **Fix:** The condition in the template was updated to check for the existence of base_unit_price explicitly using if condition effectively. This ensures that even when base_unit_price is 0, it will still be displayed, while preventing the field from disappearing for other variants. Affected Version: 17.0~master opw-4061530 Forward-Port-Of: odoo/odoo#183281
we have the same functionality before this commit https://github.com/odoo/odoo/commit/ab0bdf0192120671010634978f202da35ddfc79f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180312
Original PR description
we have the same functionality before this commit https://github.com/odoo/odoo/commit/ab0bdf0192120671010634978f202da35ddfc79f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180312
…eckbox The default value of the Peppol checkbox in the Print & Send wizard depends on the presence/absence of warnings. In [the refactoring of warnings][1], we broke the previous behavior. We decided to show the warnings only when relevant, thus only when the checkbox is selected. Since the computation of the "checked" valued is based on the warnings, there is kind of a bad cyclic dependency. The warnings won't be set, therefore the checkbox will be checked on invoices where it shouldn't.
Original PR description
…eckbox The default value of the Peppol checkbox in the Print & Send wizard depends on the presence/absence of warnings. In [the refactoring of warnings][1], we broke the previous behavior. We decided to show the warnings only when relevant, thus only when the checkbox is selected. Since the computation of the "checked" valued is based on the warnings, there is kind of a bad cyclic dependency. The warnings won't be set, therefore the checkbox will be checked on invoices where it shouldn't. This is particularly problematic for automatic flows. It was a bad design to have a computation that depends on the warnings, both shouldn't be directly linked. [1]: <https://github.com/odoo/odoo/commit/7dbcdd24cd3d8e0b6744847234a983f3361e296a> task-no Forward-Port-Of: odoo/odoo#183534
Before this commit: =================== - The kitchen order ticket was not printing correctly when the kiosk was configured with online payment, the ticket printed with incomplete or incorrect details. After this ticket: ================ - The kitchen order ticket now prints correctly when using kiosk self order. - Ticket layout has been improved, with proper margin and padding adjustments for better readability. Task- 4182015 Forward-Port-Of: odoo/odoo#180143
Original PR description
Before this commit: =================== - The kitchen order ticket was not printing correctly when the kiosk was configured with online payment, the ticket printed with incomplete or incorrect details. After this ticket: ================ - The kitchen order ticket now prints correctly when using kiosk self order. - Ticket layout has been improved, with proper margin and padding adjustments for better readability. Task- 4182015 Forward-Port-Of: odoo/odoo#180143
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10
Original PR description
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 Part 24: https://github.com/odoo/odoo/pull/181971 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183598 Forward-Port-Of: odoo/odoo#183358
PoS receipt should show fiskaly information but they are not shown Steps to reproduce: ------------------- * Setup you db with fiskaly * Start a PoS and sell any product > Observation: The receipt doesn't contain any information opw-4216415 Forward-Port-Of: odoo/enterprise#71779
Original PR description
PoS receipt should show fiskaly information but they are not shown Steps to reproduce: ------------------- * Setup you db with fiskaly * Start a PoS and sell any product > Observation: The receipt doesn't contain any information opw-4216415 Forward-Port-Of: odoo/enterprise#71779
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71802
Original PR description
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71802
Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer > Do it again with same the project and a different task - Stop timer > Time is added to previous timesheet The expected behavior would be to create a new timesheet since the task is different. The reason both timesheets are merged is that we check 'task_id' for redundance while helpdesk 'tasks
Original PR description
Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer >…
Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer > Do it again with same the project and a different task - Stop timer > Time is added to previous timesheet The expected behavior would be to create a new timesheet since the task is different. The reason both timesheets are merged is that we check 'task_id' for redundance while helpdesk 'tasks' are instead recorded in the 'helpdesk_ticket_id'. Since it is forbidden for a timesheet to have both a 'task_id' and 'helpdesk_ticket_id', it is guaranteed that task_id will be False for both of our entries, leading to a merge. Similarily we can use that property since adding helpdesk_ticket_id to the domain won't change the usual behavior (the field will always be False if the project is not from Helpdesk) to add an extra condition here. Source: we have a contraint '_check_no_link_task_and_ticket' which ensures that. opw-4203678 Forward-Port-Of: odoo/enterprise#71784
Steps to reproduce: - Any project > Gantt view > Add any groupby filter The weekends are no longer greyed out like they were without the filter. This happens because _gantt_unavailablities in this module defers calls to the super() method which is empty unless the field is user_id. This makes sense since we don't want to get unavailability by employee if the tasks are not sorted by user, we could however use company leaves instead of leaving every day as available under other filters. opw
Original PR description
Steps to reproduce: - Any project > Gantt view > Add any groupby filter The weekends are no longer greyed out like they were without the filter. This happens because _gantt_unavailablities in this module defers calls to the super() method which is empty unless the field is user_id. This makes sense since we don't want to get unavailability by employee if the tasks are not sorted by user, we could however use company leaves instead of leaving every day as available under other filters. opw-4237953 Forward-Port-Of: odoo/enterprise#71841
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object to the strptime function of datetime which in reality it needs to receive a string object instead. This raises a TypeError Since the objective is to set a string date, we convert the date_order into a string date using strftime function from datetime mod
Original PR description
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda…
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object to the strptime function of datetime which in reality it needs to receive a string object instead. This raises a TypeError Since the objective is to set a string date, we convert the date_order into a string date using strftime function from datetime module - Install 'Sales' application and 'l10n_mx_edi' module - In a company with mexican localization selected go to Sales > Quotations and create a new Order - Select a contact with the Addenda Autozone selected - Confirm it and create the corresponding invoice - Confirm the invoice and generate the CFDI 2. Traceback with invoice that have multiple sale order linked. In attribute t-att-PODATE for the Autozone Addenda is not expecting a recordset when initializing the value of sale_id, this causes a ValueError: expected singleton error when retrieving value of date_order when we create a invoice for multiple sale orders Initialize sale_id with the first order retrieved to use it task-no Forward-Port-Of: odoo/enterprise#71939 Forward-Port-Of: odoo/enterprise#71875
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Forward-Port-Of: odoo/enterprise#71953 Forward-Port-Of: odoo/enterprise#71421
Original PR description
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Forward-Port-Of: odoo/enterprise#71953 Forward-Port-Of: odoo/enterprise#71421
…sales Steps to reproduce:: [l10n_fr] - create a customer, BE Company; delivery adress USA - create an invoice for the customer - Go to EC Sales Report Issue: The transaction is displayed Solution: When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries opw-4131299 Forward-Port-Of: odoo/enterprise#69960
Original PR description
…sales Steps to reproduce:: [l10n_fr] - create a customer, BE Company; delivery adress USA - create an invoice for the customer - Go to EC Sales Report Issue: The transaction is displayed Solution: When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries opw-4131299 Forward-Port-Of: odoo/enterprise#69960
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an a
Original PR description
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an accounting report as XLSX file, we add a column for the account codes on the very left of the sheet. This looks a bit weird and is not the most important information to have as a first column. In this commit, we move the column to the right so the name of the line will be first, followed by the account code (if applicable). We also add a column name for the account codes. task-3986483 Forward-Port-Of: odoo/enterprise#71866 Forward-Port-Of: odoo/enterprise#67111
Before this commit the following error was observed: File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 112, in test_subscription_invoice_automate self.assertInvoicePaid(self.invoice) File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 66, in assertInvoicePaid self.assertEqual(invoice.amount_paid, invoice.amount_total, "Amount should match") AssertionError: 1206.3700000
Original PR description
Before this commit the following error was observed:
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 112, in test_subscription_invoice_automate
self.assertInvoicePaid(self.invoice)
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 66, in assertInvoicePaid
self.assertEqual(invoice.amount_paid, invoice.amount_total, "Amount should match")
AssertionError: 1206.3700000000001 != 1206.37 : Amount should match
Runbot errors: 100947, 100946, 100945, 100944, 100944
Forward-Port-Of: odoo/enterprise#71843…ountant *: account_reports, account_online_synchronization Configuration steps on empty Bank, Misc journals should not be shown for users that do not have the Administrator/Accountant rights. They don't have the necessary rights to execute those actions anyway. This commit hide the configuration steps for non-accountant users. task-4149584 Forward-Port-Of: odoo/enterprise#71210
Original PR description
…ountant *: account_reports, account_online_synchronization Configuration steps on empty Bank, Misc journals should not be shown for users that do not have the Administrator/Accountant rights. They don't have the necessary rights to execute those actions anyway. This commit hide the configuration steps for non-accountant users. task-4149584 Forward-Port-Of: odoo/enterprise#71210
https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 changed how the chatter is added to a view and updated the codebase except for this module. This commit fixes this. Forward-Port-Of: odoo/enterprise#71878
Original PR description
https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 changed how the chatter is added to a view and updated the codebase except for this module. This commit fixes this. Forward-Port-Of: odoo/enterprise#71878
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Description of the issue/feature this PR addresses: When a new account is added and the chart is loaded for the child company before the parent, the account will be created for both companies Current behavior before PR: Desired behavior after PR is merged: see also https://github.com/odoo/enterprise/pull/71421
Original PR description
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Description of the issue/feature this PR addresses: When a new account is added and the chart is loaded for the child company before the parent, the account will be created for both companies Current behavior before PR: Desired behavior after PR is merged: see also https://github.com/odoo/enterprise/pull/71421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182706