Thursday, January 16, 2025
62 changes · saas-18.1
Enhancements to existing features
The IoT hardware drivers now use a shared check to confirm the linked server address is available before related actions run. This makes device communication more consistent and reduces connection-related failures caused by missing setup information.
Original PR description
Lots of methods need to know the associated database url. It is sometimes checked in the caller method, and sometimes inside of the called method itself. We now use a decorator that checks it for us. Task: 4391509
Users now see a clearer notification when they leave a live chat conversation. This reduces confusion for support agents and visitors by making the action and its result easier to understand.
Original PR description
This commit changes the toast notification message when leaving a livechat conversation. task-4481370
The user form phone field has been visually aligned to better match the surrounding layout. This small interface polish improves readability and creates a cleaner, more consistent experience when viewing or editing user details.
Original PR description
Aligned the phone field to ensure it properly matches the overall layout and maintains visual consistency across the form. This adjustment improves the user interface by correcting misalignment issues, enhancing readability, and providing a cleaner design. Task-4427199
Resolved issues and error corrections
Project settings now display analytic plan labels and their selection fields in the expected order. This makes the form easier to read and use without changing how it behaves on mobile devices.
Original PR description
This commit's purpose is to fix the alignment of the plans and the selection fields associated to those plan in the setting of the form view of projects. The issue was caused by the extra 'div' inside the group, which was disrupting the usual display order of 'field name' - 'field selection' Solution: remove that extra div and adds a css class to handle margin issue with the group section. Adding a 'colspan' was a cleaner solution, but it also update the display of fields in mobile view, and we don't want that. task - 4397694
Miscellaneous changes
Before this commit: Nothing would happen after a mercado pago webhook notification received. Since 17.4, `payment_method` attribute have been changed to `payment_method_id`. Thus it was returning `undefined` and silently fail to update the line After this commit: Call `handleMercadoPagoWebhook` on notification received as intended opw-4349957 Forward-Port-Of: odoo/odoo#193784
Original PR description
Before this commit: Nothing would happen after a mercado pago webhook notification received. Since 17.4, `payment_method` attribute have been changed to `payment_method_id`. Thus it was returning `undefined` and silently fail to update the line After this commit: Call `handleMercadoPagoWebhook` on notification received as intended opw-4349957 Forward-Port-Of: odoo/odoo#193784
This fixes internal messaging test setup so it no longer assumes WhatsApp-related components are installed. It helps keep automated validation reliable across different Odoo editions, reducing false failures without changing customer-facing behavior.
Original PR description
Removes the implicit dependency on whatsapp. We instead override the method in `test_discuss_full_enterprise` such that the tests passes both with community only and community + enterprise. Runbot Error: - 109621 - 109622 - 111962 - 111963 - 111964 - 111965 Related to: https://github.com/odoo/enterprise/pull/77157
This fix ensures that if creating a database index fails, the system safely recovers before continuing. It helps avoid follow-on errors during internal setup or upgrades, improving reliability without changing user-facing features.
Original PR description
When there is a failure when adding an index, the ORM supposes a rollback is done in `add_index`, so the next SQL statement will fail because the current transaction is aborted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how point of sale receipts build their customer-facing portal link. The link now uses the order session’s base website address, helping prevent incorrect receipt URLs for customers.
Original PR description
access the url through `order.session._base_url` rather than the `props`
The archived status banner on employee profiles now appears in front of the employee photo instead of being hidden behind it. This makes archived records clearly visible to HR users and avoids confusion when viewing employee profiles.
Original PR description
if an employee get archived the banner will appear behind the employee picture Issue: the `--Ribbon-z-index: 1` var is removed from web/static because it overlap with something else - move the widget after the div to have a higher z-index Task: 4452394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The menu loading performance test was adjusted to reflect an expected extra lookup for users with read-only accounting access. This keeps automated checks aligned with the current behavior and helps avoid false build failures.
Original PR description
When user has 'account.group_account_readonly' group, _visible_menu_ids function calls for _xmlid_to_res_id to find hidden_menu_ids. This increases the querycount of the function. We are updating test_visible_menu_ids in accordance to this change. [link to broken builds](https://runbot.odoo.com/odoo/runbot.build.error/109492) Speedscope image when user has 'account.group_account_readonly' group  Speedscope image when user does not have 'account.group_account_readonly' group 
This fix prevents editor buttons from visually overlapping the form status bar when users scroll through long HTML fields. It keeps the page controls easier to read and avoids a confusing display issue in forms.
Original PR description
Description of the issue this PR addresses: Steps to reproduce: 1. Open the To-Do/Project app 2. Focus on HTML field and add some empty lines to make it scrollable. 3. Scroll the view and observe that the power buttons scroll above the status bar. Current behavior before PR: A recent commit [1] made the form view statusbar sticky with a z-index of 1, which conflicts with the editor's local overlay. Desired behavior after PR is merged: The z-index of the statusbar is increased to 2, ensuring the editor's local overlay scrolls beneath the statusbar. [1]: https://github.com/odoo/odoo/commit/a3c63413825cf3492a10ade77a2c571c4eeb33a6 task: 4457597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how point of sale receipt links are built by using the sales session's base URL instead of screen properties. It helps ensure customers receive or access the correct online receipt link from point of sale orders.
Original PR description
access the url through `order.session._base_url` rather than the `props`
This update fixes a test issue caused by a user lacking access to CRM lead information. It helps keep automated checks reliable for the Appointment CRM area without changing customer-facing behavior.
Original PR description
Fixing permission access error in the test (user does not have access to crm.lead). task-4380712 odoo/odoo#191351
This change fixes an internal test setup issue by removing an unintended dependency on WhatsApp-related functionality. It helps ensure automated checks pass consistently across different Odoo installation configurations, reducing false failures during release validation.
Original PR description
Removes the implicit dependency on whatsapp. We instead override the method in `test_discuss_full_enterprise` such that the tests passes both with community only and community + enterprise. Runbot Error: - 109621 - 109622 - 111962 - 111963 - 111964 - 111965 Related to: https://github.com/odoo/odoo/pull/193709
This update adjusts automated tests for spreadsheet features in Documents to match a corrected focus behavior. It helps keep quality checks reliable after the underlying spreadsheet interaction fix, with no expected change for everyday users.
Original PR description
The hoot dom helpers rely on a single 'pointerdown' to focus its node which is precisely the behaviour that we act upon in https://github.com/odoo/o-spreadsheet/commit/85aaab61dd3fc4ea2a8c10f9e70b8e7fa650f170
Fixed an issue where opening an analytic budget line from the Budget Report could trigger an error. The report now supports the identifier format used internally, so users can access budget details normally.
Original PR description
Steps to reproduce: 1. Install account_budget 2. Create a new analytic budget 3. Open the Budget Report in list view 4. Click on the analytic budget line 5. A traceback is raised --- Description of the issue this commit addresses: Budget report queries were made with a concatenation system on the id in order, when using "UNION ALL" to make a difference between the lines coming from one table with the same id as lines coming from another table. This causes error because the id is casted to int and contains non int characters. --- Desired behavior after this commit is merged: No traceback is raised. ids with non int characters are accepted. --- Note on the fix: A workaround is applied on the _condition_to_sql method to allow non digit characters in the id column. --- opw-4446007
Versions -------- - 16.0+ Steps ----- 1. Have a payment provider like Demo published; 2. create a discount program that expired yesterday; 3. change time of PC to yesterday; 4. go to eCommerce, add product to cart, go to checkout; 5. follow steps until you get to the "Pay Now" button; 6. change time of PC to today; 7. finalize payment. Issue ----- The payment transaction proceeds, but doesn't cover the entire amount, as the promotion was removed afterwards. Cause ----- Whe
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a payment provider like Demo published; 2. create a discount program that expired yesterday; 3. change time of PC to yesterday; 4. go to eCommerce, add product to cart, go to checkout; 5. follow steps until you get to the "Pay Now" button; 6. change time of PC to today; 7. finalize payment. Issue ----- The payment transaction proceeds, but doesn't cover the entire amount, as the promotion was removed afterwards. Cause ----- When initiating payment, there's check on whether the applied rewards are still valid. Solution -------- Add an override for `_validate_transaction_for_order`, which compares the order amount before and after updating programs & rewards. If they don't match, raise a `ValidationError`, forcing the user reload the order without expired programs & rewards. opw-4304241 Forward-Port-Of: odoo/odoo#193603 Forward-Port-Of: odoo/odoo#191256
This PR addresses the issue of users without Sales access not being able to record on time on timesheets that are linked to a sale order line. If a user with access to Projects and Timesheets, but not Sales, wants to record time on a timesheet linked to a sales order, they will get an access rights error. This is because we check to see if there is an analytic distribution associated with the sale order line associated with the project task. However, this check is done without `sudo()` access
Original PR description
This PR addresses the issue of users without Sales access not being able to record on time on timesheets that are linked to a sale order line. If a user with access to Projects and Timesheets, but…
This PR addresses the issue of users without Sales access not being able to record on time on timesheets that are linked to a sale order line. If a user with access to Projects and Timesheets, but not Sales, wants to record time on a timesheet linked to a sales order, they will get an access rights error. This is because we check to see if there is an analytic distribution associated with the sale order line associated with the project task. However, this check is done without `sudo()` access in its current state. This PR provides that access because the result is not propagated further than simply evaluating whether or not there is an analytic distribution at all. The result is that this workflow is no longer blocking for users who should be able to timesheet, but not necessarily view or edit the sale order. This can be tested on Runbot by following these steps: Configuration: - User A does not have any Sales access, but has full rights to Projects and Timesheets - Have a service product that creates a task in a project - Have a sale order made for this product by User B, who does have Sales access Now, 1) On User A, navigate to the associated project and task made by the sale order from earlier 2) Click on the Timesheets tab in the notebook part of the view 3) Attempt to record an hour of work by adding a line to the timesheet, then clicking the "save" button Prior to this PR, the user will get an access rights error. Once this is merged, that error will no longer appear. opw-4409571 Forward-Port-Of: odoo/odoo#193311
Since [1], the session getter for the sidebar cards assumes that channelMember is always defined on rtcSessions, this could cause tracebacks. [1]: https://github.com/odoo/odoo/pull/190050 Forward-Port-Of: odoo/odoo#193893
Original PR description
Since [1], the session getter for the sidebar cards assumes that channelMember is always defined on rtcSessions, this could cause tracebacks. [1]: https://github.com/odoo/odoo/pull/190050 Forward-Port-Of: odoo/odoo#193893
Steps to reproduce: - Install the e-commerce module. - Go to the homepage. - Enter edit mode. - Drag and drop a "Products" block onto the page. - Click on the "See all" link. - Edit the link (e.g., change "/shop" to "/contactus"). - Save the page. - Click on the "See all" link. - Bug: You are redirected to the "/shop" page instead of the "/contactus" page as expected. The bug occurs since commit [1], where the "See all" link was added to "Dynamic" snippets. Each time a "Dynamic"
Original PR description
Steps to reproduce: - Install the e-commerce module. - Go to the homepage. - Enter edit mode. - Drag and drop a "Products" block onto the page. - Click on the "See all" link. - Edit the link (e.g.,…
Steps to reproduce: - Install the e-commerce module. - Go to the homepage. - Enter edit mode. - Drag and drop a "Products" block onto the page. - Click on the "See all" link. - Edit the link (e.g., change "/shop" to "/contactus"). - Save the page. - Click on the "See all" link. - Bug: You are redirected to the "/shop" page instead of the "/contactus" page as expected. The bug occurs since commit [1], where the "See all" link was added to "Dynamic" snippets. Each time a "Dynamic" snippet is rendered during a page load, the href of the "See all" link is reset to the main module page. While this behavior is useful when the snippet is first rendered after being dropped onto the page, it is problematic afterward. Once the user has edited the link with a different href, it should not be reset on every page load. [1]: https://github.com/odoo/odoo/commit/bbcff746075485be61807d08ad8232dbad347713 [opw-4418048](https://www.odoo.com/web#id=4418048&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#191689
**Steps to reproduce:** In Inventory > Settings > Traceability, enable Lots & Serial Numbers - Create a product P1 tracked by unique serial number - Update on-hand quantities: 2 x P1 - Create a quotation with 2 units of P1 - Deliver products (assign the two serial numbers) - Return only 1 product - Go to the Customer view, click Lot/Serial Numbers, and remove all filters. **Issue:** When returning just one product from a delivery containing multiple products, all products in the picki
Original PR description
**Steps to reproduce:** In Inventory > Settings > Traceability, enable Lots & Serial Numbers - Create a product P1 tracked by unique serial number - Update on-hand quantities: 2 x P1 - Create a quotation with 2 units of P1 - Deliver products (assign the two serial numbers) - Return only 1 product - Go to the Customer view, click Lot/Serial Numbers, and remove all filters. **Issue:** When returning just one product from a delivery containing multiple products, all products in the picking appear as returned. **Expected:** Only the product that was actually returned should be marked as returned. **Cause:** The logic that sets `has_return` relies solely on the `return_id` field, incorrectly marking all items in the picking as returned if one item is returned. opw-4417716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192641
**Current behavior:** The global lead days system parameter may be counted in the lead days breakdown in the replenishment report when: A) product has manufacture route and, B) WH manufacture steps is not 1-step **Expected behavior:** The parameter is counted once. **Steps to reproduce:** 1. Create a product with a simple BoM and the manufacture route 2. Enable 2 or 3 step manufacturing in WH 3. Create an out move for the product 4. Open the replenishment report in inventory
Original PR description
**Current behavior:** The global lead days system parameter may be counted in the lead days breakdown in the replenishment report when: A) product has manufacture route and, B) WH manufacture steps…
**Current behavior:** The global lead days system parameter may be counted in the lead days breakdown in the replenishment report when: A) product has manufacture route and, B) WH manufacture steps is not 1-step **Expected behavior:** The parameter is counted once. **Steps to reproduce:** 1. Create a product with a simple BoM and the manufacture route 2. Enable 2 or 3 step manufacturing in WH 3. Create an out move for the product 4. Open the replenishment report in inventory 5. Click the (i) in the orderpoint line for the product -> see the global vis. days are counted 2x **Cause of the issue:** Like the issue solved by 38d8e77 In some instances the `_get_lead_days()` must be called a second time to capture some additional lead time (in this case because we have > 1-step manufacturing). **Fix:** Use the context added in the referenced similar commit to ignore the global days in the second call. opw-4410790 Forward-Port-Of: odoo/odoo#193154 Forward-Port-Of: odoo/odoo#190808
- edit the codition to check if the active model is HR to use the smae plan summary as the buttom rfom the employee from Task: 4237311 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#189480
Original PR description
- edit the codition to check if the active model is HR to use the smae plan summary as the buttom rfom the employee from Task: 4237311 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#189480
Use fully qualified names as columns in related table can have a same name and this query could raise an error. Like the one below error below was shown in 18.0 ``` psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 3: AND state = 'validate' ``` Note: error occured in 18.0 will be fixed in forward port, using fully qualified names was the purpose so made sense to start from 16.0 and fix for all versions after Description of the issue/
Original PR description
Use fully qualified names as columns in related table can have a same name and this query could raise an error. Like the one below error below was shown in 18.0 ``` psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 3: AND state = 'validate' ``` Note: error occured in 18.0 will be fixed in forward port, using fully qualified names was the purpose so made sense to start from 16.0 and fix for all versions after 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#193672 Forward-Port-Of: odoo/odoo#193568
Commit c63d14a0485a553b74a8457aee158384e9ae6d3f introduced new nicer urls to get to Odoo. Commit 5776b574b3aba190c54b2e4974ce514d9b0bec2a adapted the /mail/view controller for it, allowing people clicking on a link to a record in a mail to be redirected to a nice new URL. Although one case was missing: when the model doesn't contain dots, the string is considered an action's path. So, when opening a record from a mail, there was a crash in odoo because the action could not be found. After
Original PR description
Commit c63d14a0485a553b74a8457aee158384e9ae6d3f introduced new nicer urls to get to Odoo. Commit 5776b574b3aba190c54b2e4974ce514d9b0bec2a adapted the /mail/view controller for it, allowing people clicking on a link to a record in a mail to be redirected to a nice new URL. Although one case was missing: when the model doesn't contain dots, the string is considered an action's path. So, when opening a record from a mail, there was a crash in odoo because the action could not be found. After this commit, there is no crash, and the record is opened correctly with a nice url. see router.js: heuristics to discrimate a model name from an action path is the presence of dots, or the prefix m- for models opw-4475237 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#193762
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g. Contact); 2. set trigger to On Creation; 3. in data to write, have evaluation type to Value; 4. fill in the value (e.g. 1); 5. create a record that would trigger the automation. Issue ----- > ValueError: Wrong value for res.partner.category_id: 1 Cause ----- In the `eval_value`
Original PR description
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g.…
Versions -------- - 16.0 (fix issue) - 17.0+ (skip useless constraint) Commit 3871ae2c6c45 enabled automated m2m CRUD in 17.0+ Steps ----- 1. Create an automated action on a Model with tags (e.g. Contact); 2. set trigger to On Creation; 3. in data to write, have evaluation type to Value; 4. fill in the value (e.g. 1); 5. create a record that would trigger the automation. Issue ----- > ValueError: Wrong value for res.partner.category_id: 1 Cause ----- In the `eval_value` method, the `many2many` type doesn't get covered. Solution -------- 1. Have `eval_value` handle `many2many` values (linking them to relevant record, and existing as a single expression per column). 2. Undo 09a6df204f2a which disallowed writing by reference for many2many fields. This change makes writing by reference possible as well, and allows you to select the desired record, instead of having to manually fill in its ID. opw-4054461 Forward-Port-Of: odoo/odoo#193610 Forward-Port-Of: odoo/odoo#190047
Versions -------- - 18.0+ Steps ----- 1. Go to eCommerce; 2. add only services to cart; 3. go to checkout; 4. on payment page, go back to Delivery page; 5. add a second address if needed; 6. change selected address. Issue ----- > Uncaught Promise > Cannot read properties of null Cause ----- The query selector in `_canEnabledMainButton` assumes a radio input is always present on this step, but this is only the case when deliverable products were added to the cart. Solutio
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Go to eCommerce; 2. add only services to cart; 3. go to checkout; 4. on payment page, go back to Delivery page; 5. add a second address if needed; 6. change selected address. Issue ----- > Uncaught Promise > Cannot read properties of null Cause ----- The query selector in `_canEnabledMainButton` assumes a radio input is always present on this step, but this is only the case when deliverable products were added to the cart. Solution -------- Skip the remainder of the method if the delivery radio wasn't found. opw-4365246 opw-4422905 Forward-Port-Of: odoo/odoo#193357
- Added a new ScreenSaver component that displays the brand image. - The screensaver disappears when clicked. - Automatically activates and becomes visible after 5 minutes of user inactivity. task- 4374221 Forward-Port-Of: odoo/odoo#191392
Original PR description
- Added a new ScreenSaver component that displays the brand image. - The screensaver disappears when clicked. - Automatically activates and becomes visible after 5 minutes of user inactivity. task- 4374221 Forward-Port-Of: odoo/odoo#191392
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen sizes. Newer versions of Chrome sometimes introduce slight variation between the Chrome's window size and its viewport size (due to changes in the interface layout...). While often not a deal-breaker, Chrome 128 forces a min-width for the window greater than the breakpoint we use for smaller/
Original PR description
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen…
To run tours or unit tests, we instrument Chrome and run it headlessly. One of the arguments passed while doing so is the "window size" it needs to use to emulate desktop-like or mobile-like screen sizes. Newer versions of Chrome sometimes introduce slight variation between the Chrome's window size and its viewport size (due to changes in the interface layout...). While often not a deal-breaker, Chrome 128 forces a min-width for the window greater than the breakpoint we use for smaller/mobile-like testing (e.g. 375px, which matches a small smartphone). This commit changes the way we instrument Chrome to use a specific size by using the DevTools' Emulated Device (aka. "responsive mode"). It allows to apply a very specific viewport's size independently of the actual Chrome's window size, which makes it way more predictable than before. Note: this change is part of the preparation to support the "new" headless mode, which becomes the default starting with Chrome 128. Reference: - https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setDeviceMetricsOverride Forward-Port-Of: odoo/odoo#193847 Forward-Port-Of: odoo/odoo#193696
### Before -When the eFactura status was fetched and there was an invoice content error it was not displayed. This issue was due to both the overlooking of: - the 'nok' status (sent back by the Romanian authorities regarding the presence of errors in the invoice content) - the file provided in the zip that would contain the errors -The error message shown would also only contain the first error even if many were present. ### Now -If the status fetched contains 'nok' and is theref
Original PR description
### Before -When the eFactura status was fetched and there was an invoice content error it was not displayed. This issue was due to both the overlooking of: - the 'nok' status (sent back by the Romanian authorities regarding the presence of errors in the invoice content) - the file provided in the zip that would contain the errors -The error message shown would also only contain the first error even if many were present. ### Now -If the status fetched contains 'nok' and is therefore signaling the presence of invoice content errors, then the apposite error file is chosen instead of the file with the electronic signature. This allows for following logic to account for errors, to retrieve the error message and to provide the error file as the downloadable document. -The pop up shows all the errors with an increased width to account for more content. task-4306506 Forward-Port-Of: odoo/odoo#193668 Forward-Port-Of: odoo/odoo#190618
Devices detected through usb don't always have there manufactured and product name which can be retrieved. For example, our foot pedal in the office doesn't which leads to it having a name `"None - None"` in Odoo. After this PR if a device doesn't have a product name / manufacturer name it will be saved as `"Unknown input device"` task-4472585 Forward-Port-Of: odoo/odoo#193295 Forward-Port-Of: odoo/odoo#193277
Original PR description
Devices detected through usb don't always have there manufactured and product name which can be retrieved. For example, our foot pedal in the office doesn't which leads to it having a name `"None - None"` in Odoo. After this PR if a device doesn't have a product name / manufacturer name it will be saved as `"Unknown input device"` task-4472585 Forward-Port-Of: odoo/odoo#193295 Forward-Port-Of: odoo/odoo#193277
Filipino is a standardized version of Tagalog that was created to be the national language of the Philippines. In Odoo, we use the "tl" locale to refer to Filipino, but this locale is considered "legacy" by standards bodies such as the Unicode Consortium. This is the reason why some APIs, such as the Intl API in the browser, treat "tl" as "fil" and even implicitly replace the former with the latter. This is a problem in Odoo, since the locale we use on the server side is still tl_PH, which
Original PR description
Filipino is a standardized version of Tagalog that was created to be the national language of the Philippines. In Odoo, we use the "tl" locale to refer to Filipino, but this locale is considered "legacy" by standards bodies such as the Unicode Consortium. This is the reason why some APIs, such as the Intl API in the browser, treat "tl" as "fil" and even implicitly replace the former with the latter. This is a problem in Odoo, since the locale we use on the server side is still tl_PH, which leads to crashes when a converted Filipino locale (fil_PH) is sent to the server. While waiting for a better solution, this commit forces the tl locale on the client side. opw-4426799 Forward-Port-Of: odoo/odoo#192532
We can only attempt to get fields from `res.company` model. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193760
Original PR description
We can only attempt to get fields from `res.company` model. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193760
Since commit 567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb It used to insert a placeholder when the data is not there but we won't on real report 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#193531
Original PR description
Since commit 567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb It used to insert a placeholder when the data is not there but we won't on real report 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#193531
Steps to reproduce: - Go to a form view with a one2many with a handle widget - Move a line in the one2many that make Odoo crash with the onchange To generate a faulty view, create a form view with a one2many and add an automation "On UI change" to make the resequence crash. Current behaviour ----------------- After the error being thrown, the user will not be able to resequence this line again. Expected Behaviour ------------------ After the error, the user will still be able to r
Original PR description
Steps to reproduce: - Go to a form view with a one2many with a handle widget - Move a line in the one2many that make Odoo crash with the onchange To generate a faulty view, create a form view with a one2many and add an automation "On UI change" to make the resequence crash. Current behaviour ----------------- After the error being thrown, the user will not be able to resequence this line again. Expected Behaviour ------------------ After the error, the user will still be able to resequence this line Forward-Port-Of: odoo/odoo#193781 Forward-Port-Of: odoo/odoo#157539
__Current behavior before commit:__ Since [`9592bd1`][1] when the livechat is integrated on a third-party website, a visitor can not answer the call of an operator. This is because the script `selfie_segmentation.js` is being fetched from the third-party website domain instead of the Odoo database domain; resulting in the following error: `AssetsLoadingError: The loading of /mail/static/lib/selfie_segmentation/selfie_segmentation.js failed` __Description of the fix:__ Use of the `url` fun
Original PR description
__Current behavior before commit:__ Since [`9592bd1`][1] when the livechat is integrated on a third-party website, a visitor can not answer the call of an operator. This is because the script `selfie_segmentation.js` is being fetched from the third-party website domain instead of the Odoo database domain; resulting in the following error: `AssetsLoadingError: The loading of /mail/static/lib/selfie_segmentation/selfie_segmentation.js failed` __Description of the fix:__ Use of the `url` function to prepend the correct domain name. opw-4417974 [1]: https://github.com/odoo/odoo/commit/9592bd1 Forward-Port-Of: odoo/odoo#193798
### To reproduce: - Model A has an inverse X2many stored field pointing to model B. - Calling `A.create({'X2many': [Command.create({...})]})` returns `A(1)`. - `A(1).X2many` returns `B(1, <NewId NoOrigin>)`. This breaks one of the implicit invariants of the ORM, we shouldn't have a mix of real and New ids in the same recordset. Also, it may break some computation done on this X2many later in the same request, since `A(1).X2many` contains two records instead of one. This happens because `cr
Original PR description
### To reproduce: - Model A has an inverse X2many stored field pointing to model B. - Calling `A.create({'X2many': [Command.create({...})]})` returns `A(1)`. - `A(1).X2many` returns `B(1, <NewId…
### To reproduce:
- Model A has an inverse X2many stored field pointing to model B.
- Calling `A.create({'X2many': [Command.create({...})]})` returns `A(1)`.
- `A(1).X2many` returns `B(1, <NewId NoOrigin>)`. This breaks one of the implicit invariants of the ORM, we shouldn't have a mix of real and New ids in the same recordset. Also, it may break some computation done on this X2many later in the same request, since `A(1).X2many` contains two records instead of one.
This happens because `create()` calls `_update_cache()` with X2many values, but the value of that X2many is already in the cache with the record created from the command values. This causes the X2many values to be duplicated with the new record version of the command values.
### Real Issue in the standard code
In the case of the 'sale.commission.plan' model and due to the inversed `target_commission_ids` field, it breaks the duplicate feature (`copy()` method):
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/http.py", line 1960, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/service/model.py", line 138, in retrying
result = func()
^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/http.py", line 1927, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/http.py", line 2174, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/http.py", line 729, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5921, in copy
old_record.copy_translations(new_record, excluded=default or ())
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5874, in copy_translations
new_lines = new[name].sorted(key='id')
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6690, in sorted
ids = tuple(item.id for item in sorted(self, key=key, reverse=reverse))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'NewId' and 'int'
```
Explanation of the traceback:
A `copy()` calls `create()` on 'sale.commission.plan', which returns a `commission` record that should contain the same `target_commission_ids` values. Instead of that, `commission.target_commission_ids` (after the create and before `copy_translations`) returns twice as many records and with a mix of New and real ids, causing `copy_translations()` to crash when sorting by id.
### Fix
To avoid this issue, we don't call `_update_cache()` for the stored fields because we are sure that the cache has already been set in `_create()` and not invalidated by `modified()`.
Forward-Port-Of: odoo/odoo#193256- edit the `_read_group` domain to include the current active companies Task: 4353391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190322
Original PR description
- edit the `_read_group` domain to include the current active companies Task: 4353391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190322
Since [1], clicking the button while the SEO toaster was visible could repeatedly open the SEO optimization dialog, resulting in multiple instances of the dialog box being opened. This commit addresses this issue by: - Adding logic to ensure toasters close properly when a button is clicked. (i.e the SEO toaster when you publish a page with missing important SEO informations). [1]: https://github.com/odoo/odoo/commit/45ea6e4a4a5c8e314b110a45198fbe3d57bb996e task-4384773 Forwa
Original PR description
Since [1], clicking the button while the SEO toaster was visible could repeatedly open the SEO optimization dialog, resulting in multiple instances of the dialog box being opened. This commit addresses this issue by: - Adding logic to ensure toasters close properly when a button is clicked. (i.e the SEO toaster when you publish a page with missing important SEO informations). [1]: https://github.com/odoo/odoo/commit/45ea6e4a4a5c8e314b110a45198fbe3d57bb996e task-4384773 Forward-Port-Of: odoo/odoo#189788
Before this commit: It is not able to drag and drop text between fields in the form view. After this commit: It is possible to drag and drop text between fields in the form view. Task-4286285 Forward-Port-Of: odoo/odoo#189397
Original PR description
Before this commit: It is not able to drag and drop text between fields in the form view. After this commit: It is possible to drag and drop text between fields in the form view. Task-4286285 Forward-Port-Of: odoo/odoo#189397
Description of the issue/feature this PR addresses: This PR addresses the issue where the currency column repeats in view_move_line_payment_tree view when there are multiple active currencies. This can lead to confusion and clutter in the user interface. Current behavior before PR: Before this PR, when multiple active currencies are set up, the currency column is duplicated in view_move_line_payment_tree view, displaying the same information multiple times. Desired behavior after PR is m
Original PR description
Description of the issue/feature this PR addresses: This PR addresses the issue where the currency column repeats in view_move_line_payment_tree view when there are multiple active currencies. This can lead to confusion and clutter in the user interface. Current behavior before PR: Before this PR, when multiple active currencies are set up, the currency column is duplicated in view_move_line_payment_tree view, displaying the same information multiple times. Desired behavior after PR is merged: After merging this PR, the currency column will appear only once when the optional hide setting is enabled, even with multiple active currencies, resulting in a cleaner and more readable report. [Video](https://drive.google.com/file/d/1bL8L88y81HomX6Q9MkErmOGVDWHdE4_r/view) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193189 Forward-Port-Of: odoo/odoo#192784
After merging of this PR [1], video tab will not be visible in media dialog in report as `allowCommandVideo` is false. But this will override `noVideos` option from `params` to false if `allowCommandVideo` is true and video tab will be visible even if `noVideos` is `true`. This PR makes sure that `noVideos` property from `params` should be checked if `allowCommandVideo` is true. [1]: 187251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Fo
Original PR description
After merging of this PR [1], video tab will not be visible in media dialog in report as `allowCommandVideo` is false. But this will override `noVideos` option from `params` to false if `allowCommandVideo` is true and video tab will be visible even if `noVideos` is `true`. This PR makes sure that `noVideos` property from `params` should be checked if `allowCommandVideo` is true. [1]: 187251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192838
Steps to reproduce: 1) Go to website settings and disable 'Shipping address' 2) Add to cart deliverable product and go to checkout 3) See the broken UI This PR adapts UI to the setting of disabling delivery address. opw-4367079 Forward-Port-Of: odoo/odoo#191180
Original PR description
Steps to reproduce: 1) Go to website settings and disable 'Shipping address' 2) Add to cart deliverable product and go to checkout 3) See the broken UI This PR adapts UI to the setting of disabling delivery address. opw-4367079 Forward-Port-Of: odoo/odoo#191180
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193571 Forward-Port-Of: odoo/odoo#193358
Original PR description
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193571 Forward-Port-Of: odoo/odoo#193358
Steps to Reproduce: • Install the Employee app. • Switch to mobile view. • Open the Employee app; employee images are not visible. Cause: CSS was not defined for screen sizes smaller than medium. Fix: Added CSS rules for screens smaller than medium to ensure employee images are displayed correctly in mobile view. task-4380126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189829
Original PR description
Steps to Reproduce: • Install the Employee app. • Switch to mobile view. • Open the Employee app; employee images are not visible. Cause: CSS was not defined for screen sizes smaller than medium. Fix: Added CSS rules for screens smaller than medium to ensure employee images are displayed correctly in mobile view. task-4380126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189829
Steps: - Create a discount program with `Discount Code` as the program type. - Add a coupon for the program using the stat button. - Open the POS UI and add products to the cart. - Apply the coupon to the cart. Issue: - A traceback error occurs when applying that coupon. Fix: - added a validation warning when a user attempts to apply a coupon code from a discount code program type (similar to sales) Task - 4422507 Forward-Port-Of: odoo/odoo#191894
Original PR description
Steps: - Create a discount program with `Discount Code` as the program type. - Add a coupon for the program using the stat button. - Open the POS UI and add products to the cart. - Apply the coupon to the cart. Issue: - A traceback error occurs when applying that coupon. Fix: - added a validation warning when a user attempts to apply a coupon code from a discount code program type (similar to sales) Task - 4422507 Forward-Port-Of: odoo/odoo#191894
Steps to reproduce: Not reproducible in V16. However, in older versions, it was possible to have multiple finished_moves with different quantities (see https://github.com/odoo/odoo/pull/46718). This fix ensures such issues are avoided in the future and also addresses potential problems for clients migrating from older versions. Example: Two finished_moves with different quantities. Before the fix, both moves would be updated based on the unbuild quantity, resulting in incorrect quantit
Original PR description
Steps to reproduce: Not reproducible in V16. However, in older versions, it was possible to have multiple finished_moves with different quantities (see https://github.com/odoo/odoo/pull/46718). This fix ensures such issues are avoided in the future and also addresses potential problems for clients migrating from older versions. Example: Two finished_moves with different quantities. Before the fix, both moves would be updated based on the unbuild quantity, resulting in incorrect quantities. After the fix, the moves for unbuild will use only the move's quantity. opw-4379204 Forward-Port-Of: odoo/odoo#193777 Forward-Port-Of: odoo/odoo#191908
Description of the issue this commit addresses: The Italian tax report lacks clarity and can be improved both in readabilty and usability by splitting the monthly and the annual reports. --- Desired behavior after this commit is merged: The Italian tax report is now split in a monthly and an annual report. The report uses the sections mechanism to be split in the different parts it is made from and clean the UI by not having everything on the same sreen. --- Enterprise PR: h
Original PR description
Description of the issue this commit addresses: The Italian tax report lacks clarity and can be improved both in readabilty and usability by splitting the monthly and the annual reports. --- Desired behavior after this commit is merged: The Italian tax report is now split in a monthly and an annual report. The report uses the sections mechanism to be split in the different parts it is made from and clean the UI by not having everything on the same sreen. --- Enterprise PR: https://github.com/odoo/enterprise/pull/62405 Task-3479785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193662 Forward-Port-Of: odoo/odoo#164064
Forward-Port-Of: odoo/enterprise#77251
Original PR description
Forward-Port-Of: odoo/enterprise#77251
[FIX] pos_preparation_display: Prevent Cancel When Payment This commit is a forward port of https://github.com/odoo/enterprise/commit/5108b400d1f7c4b7239fbc3f5651cf9b835d385c. In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed. 1. In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order. 2. A
Original PR description
[FIX] pos_preparation_display: Prevent Cancel When Payment This commit is a forward port of https://github.com/odoo/enterprise/commit/5108b400d1f7c4b7239fbc3f5651cf9b835d385c. In a POS restaurant…
[FIX] pos_preparation_display: Prevent Cancel When Payment This commit is a forward port of https://github.com/odoo/enterprise/commit/5108b400d1f7c4b7239fbc3f5651cf9b835d385c. In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed. 1. In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order. 2. Add another order with the same product and internal note but with a quantity of 5. 3. In the kitchen display, change the stage of the first display line (quantity 2) from "To Cook" to "Ready." 4. In the POS, reduce the quantity of the second order line (quantity 5) to 4. Reducing the quantity of the second order line inadvertently reduces the quantity of the first display line (the one in the "Ready" stage). In `_process_preparation_changes` of `pos_order.py` in the `pos_preparation_display` module, display lines are filtered and sorted based on their creation order. Commit `55f2b24870b664815fe7b926835d07259608ae09` added the `uuid` field, which allows the correct display line to be adjusted when reducing the quantity in the POS order line. Added a tour to test the following use case fixed by this commit (only in version 18.0 and above): 1. In the POS restaurant, add a product with a quantity of 1 and an internal note. Confirm the order. 2. Add another order with the same product and the same internal note but with a quantity of 2. Reduce the quantity of the second order line from 2 to 1. 3. Proceed to payment. In the preparation display module, the original display orders are canceled, and new ones are created instead. opw-4354093 Forward-Port-Of: odoo/enterprise#75976
Steps to Reproduce: ----------------------------------------------- 1. Install the `planning` module. 2. Create a shift from `8:00 AM to 9:30 AM` for any resource. The allocated hours will show as `1:30`. 3. Go to the list view and print the planning report. 4. In the report, you will notice that the allocated hours are rounded up to `2` Issue: ----------------------------------------------- - The allocated hours are being rounded up to a higher value but it should match
Original PR description
Steps to Reproduce:
-----------------------------------------------
1. Install the `planning` module.
2. Create a shift from `8:00 AM to 9:30 AM` for any resource. The allocated
hours will show as `1:30`.
3. Go to the list view and print the planning report.
4. In the report, you will notice that the allocated hours are rounded
up to `2`
Issue:
-----------------------------------------------
- The allocated hours are being rounded up to a higher value but it should match
with the UI and stay consistent.
Cause:
-----------------------------------------------
- The `ceil` function is being used, which rounds the value up to the next
higher number.
Fix:
-----------------------------------------------
- In this commit we removed the `ceil` function to ensure that the allocated
hours are not rounded up.
task-4416792
Forward-Port-Of: odoo/enterprise#77110
Forward-Port-Of: odoo/enterprise#76198How to reproduce: - Install documents_hr_payroll - Go to Marc Demo employee file - Activate debug and click on View:form item of the debug menu - Move the field "work_contact_id" in the sheet tag and make it visible - Return on the Marc Demo employee file - Set a new work contact for Marc Demo (using the field): newContact - Go to the payslip and confirm one of the payslip of Marc - Open HR Payroll directory in the Document App - The payslip of Marc is present, select it and click on "S
Original PR description
How to reproduce: - Install documents_hr_payroll - Go to Marc Demo employee file - Activate debug and click on View:form item of the debug menu - Move the field "work_contact_id" in the sheet tag and…
How to reproduce: - Install documents_hr_payroll - Go to Marc Demo employee file - Activate debug and click on View:form item of the debug menu - Move the field "work_contact_id" in the sheet tag and make it visible - Return on the Marc Demo employee file - Set a new work contact for Marc Demo (using the field): newContact - Go to the payslip and confirm one of the payslip of Marc - Open HR Payroll directory in the Document App - The payslip of Marc is present, select it and click on "Share" The payslip is shared with "Mitchell Admin" and "newContact" so Marc Demo won't be able to see it because it is not shared with the partner of his user. The problem was that the employee work_contact_id partner was used to give access to the payslip (and as contact of the payslip document) while for some employee, the work contact is different than the partner associated with their user. In that case, the payslip is shared with a partner different than the employee user partner and the employee cannot see the payslip. We solve the problem by always sharing the payslip with the partner of the employee user if it exists and we fallback only to the work contact if there is no user associated with the employee. Task-4404015 Forward-Port-Of: odoo/enterprise#75673
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#75884 Forward-Port-Of: odoo/enterprise#73580
Original PR description
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#75884 Forward-Port-Of: odoo/enterprise#73580
Forward-Port-Of: odoo/enterprise#77119
Original PR description
Forward-Port-Of: odoo/enterprise#77119
task-4285805 Forward-Port-Of: odoo/enterprise#77108 Forward-Port-Of: odoo/enterprise#76950
Original PR description
task-4285805 Forward-Port-Of: odoo/enterprise#77108 Forward-Port-Of: odoo/enterprise#76950
Before this commit, when editing a default value for a field, it was always setting th default on the company of the user (as set on the user), not on the current company the user is logged into. This was largely misleading. After this commit, we get and set the default on the current company. Some work need to be done in master to improve those flows. opw-4427384 Forward-Port-Of: odoo/enterprise#77015 Forward-Port-Of: odoo/enterprise#76819
Original PR description
Before this commit, when editing a default value for a field, it was always setting th default on the company of the user (as set on the user), not on the current company the user is logged into. This was largely misleading. After this commit, we get and set the default on the current company. Some work need to be done in master to improve those flows. opw-4427384 Forward-Port-Of: odoo/enterprise#77015 Forward-Port-Of: odoo/enterprise#76819
The code currently tries to access `private_key_id_id` which is actually `private_key_id`. opw-4466293 Forward-Port-Of: odoo/enterprise#77159
Original PR description
The code currently tries to access `private_key_id_id` which is actually `private_key_id`. opw-4466293 Forward-Port-Of: odoo/enterprise#77159
Remove the workaround introduced in https://github.com/odoo/enterprise/pull/76546 because the root cause has been fixed in the linked community PR. https://github.com/odoo/odoo/pull/193256 Forward-Port-Of: odoo/enterprise#77012
Original PR description
Remove the workaround introduced in https://github.com/odoo/enterprise/pull/76546 because the root cause has been fixed in the linked community PR. https://github.com/odoo/odoo/pull/193256 Forward-Port-Of: odoo/enterprise#77012
This file was not loaded in the manifest and is a duplicated of `/mrp_account_enterprise/views/cost_structure_report.xml` Forward-Port-Of: odoo/enterprise#77177
Original PR description
This file was not loaded in the manifest and is a duplicated of `/mrp_account_enterprise/views/cost_structure_report.xml` Forward-Port-Of: odoo/enterprise#77177
Issue: ------ When printing the reports which are Print Check(Top, Middle and Bottom), the address of that particular report is not being formatted properly which makes the printed report poor formatted/ugly. There are three types/formats of report which are Print Check(Top, Middle and Bottom) none of them are getting printed properly(address). View Ref: [Link](https://github.com/odoo/enterprise/blob/saas-17.4/l10n_us_check_printing/report/print_check.xml#L17) **Note:** Not the blank repor
Original PR description
Issue: ------ When printing the reports which are Print Check(Top, Middle and Bottom), the address of that particular report is not being formatted properly which makes the printed report poor…
Issue: ------ When printing the reports which are Print Check(Top, Middle and Bottom), the address of that particular report is not being formatted properly which makes the printed report poor formatted/ugly. There are three types/formats of report which are Print Check(Top, Middle and Bottom) none of them are getting printed properly(address). View Ref: [Link](https://github.com/odoo/enterprise/blob/saas-17.4/l10n_us_check_printing/report/print_check.xml#L17) **Note:** Not the blank reports like Print Blank Check(Top, Middle and Bottom). Solution: ----------- Add an adequate width to the addresses class i.e; `ckus_payee_addr`. Steps to reproduce:- -------------------- 1. Create a demo db in version 18.0 with `l10n_us_check_printing` module installed. 2. Create a payment record and confirm it. 3. Try printing that payment with any of (top/middle/bottom) Print Check reports. 4. check with the address which would've broken. Reference Screenshots: **Without Fix:**  **With Fix:**  OPW - 4454079 UPG - 2408700 Forward-Port-Of: odoo/enterprise#76706
Demo data in those modules were in `data/` folder, they are now in the `demo/` one. Tasks: 4399091, 4464497 Forward-Port-Of: odoo/enterprise#77160
Original PR description
Demo data in those modules were in `data/` folder, they are now in the `demo/` one. Tasks: 4399091, 4464497 Forward-Port-Of: odoo/enterprise#77160
Description of the issue this commit addresses: The Italian annual tax report lacks an integer rounding feature. --- Desired behavior after this commit is merged: The Italian annual tax report uses the HALF-UP rounding method. --- Community PR: https://github.com/odoo/odoo/pull/164064 Task-3479785 Forward-Port-Of: odoo/enterprise#77142 Forward-Port-Of: odoo/enterprise#62405
Original PR description
Description of the issue this commit addresses: The Italian annual tax report lacks an integer rounding feature. --- Desired behavior after this commit is merged: The Italian annual tax report uses the HALF-UP rounding method. --- Community PR: https://github.com/odoo/odoo/pull/164064 Task-3479785 Forward-Port-Of: odoo/enterprise#77142 Forward-Port-Of: odoo/enterprise#62405