Thursday, January 18, 2024
21 changes · 17.0
Resolved issues and error corrections
This fix removes manual bypasses of a core accounting balance check so entries are still validated once multi-step updates are complete. It helps prevent unbalanced accounting records while preserving necessary workflows such as point of sale session validation.
Original PR description
TLDR: the context key `check_move_validity` should never be used explicitly. `check_move_validity` is a context key used to disable some important integrity check in accounting: `debit=credit`, which…
TLDR: the context key `check_move_validity` should never be used explicitly. `check_move_validity` is a context key used to disable some important integrity check in accounting: `debit=credit`, which is one of the most fundamental rule. It is possible to disable this in some cases, when creating and updating lines one by one, since the constraint cannot be satisfied between each line if the operations are not atomic. A mechanism has been created for this, with `_check_balanced`. It is a context manager using `_disable_recursion`, which will taint all the contexts while inside of the context manager. Putting any code changing lines one by one inside of that context manager will then allow having a transient invalid state, but still always check the validity at the end, when exiting the context. That context key has been kept only in `point_of_sale` because a special wizard is used there to be able to validate a session with an unbalanced move, but a wizard is then in charge of balancing it. The check is then done at that time.
Opening a newly added subtask from a project now saves it first, so inherited details from the parent task are available immediately. This prevents users from seeing incomplete subtask forms and avoids needing to go back and reopen the record.
Original PR description
Steps: - Open the Project module. - Open any project. - Add a subtask. - Without manually saving the subtask beforehand, click on 'View'. Form view of sub-task opens that doesn't have any of the…
Steps: - Open the Project module. - Open any project. - Add a subtask. - Without manually saving the subtask beforehand, click on 'View'. Form view of sub-task opens that doesn't have any of the fields it should inherit from its parent task. - Go back to the parent task using the breadcrumbs. - Click on 'View' again. Now, the sub-task has all of its fields set as it should. Issue: - After clicking on 'View', the form view of the sub-task opens, but it doesn't have any of the fields it should inherit from its parent task. Cause: - On clicking 'View', the switchToForm action is called, and this action doesn't save records before switching to the form view. Also, it should load that record into the Parent task after saving. In other modules, when clicking on 'View', the openRecord action is called, which is also not saving data. Fix: - Records should be saved when the action is called on clicking 'View'. For the project module, when the action is called, after saving the record, it should also load records in the parent task. Task: 3631285
This fixes an issue where users could not assign a parent company to an existing company for the first time. Businesses can now build their company hierarchy correctly while still preventing later hierarchy changes that could disrupt records or reporting.
Original PR description
### Steps to reproduce: - Go to **Settings** > **Users & Companies** > **Companies** - Create a new company called **Child Company** - Create a new company called **Parent Company** - Go to the **Child Company** - In **General Information** tab, set the **Parent Company** property to **Parent Company** - An Error is raised stating that "The company hierarchy cannot be changed." ### Investigation: The following commit https://github.com/odoo/odoo/pull/125642/commits/b5d000141a58e6ab4b59c76f127f68ff22cb984c changed the behavior to prevent changing/updating the company hierarchy -Parent > Child- with https://github.com/odoo/odoo/blob/a0741f6427514be5246a5476b5c2f1ca1c23e6e5/odoo/addons/base/models/res_company.py#L297-L298 opw-3660943
This fixes an editor issue where selecting a font size from the toolbar caused the current text selection to disappear. Users can now change font size more reliably without losing their selected text, while website behavior remains unchanged.
Original PR description
This PR addresses an issue where the text selection disappears from editor when clicking on the font size option
from the toolbar.
Modifications:
* The issue of text selection disappearing when interacting with the font size dropdown has been fixed.
* A new toolbar option, `customFontSize`, has been added. This option is exclusively enabled for editor that have a toolbar in the same document. The `readonly` attribute has been added to the input field to make it read-only in our scenario, providing dropdown functionality for font size in the editor. However, the functionality remains unchanged for the website.
task-3500827Fixed an issue where the system would constantly override manually-selected invoice accounts when users changed line labels. Now the system only suggests a different account if it's significantly more confident in the prediction (at least 10% better than the second option), reducing unnecessary interruptions and respecting user choices.
Original PR description
Avoid annoying the user when he put an account manually then changes the label because the account changes again. In order to do that, we only apply the predicted account if it is better than the second option for prediction. To reproduce: * create an invoice * add a line * change the account * change the label of the line Previously, it would always change and override the account even if it had a low certainty about the prediction. Now, it will only override the current account if there is a prediction that is clearly better. The threashold is a ranking at least 10% better than the secondbest choice. [task-3525714](https://www.odoo.com/web#id=3525714&model=project.task) Forward-Port-Of: odoo/enterprise#54026 Forward-Port-Of: odoo/enterprise#53776
This update fixes a readability issue with color-coded lists in Dark Mode. The fix applies the same color styling approach used for badges to color list items, ensuring text and icons remain clearly visible regardless of the background color selected by users.
Original PR description
- Requires : https://github.com/odoo/odoo/pull/138391 task-3524295 -------------------------- This PR fixes an issue about the `colorlist_item` contrast in dark mode. With Odoo 17, the dark mode…
- Requires : https://github.com/odoo/odoo/pull/138391 task-3524295 -------------------------- This PR fixes an issue about the `colorlist_item` contrast in dark mode. With Odoo 17, the dark mode received an update, and the way we handle our tags changed. We now use two CSS variables: 1. `--background-color` for the background ; 2. `--color` to handle the colors of the tags. This approach allow us to have full control on the visual result of our badges depending on the color scheme used by the user, by using the same color but with different adjustments. While this approach was applied to our badges, it was not applied to the `colorlist_item_color` class, resulting in a readability issue in dark mode. To fix this issue, we simply add a `--color` CSS variable inside the color adjustments made to `colorlist_item`, with the same parameters as the badges one, to ensure that the text/icon inside a `colorlist` element is always readable. | 17.0 | master-web-gantt-dark-mode-issue-irsa | | ------------- | ------------- | |  |  |
This fix ensures that when viewing tickets in the Helpdesk portal, the order of grouped tickets remains consistent regardless of how they are sorted. Previously, grouping by Stage would show groups in one order, but sorting by Stage would rearrange them differently, creating a confusing user experience. Now the groups maintain a stable, predictable order.
Original PR description
Steps to reproduce ------------------ 1. Install Helpdesk with demo data, go to the portal > Tickets. 2. Group by "Stage", and look at the order of the Stage groups. 3. Sort by "Stage", and the order of the Stage groups is now different. --- The groups should always be in the same order, regardless of the order of the tickets. This PR makes the order of the groups consistent regardless of the order of the tickets. Task-3675085 Forward-Port-Of: odoo/enterprise#53908
Users can now successfully update timesheets for archived employees without encountering validation errors. Previously, the system incorrectly prevented timesheet modifications for archived employees because it wasn't properly verifying manager permissions. This fix ensures the permission check works correctly regardless of employee archive status.
Original PR description
Before this commit, when the user tries to update a timesheet of an archived employee, he got an error saying:
"Timesheets before the {last_validated_timesheet_date set on the employee} (included) have been validated, and can no longer be modified" The reason is because the employee is archived and so the check does not fetch the employee to be sure the approver who alters the timesheet is the manager/timesheet manager of the employee archived.
This commit fixes the issue by also fetching the archived employees to be sure to check is correctly done as expected.
opw-3613473
Forward-Port-Of: odoo/enterprise#54356
Forward-Port-Of: odoo/enterprise#53832The Knowledge editor has been improved to use the full available width on large displays instead of being limited to 2600 pixels. This eliminates blank space on the right side of the screen and provides a better user experience by allowing the editor to be properly centered and utilize all available space.
Original PR description
Currently, there is a CSS rule constraining all form sheets of Odoo to have a maximal width of 2600px. Since the Knowledge editor is a form view, it is affected by this rule. As a result, the editor does not fully utilize the available space on large displays, leaving blank space on the right side of the screen. To enhance user comfort, we unset the max-width constraint of the form sheet of Knowledge. The page now takes all available space and the editor is now centered. task-3636625 Forward-Port-Of: odoo/enterprise#54513 Forward-Port-Of: odoo/enterprise#53926
This fix corrects how inventory costs are calculated when purchase prices change after partial receipts and returns. Previously, the system was incorrectly using updated invoice prices for all inventory movements, resulting in overstated inventory values. Now it properly uses only the original purchase order price for inventory valuation, ensuring accurate cost tracking.
Original PR description
# HOW TO REPRODUCE - Create Product P, storable, AVCO - Create Purchase Order for 100 units of P for $10 each > confirm - Receive 40 units of P, create backorder - Create Bill, change price to $12,…
# HOW TO REPRODUCE
- Create Product P, storable, AVCO
- Create Purchase Order for 100 units of P for $10 each > confirm
- Receive 40 units of P, create backorder
- Create Bill, change price to $12, confirm
- Return 10 units of P
- Receive 60 units of P
=> unit-cost in SVL is $12 instead of $10
---
Result of the test without the fix:
```
2024-01-11 09:02:45,649 9822 ERROR oes_purchase_test odoo.addons.purchase_stock.tests.test_stockvaluation: FAIL: TestStockValuationWithCOA.test_purchase_with_backorders_and_return_and_price_changes
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/16.0/odoo/addons/purchase_stock/tests/test_stockvaluation.py", line 2740, in test_purchase_with_backorders_and_return_and_price_changes
self.assertEqual(receipt03.move_ids.stock_valuation_layer_ids.ensure_one().value, 300.0)
AssertionError: 375.0 != 300.0
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#148912This fix ensures that when processing point-of-sale orders with EU intracom taxes in Belgium, invoices are automatically created. This is required for proper government reporting of intracom sales, which requires capturing customer details like name, VAT number, and destination country. Previously, settled orders without invoices would cause errors in the EC Sales List report.
Original PR description
Current behavior: In Belgium when using a EU intracom tax, as we need to report those special sales to the government we need to create an invoice as we need to report the customer name, VAT number and the country where the goods are going to end up Steps to reproduce: - Create an order with a product and a tax (0% EU M) - Settle the order in the PoS and pay it (no invoice) - Go to the accounting and check the EC Sales List report - There is an error shown in the report opw-3514737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147572 Forward-Port-Of: odoo/odoo#139467
This update upgrades the spreadsheet application to the latest version (17.0.8) and includes several important bug fixes. The fixes address issues with range handling, markdown link detection, and checkbox styling in data validation, ensuring the spreadsheet feature works more reliably for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0f2d46e7a [REL] 17.0.8 https://github.com/odoo/o-spreadsheet/commit/518469ade [FIX] range: Support ranges with no `Rangeparts` Task: 3608941 https://github.com/odoo/o-spreadsheet/commit/676c3fb43 [FIX] config: remove latest tag https://github.com/odoo/o-spreadsheet/commit/a0cb69a93 [FIX] Cell: Fix detection of markdown links Task: 3628780 https://github.com/odoo/o-spreadsheet/commit/82d2e774e [FIX] Datavalidation: fix checkbox style Task: 3650740
This fix improves the performance of kanban view progress bars when filtering by groups. Previously, when clicking a filter on a progress bar, the system would recalculate data for all groups. Now it only recalculates data for the specific group being filtered, reducing unnecessary processing and improving responsiveness.
Original PR description
When clicking on a filter on a progress bar of a group, the aggregates need to be recomputed. To do this, a web_read_group is called. Since [1], the key groupDomain was removed, with the result that, the web_read_group is called for all the groups and not only for the needed one. This can be a performance issue. Now, the key groupDomain was reintroduced and the web_read_group is done only for the modified filter's group. [1]: https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3
This update corrects how dates are processed in the accounting module to properly account for each user's local time zone instead of always using UTC. This fix is particularly important for users in Latin America where time zones have negative offsets, ensuring that accounting records are dated correctly based on the user's actual location.
Original PR description
Before this commit, the date was being considered in UTC instead of the time zone of the current user. This is problematic in LATAM, where the time zone is negative.
This fix resolves an issue where invoices with multiple product lines and specific tax amounts (16%, 8%, or 0%) would fail to generate messages for the Kenya EDI device. The system can now properly process these multiline invoices with various tax configurations, improving the reliability of electronic invoice transmission.
Original PR description
Before this commit: In the case of an invoice with multiple product lines and a line has a tax amount in (16, 8, 0), a KeyError is raised while generating the message for the device. After this commit: The message for the device can be generated. opw-3674728 Forward-Port-Of: odoo/odoo#149577
This fix enables the shopping cart notification message to display in customers' local languages instead of always appearing in English. A translation function was missing from the code, preventing the system from properly translating the notification title. This ensures a better user experience for international customers by showing messages in their preferred language.
Original PR description
Missing _t to translate a string made it so the cart notification title was always in English. opw-3683578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a performance issue where the system was fetching too many sales order lines, causing slowdowns. The fix removes an inefficient filtering method and replaces it with a more direct approach that only retrieves the relevant sales orders needed for timesheet entries. This will result in faster performance when working with timesheets, especially when dealing with large numbers of sales orders.
Original PR description
Before this commit, the `allowed_so_line_ids` has been introduced to always use `_default_sale_line_domain` method in the domain of `so_line` field and so instead of easing the domain in the field…
Before this commit, the `allowed_so_line_ids` has been introduced
to always use `_default_sale_line_domain` method in the domain of
`so_line` field and so instead of easing the domain in the field definition
we will be able to override the domain by overriding `_default_sale_line_domain`
method. However, since in `sale_timesheet` module, the new domain will contain
a dynamic value in the right part of a leaf
(`('order_partner_id', 'child_of', commercial_partner_id)`), the
`allowed_so_line_ids` is instead use in the domain of `so_line` field to
easily add that leaf in the domain returned `_default_sale_line_domain`
in the compute method of that field. The problem is the number of SOLs
fetched could be really huge and caused a performance issues.
This commit reverts the commit b7491b5b94a1c411fce55565c2bdbddb99b32de5 by
- deprecating the `allowed_so_line_ids`, that is, that field will now always get an empty recordset.
- deprecating the `_default_sale_line_domain` method, that is the method will no longer be used
- manually adding the domain instead of calling `_default_sale_line_domain`
- altering the domain when the `sale_timesheet` module is installed to get the same domain used in the `sale_line_id` of `project.task` modelFixed an issue where payment methods would not appear when customers changed their delivery method during checkout. The fix ensures that payment options are properly refreshed and displayed when switching between delivery methods, particularly when using discount coupons that affect the order total.
Original PR description
This pr contains 2 parts: Part 1: ===== Backport of https://github.com/odoo/odoo/commit/94ed203404b3b2121122697f5ebfe09cc21e3630 to not change the carrier_id on reload. Part2: ===== Issue: ======…
This pr contains 2 parts: Part 1: ===== Backport of https://github.com/odoo/odoo/commit/94ed203404b3b2121122697f5ebfe09cc21e3630 to not change the carrier_id on reload. Part2: ===== Issue: ====== Payment methods doesn't show when updating delivery method Steps to reproduce the issue: ============================= - Install website_sale - Activate coupons and promotions in settings - Create a coupon program with the follwing values : reward: discount, percentage: 100% - Save the program and generate some coupons - Activate at least 1 free delivery method and 1 free delivery method - Activate at least one payment method - Go to shop add anything to cart - Apply one of the codes from the generated coupons - Go to confirm order and change between the delivery methods. - If the default delivery method is free, the payment methods will never show , otherwise they will always show. Origin of the issue: ==================== The payment methods were rendered using `t-if` directive which means that we can't toggle it dynamically since they don't exist in the view. Solution: ========= we reload the page only when we toggle from zero to non zero total. opw-3662606 Forward-Port-Of: odoo/odoo#149782 Forward-Port-Of: odoo/odoo#148431
This fix resolves an issue where users on iOS devices could not sign documents using Safari browser version 15.4 and later. The signing feature would not respond when users attempted to sign documents. This update ensures that document signing works properly across all supported browsers and devices, improving the user experience for mobile users.
Original PR description
Issue: ===== Users with IOS can't sign with safari. Steps to reproduce the issue: ============================= - Install sign - Make sure you have a template which has at least one signature sign item. - Share the docuemnt and open the link with ios on safari in v 15.4+ (browserstack) for example. - Go to the signature sign item and use auto and click sign or sign all - Nothing will happen. Origin of the issue: ==================== https://github.com/niklasvh/html2canvas/issues/2864 Solution: ========= https://github.com/niklasvh/html2canvas/issues/2864#issuecomment-1111044861 opw-3660682 Forward-Port-Of: odoo/odoo#148329
This fix resolves a problem where inventory items were not being properly reserved across multiple sales orders when processing warehouse transfers in a multi-step delivery setup. When validating a picking operation that serves multiple delivery orders, the system now correctly reserves stock for all affected orders instead of just the first one, preventing orders from getting stuck in a waiting state.
Original PR description
Steps to reproduce: - Install Inventory and Sales - Go to "Inventory / Configuration / Settings" - Activate "Storage Locations" and "Multi-Steps Routes" - Go to "Inventory / Configuration / Warehouse Management / Warehouses" - Configure main warehouse: (e.g. San Francisco warehouse) * Outgoing Shipments: Send goods in output and then deliver (2 steps) - Go to "Inventory / Configuration / Warehouse Management / Rules" - Configure the following rule: * Action: Pull From opw-3548123 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149780 Forward-Port-Of: odoo/odoo#149421
Users can now send messages and attach files to archived records without encountering server errors. Previously, attempting to use the messaging feature on archived records would display an error popup, preventing communication and file sharing on these records.
Original PR description
The webclient returns a message "server error" if you add an attachment or send a message on an archived record chatter. **steps to reproduce:** - archive a record (ex: a partner) - send a message on the chatter or add an attachment **before this commit:** - a popup error is raised "server error" **after this commit:** - the chatter is working properly on archived records opw-3689169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr