Monday, September 30, 2024
26 changes · 18.0
Enhancements to existing features
Users can now move between related discussion threads and create a sub-thread directly from an existing sub-thread using action buttons. This makes conversations easier to explore and helps teams organize follow-up discussions without losing context.
Original PR description
Purpose of this commit: Enable navigating and creating a sub thread from another sub thread using action buttons. task-4202826 closes odoo/odoo#181558
The Discuss sidebar has been visually refined to feel less crowded and easier to scan. Smaller mailbox entries, clearer category styling, stronger unread indicators, and a more recognizable options menu help users navigate conversations more comfortably.
Original PR description
Discuss sidebar feels too crowded, and items take too much space. This commit makes slight adjustments to make it look nicer: 1. discuss Expand/Collapse icon replaced by "..." clickable dropdown -…
Discuss sidebar feels too crowded, and items take too much space. This commit makes slight adjustments to make it look nicer: 1. discuss Expand/Collapse icon replaced by "..." clickable dropdown - motivation: this looks consistent with chat window options, prevent accidental click, and allow to put more options in the future. Also the button looks more like an "options" button 2. sidebar items are smaller in height but wider - motivation: more efficient spacing which looks better 3. mailboxes are significantly smaller in height - motivation: some users do not use mailboxes so less presence is appreciate for them. Besides, they don't need big size of avatar so they can be smaller without much compromise 4. category names are smaller and muted - motivation: they looked too alike to channel items, so this put more distinctive style making less exhausting to use Discuss app 5. category and channel actions are circle buttons, so it looks nice inside square on hovered/active items. Also less opacity so they are less distracting in general 6. active navigable list item is easier to see (colorful rather than greyish) 7. Unread threads are more visible (bolder text) Before <img width="1281" alt="Screenshot 2024-09-29 at 16 57 36" src="https://github.com/user-attachments/assets/88ead9ab-ea2d-44bb-a9c1-762d88050e92"> After <img width="1282" alt="Screenshot 2024-09-30 at 13 29 36" src="https://github.com/user-attachments/assets/97cd2513-d84e-408a-ad78-9d3da57cb977">
Spreadsheet-related insert options are now enabled based on permissions calculated by the server and included in the user's session. This prevents users without document or dashboard editing rights from seeing or using spreadsheet linking options, while also reducing extra permission checks in the browser.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Stock deliveries to customers and production now use make-to-order as the default procurement approach, making replenishment behavior more predictable. The MTO route is enabled by default, dropshipping setup is clarified, and related labels/messages were updated so teams better understand how stock is sourced.
Original PR description
This PR introduces a couple of modifications regarding procurement methods, namely 1. Stock to Customer/Production rules are now using `make to order` procurement method instead of `mts_else_mto` 2. `MTO` route is now unarchived by default 3. `mts_else_mto` message has been modified to better reflect its behavior now task-4150122 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website translations now better preserve inline formatting such as line breaks, bold or italic text, highlights, icons, and styled text. This helps translated website content keep the intended visual presentation instead of losing design details during automated translation.
Original PR description
This commit enhances the handling of inline HTML elements and text highlights when processing translated terms via IAP and ChatGPT. Previously, inline HTML such as `<br/>` and text formatting (bold, italic) were stripped from the source text before sending it for translation, leading to a loss of formatting in the translated output. - Reintroduced `<br/>` at the right place using a markdown syntax in the original text. - SVG text highlights are restored - Font tags including informations about gradient colors are reintroduced - If the whole sentence is wrapped in a tag, the tag is reintroduced after the translation. task-4185355
Tax totals are now calculated consistently when global rounding is used, including invoices with analytic splits or price-included taxes. This reduces small rounding discrepancies and helps ensure accounting documents, reports, and local compliance outputs reflect the correct totals.
Products created by scanning barcodes during receipt processing are now set up as storable by default, including when barcodelookup.com provides the product details. This helps ensure newly created items are included in inventory tracking without extra manual setup.
Original PR description
Products created by scanning a barcode in a receipt (Barcode app) should by default be storable ("Track Inventory" checked). This includes a situation when barcodelookup.com is configured.Users can now open the partner ledger directly from the customer list, making customer accounting review faster. SMS-related actions have also been renamed to “Send SMS” for simpler, clearer wording across follow-up and helpdesk workflows.
Original PR description
First commit will add a new action to open the partner ledger from the customer list view. And the second will rename the follow up action and all occurence of the "send SMS text message" to "send SMS" task: 4213146
Resolved issues and error corrections
Tax totals are now calculated consistently across invoices and other accounting flows, especially when taxes are rounded globally or included in prices. This reduces one-cent discrepancies and improves reliability for invoices with multiple lines, analytic allocations, or complex tax repartitions.
Original PR description
The creation of tax lines is made with 2 duplicated mechanisms: _get_generation_dict_from_base_line is the method saying the granularity of your tax lines. This method is used by everyone using the…
The creation of tax lines is made with 2 duplicated mechanisms: _get_generation_dict_from_base_line is the method saying the granularity of your tax lines. This method is used by everyone using the compute_taxes method. Since V16, a custom similar mechanism has been duplicated on invoices in _compute_all_tax in account_move_line.py => We should have only one mechanism. Then, another problem is the whole logic to compute the round_globally is wrong. Instead of: - compute the tax values per grouping key per tax repartition line per line - aggregate the amounts - round we should: - compute the tax values per tax and per line - round - dispatch the amounts to the repartition lines. Let's take some examples: Suppose 3 lines of: price_unit = 33.33, tax = 10% price_unit = 33.33, tax = 10% price_unit = 33.34, tax = 10% Using round_per_line, each line will compute 3.33 as tax so a total of 9.99. Using round_globally, each line will respectively compute a tax amount of 3.333, 3.333, 3.334 so a total of 10.0. However, depending the current grouping key to compute the tax lines (each one corresponding to a repartition line), the computation could be different. Suppose the analytic checkbox is ticked on the tax and the base lines are: price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_A price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_B price_unit = 33.34, tax = 10%, analytic_distribution = 100% on account_C In this specific case, the total of taxes will be 3 x 3.33 = 9.99 because it will generate 3 tax lines, one for each analytic distribution. Another problem is when dealing with price included taxes. Suppose two lines: price_unit = 21.53, tax = 21% incl price_unit = 21.53, tax = 21% incl Each line will compute a tax excluded amount of round(21.53 / 1.21) = 17.79 So the total untaxed amount is computed as 17.79 x 2 = 35.58. However, since the tax is included in price, the untaxed amount should be round(21.53 * 2 / 1.21) = 35.59 It means there is 0.01 that need to be distributed on invoice's journal items. task-id: 3725705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
The creation of tax lines is made with 2 duplicated mechanisms: _get_generation_dict_from_base_line is the method saying the granularity of your tax lines. This method is used by everyone using the…
The creation of tax lines is made with 2 duplicated mechanisms: _get_generation_dict_from_base_line is the method saying the granularity of your tax lines. This method is used by everyone using the compute_taxes method. Since V16, a custom similar mechanism has been duplicated on invoices in _compute_all_tax in account_move_line.py => We should have only one mechanism. Then, another problem is the whole logic to compute the round_globally is wrong. Instead of: - compute the tax values per grouping key per tax repartition line per line - aggregate the amounts - round we should: - compute the tax values per tax and per line - round - dispatch the amounts to the repartition lines. Let's take some examples: Suppose 3 lines of: price_unit = 33.33, tax = 10% price_unit = 33.33, tax = 10% price_unit = 33.34, tax = 10% Using round_per_line, each line will compute 3.33 as tax so a total of 9.99. Using round_globally, each line will respectively compute a tax amount of 3.333, 3.333, 3.334 so a total of 10.0. However, depending the current grouping key to compute the tax lines (each one corresponding to a repartition line), the computation could be different. Suppose the analytic checkbox is ticked on the tax and the base lines are: price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_A price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_B price_unit = 33.34, tax = 10%, analytic_distribution = 100% on account_C In this specific case, the total of taxes will be 3 x 3.33 = 9.99 because it will generate 3 tax lines, one for each analytic distribution. Another problem is when dealing with price included taxes. Suppose two lines: price_unit = 21.53, tax = 21% incl price_unit = 21.53, tax = 21% incl Each line will compute a tax excluded amount of round(21.53 / 1.21) = 17.79 So the total untaxed amount is computed as 17.79 x 2 = 35.58. However, since the tax is included in price, the untaxed amount should be round(21.53 * 2 / 1.21) = 35.59 It means there is 0.01 that need to be distributed on invoice's journal items. task-id: 3725705
The checkout now blocks customers from using a Mondial Relay pickup point as their billing address, avoiding order errors during payment or confirmation. The relay selection dialog also opens as soon as the delivery method is chosen, making the process clearer and reducing failed checkouts.
Original PR description
It was possible to use delivery as billing address even if delivery address was a modialrelay one. That caused a traceback as it is not allowed to change modialrelay address. This commit will prevent these cases.
Customers can now add products to their cart when click and collect is enabled, even if the website’s default warehouse is out of stock, as long as another selected pickup location has availability. Stock validation is handled later during checkout and payment, with clearer availability warnings and better order warehouse updates when pickup options change.
Original PR description
When warehouse is set on website then website_sale_stock adds logic to handle out of stock products, namely preventing to sell them or adding to the cart. However, when click and collect is activated user can choose a warehouse where the product is available that is not necessarily the one set on the website. For these cases user should be capable to add products in the cart. The validation of the availability is checked later in the /checkout and /payment.
Mobile users who tap a link to a message in a chat channel are now taken directly to the relevant conversation instead of staying on the main Discuss screen. This makes navigation from message links consistent and avoids confusion when using Discuss on mobile.
Original PR description
Before this commit, clicking on message link from a channel in mobile app was not opening the conversation with the message. This happens because when the conversation is a channel, it relies on `active_id` of Discuss app. The auto-set of active thread in Discuss app based on `active_id` works in Desktop but not in mobile, as a result it stays in the "main" screen of discuss app. This commit fixes the issue by invoking explicitly `thread.open()` when thread is set as the Discuss app active thread in mobile. This made it open in chat window, which is how threads are open in mobile in all cases including discuss app. Task-4208169
Fixed an issue that prevented portal users from previewing or downloading files embedded in knowledge articles. The file access information now matches the expected format, avoiding unnecessary access errors.
Original PR description
Purpose: -------- Currently, portal users cannot preview nor download files inserted in knowledge articles. The issue arises because there is a mismatch between the accessToken key used inside the embedded props of the embedded file component and the access_token field used in the file model. Therefore, portal users try to preview/download attachments without access tokens, which results in access errors. This commit renames the key used for the embedded file component so that it matches the one of the file model. Task-4221554
Stock in inter-company transit locations can now be reserved again, allowing companies to use these locations like normal transit points. This supports smoother inter-company transfers now that lots can be shared without being tied to one company.
Original PR description
It used to be forbidden to reserve on inter-company transit, as this could raise issues with transfered lots that would belong to a company being processed in another company. Since now lots can be made company-less for the purpose of being transferable between companies, it would make sense to enable the reservation again, and allow to draw from the inter-company location as if it was a normal transit location. Task-4207078 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes spreadsheet list formulas that spill results across multiple cells so those generated cells are correctly treated as list cells. Users will now see the expected list menus and visual highlights when working with these expanded list formulas.
Original PR description
With the new `SEQUENCE` function and the formula vectorization, we can write spread formulas for lists (e.g. `=ODOO.LIST(1, SEQUENCE(5), "name")`), but the spreaded cells were not recognized as list cells. This caused issues of missing list menu items & missing highlights. Task: [4199994](https://www.odoo.com/web#id=4199994&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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
Changing the note on an existing point-of-sale order line now correctly records the old line as cancelled and the updated line as new. This prevents preparation screens, such as kitchen or bar tools, from mistaking a note edit for an extra item being ordered.
Original PR description
The return value of [`changesToOrder`](https://github.com/abichinger/odoo/blob/74273fea6a9c7f57da95aa120fd2767443822c46/addons/point_of_sale/static/src/app/models/utils/order_change.js#L1) is missing…
The return value of [`changesToOrder`](https://github.com/abichinger/odoo/blob/74273fea6a9c7f57da95aa120fd2767443822c46/addons/point_of_sale/static/src/app/models/utils/order_change.js#L1) is missing a line inside the `cancelled` array, while updating the note of an existing order line. From the POV of a preperation tool, this makes it look like a new item has been added to the order.
https://github.com/user-attachments/assets/618263ac-0a61-42f2-b662-10e1ae63e39f
While recording the video I captured the following values from `changesToOrder`
```jsonc
// 1st output after the orderline was created
{
"new": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
],
"cancelled": []
}
// 2nd output after the note was added
{
"new": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "Zero",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
],
"cancelled": []
}
```
I would expect the second output to look like this
```jsonc
{
"new": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "Zero",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
],
"cancelled": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
]
}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUpdating a note on an existing point-of-sale order line is now treated as a change to that line instead of appearing like an additional item was ordered. This helps kitchen or preparation screens show accurate order updates and avoid duplicate preparation work.
Original PR description
The return value of [`changesToOrder`](https://github.com/abichinger/odoo/blob/74273fea6a9c7f57da95aa120fd2767443822c46/addons/point_of_sale/static/src/app/models/utils/order_change.js#L1) is missing…
The return value of [`changesToOrder`](https://github.com/abichinger/odoo/blob/74273fea6a9c7f57da95aa120fd2767443822c46/addons/point_of_sale/static/src/app/models/utils/order_change.js#L1) is missing a line inside the `cancelled` array, while updating the note of an existing order line. From the POV of a preperation tool, this makes it look like a new item has been added to the order.
https://github.com/user-attachments/assets/618263ac-0a61-42f2-b662-10e1ae63e39f
While recording the video I captured the following values from `changesToOrder`
```jsonc
// 1st output after the orderline was created
{
"new": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
],
"cancelled": []
}
// 2nd output after the note was added
{
"new": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "Zero",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
],
"cancelled": []
}
```
I would expect the second output to look like this
```jsonc
{
"new": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "Zero",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
],
"cancelled": [
{
"uuid": "db47ade6-c8e1-47e1-8dcc-8c43ef67de8a",
"name": "Coca-Cola",
"product_id": 100,
"attribute_value_ids": [],
"quantity": 1,
"note": "",
"pos_categ_id": 10,
"pos_categ_sequence": 0
}
]
}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update prevents certain bank statement workflows from accidentally disrupting the accounting record chain. It also adds clearer guidance when users encounter the affected flow, helping them avoid actions that could compromise locked financial records.
Original PR description
Some specific flows could lead to a break in the hash chain, due to a missing check that ensure no aml are deleted. This check is added, as well as a nicer error message in the flow that would cause the issue to guide the user. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The homepage guided tour now works correctly with the updated page-building flow, where building blocks are selected from a modal instead of dragged onto the page. This makes onboarding and automated checks more reliable by keeping guidance pointers visible and aligned while users browse available blocks.
Original PR description
mass_mailing, test_website, web_tour, website_event, website_mass_mailing, website_payment, website_sale This commit adapts the "homepage" tour following the change in the way building blocks are inserted into a page (now, the blocks are displayed in a modal). Change introduced by this commit [1]. Here are the changes made in this PR: - The "dragNDrop" function of "tour_utils" has been changed and is now called "insertSnippet". Instead of dragging and dropping a category, users now simply need to click on the category. - Before this commit, the "tour pointers" that indicated to users that they needed to scroll the "snippets modal" were misaligned. Their position did not account for the iframe offset of the modal. - Before this commit, the position of the "tour pointers" displayed on the building blocks in the modal was not updated when the modal was scrolled. [1]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a task-4072655
Project users can now open the Documents app directly in the relevant project folder, making it faster to find and upload files. Folder navigation is also corrected so users can browse folders as expected from project-related document views.
Original PR description
Open the documents app directly in the project's folder allows quicker access to documents and upload. We also correct view contexts to show folders to allow navigation. Task-4216195
This update fixes an issue where the Barcode app could reuse outdated cached data when users performed multiple warehouse operations without refreshing the browser. It also makes barcode processing more robust and stabilizes automated barcode workflow checks, reducing the risk of incorrect or flaky warehouse handling.
Original PR description
Fixes persistent cache ================= Before this commit, an old instance of `LazyBarcodeCache` was used by `BarcodeObject` when an operation is done after another operation without any browser's…
Fixes persistent cache ================= Before this commit, an old instance of `LazyBarcodeCache` was used by `BarcodeObject` when an operation is done after another operation without any browser's refresh between them. Cleans `processBarcode` =================== Makes some cleans/improvements/fixes of the `processBarcode` code: - Does nothing if no barcode is given; - Moves all cleaning stuff in its own method, `postProcessBarcode`, so this way this is better organized and easier to override. Fixes failing test tours =============== Following https://github.com/odoo/enterprise/pull/68825, the Barcode app code `processBarcode` is now slightly slower. In consequence, some not so precise triggers in the tours run too faster and don't correctly wait the previous trigger's action to be completed. This commit makes those triggers more precise. Runbot build error: - 99509 `test_receipt_reserved_2_partial_put_in_pack` - 99513 `test_setting_group_lines_by_product` - 99515 `test_inventory_adjustment_tracked_product` - 99520 `test_put_in_pack_before_dest` - 99521 `test_split_line_on_exit_for_delivery` - 99523 `test_split_line_reservation` - 99525 `test_barcode_batch_delivery_1` - 99529 `test_put_in_pack_from_multiple_pages` - 99531 `test_put_in_pack_scan_suggested_package` - 99536 `test_picking_type_mandatory_scan_complete_flux` - 99537 `test_put_in_pack_before_dest` (from picking batch)
Companies can now keep related deliveries and receipts in sync even when automatic inter-company purchase or sales order creation is disabled. This removes a confusing limitation and helps teams maintain accurate stock movements across companies without changing their automation preferences.
Original PR description
Previously, it was considered that a company needed to allow the generation of purchase orders for inter-company transactions in order to allow the sync between deliveries made to it and its own receptions. This implied that a company not allowing automated purchases to be made on itself couldn't sync its receipts with a sale order generated another company following a purchase to it, which is quite confusing user-wise. To avoid that, we allow the sync regardless of the selected options for automated Purchase / Sale Order generation. Task-4207009
This update fixes several issues with the status banner shown during document extraction across accounting, expenses, recruitment, and bank statement workflows. Users should see clearer wording, better layout on smaller screens, fewer duplicate or stale status messages, and disabled actions while extraction checks are still loading.
Original PR description
Fixes for multiple things related to extract status header: - Fix split translation string by choosing a generic term - On smaller displays, the header was not taking up the full width - Added check_status_loading to disable button when rpc is loading - Remove header in expense when the user refreshes a extracted document - Sync record props when switching between documents or manually requesting extraction
Financial budget amounts can now be edited when working across companies that use different currencies. This prevents an error in consolidated profit and loss reporting, helping finance teams update budgets without interruption.
Original PR description
To reproduce: 1) Create two companies, with different currencies, make them both active in the selector 2) Open the P&L 3) Create a new financial budget 4) Try to add an amount to some account for this budget ==> Traceback. This happens because the currency table is not initialized. When modifying a manual value, a different public function is called server-side than when rendering the report ; we need to initialize it there as well.
The update prevents users from linking a menu to a spreadsheet when the required Documents or Dashboard features are not installed. This avoids a crash during confirmation and improves access-right checks around spreadsheet-related integrations.
Original PR description
… nor dashboard Steps to reproduce: * Install hr and spreadsheet (not documents nor dashboard!) * Try to link a menu to spreadsheet * Click confirm => Boom Task: 4134791