Monday, September 30, 2024
30 changes
1 change
Resolved issues and error corrections
Users opening Documents from a project are now taken straight to that project's folder, making it faster to find and upload project files. Folder navigation is also corrected so users can move through document folders as expected.
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. (Setting `action_id` to `False` for updating existing records, see `check_only_one_action_defined`) Task-4216195
18 changes
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…
11 changes
Resolved issues and error corrections
This fix ensures that the packaging button appears in the barcode app's inventory adjustment feature, even when no initial quantity demand is set. Previously, users couldn't quickly add products in packaging multiples during inventory adjustments because the button was hidden. Now the button displays correctly, making it easier to process packaged items.
Original PR description
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a product with a barcode - Inventory > Configuration > Product Packaging > New - Create a packaging for that prodcut with a quantity of 10 - In the barcode app create an inventory adjustment or a new immediate transfer and scan your product - Click on the pencil icon > you are redirected to the digipad #### > The button to add prodcuts by multiple of your packaging is not there ### Cause of the issue: Currently, a packaging buttons is only displayed if the quantity of the demandQty of the move line is higher or equal to the packaging qty: https://github.com/odoo/enterprise/blob/dbe94f71121851babeb1831814ccc3349301430e/stock_barcode/static/src/widgets/digipad.js#L63-L81 However, it should also be is the picking or inventory adjustment did not defined an initial demand. ### opw-4156249
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
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
This fix adds a safeguard to prevent certain bank statement actions from disrupting the integrity of accounting records. It also improves the error message so users are guided more clearly when an action cannot be completed.
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.
This fix corrects how employee salaries are calculated in Mexican payroll when employees are paid on a weekly or other non-monthly schedule. Previously, the system was incorrectly dividing the wage amount by a pay schedule coefficient, resulting in incorrect basic salary amounts on payslips. The fix ensures employees receive the correct wage amount for their pay period while maintaining proper calculations for special payments like Christmas bonuses.
Original PR description
Issue: ====== `paid_amount` is not calculated correctly when the schedule pay isn't month. Steps to reproduce the issue: ============================= - Switch to MX company - Go to roque and employee and add these values to his contract : salary structure type( Mexico:Employee) - both schedule pay fields (weekly) - add any amount in wage. - Go to payslips and create one for roque and click on compute sheet - Go to salary computation tab - Basic salary is wrong it should be the amount you put at the start. Origin of the issue and solution: ================================= We were dividing by the coefficient of the pay schedule but in reality we didn't have to since we create the payslip for the period of the schedule pay so it will have the full mentioned wage. But for the christmas we need to divide by the coefficient since it's computed by `days/year`. opw-413332
This fix resolves an issue where combo products could not be invoiced in Peru due to a tax validation error. Combo products don't require individual tax assignments since taxes are applied to each component product within the combo. The fix treats the parent combo line similar to notes or sections on quotations, allowing invoicing to proceed without errors.
Original PR description
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_pe_edi_pos** * Switch to the **PE Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Taxes need to be assigned on all invoice lines Why the fix: ------------ Combo products do not have the possibility to be assigned a tax, as they are not supposed to. Taxes are computed for each product chosen and applies on that product. We can treat the parent combo line as the note or sections we would put on a quotation. opw-4090946 Community PR: https://github.com/odoo/odoo/pull/181068
This update corrects how times are displayed in the Field Service task view when using 12-hour time format. Previously, times showed incorrectly as "02:00 A" instead of "02:00 AM/PM". The fix corrects a formatting error so that AM and PM indicators now display properly for users in regions using 12-hour time formats.
Original PR description
### Steps to reproduce: - Install Field Service module - Set 12-hour time format in the languages - Navigate to My tasks kanban view in Field Service ### Current behavior before PR: When having 12-hour time format for Field Service it will be shown in the kanban view as '02:00 A' for example. This is happening because when formatting the time in the fsm_date widget the format we are using have a typo 'hh:mm A' where the 'AM, PM' should be represented with lowercase 'a' not uppercase 'A' ### Desired behavior after PR is merged: Fixed the typo and added the correct format opw-4178726 Forward-Port-Of: odoo/enterprise#70250
Fixed an issue where the EC Sales List menu option was not appearing when installing the French localization module. Users in France can now access the EC Sales List reporting feature directly after installing the French localization without needing to install additional modules.
Original PR description
Currently the EC Sales List menuitem is not visible when only installing `l10n_fr_reports` (and no other localization activating the item). To reproduce it you need to install `l10n_fr_reports` on a database where the item is not already visible. (It does not work on the runbot.) Forward-Port-Of: odoo/enterprise#70723
This fix resolves an issue where users were redirected to an error page after logging in to access a knowledge article view link. The problem occurred because the system was generating an incorrect redirect URL. The fix ensures users are properly redirected to the correct article view after authentication, allowing them to access shared knowledge articles seamlessly.
Original PR description
When a visitor clicks on a view link, they are redirected to the login page to authenticate and gain access to the view. This is necessary to ensure the user has the appropriate permissions to open…
When a visitor clicks on a view link, they are redirected to the login page to authenticate and gain access to the view. This is necessary to ensure the user has the appropriate permissions to open the view and access the records.
Current problem:
When clicking on a view link, the users are redirected to an error page after successfully logging in. This happens because the system generates a faulty redirection URL (`/knowledge/article/undefined`) for the login page. This occurs because the `KnowledgeWidget` widget generates the URL using `this.resId` (`/knowledge/article/{this.resId}`) and the widget does not have any `resId` property set.
Steps to reproduce:
1. Open any list or kanban view
2. In the view's cog menu: "Knowledge" > "Insert link in article"
3. Click the "New" button to create a new article
4. After being redirected to the article, click on the "Share" button
5. Publish the article
6. Copy the generated article URL
7. Open a private window and paste the URL
8. Click the view link
9. Enter valid credentials
=> After logging in, the user is redirected to an error page.
TO BE: After logging in, the user should be redirected to the backend view of the article. The user should then be able to open the view by clicking on the view link.
Solution:
To solve this issue, we will use `this.$id` instead of `this.resId` to get the current article id.
Reference: https://github.com/odoo/enterprise/pull/57346
task-4210743Planning users can now see and access the Schedule by Sales Order menu when they have the appropriate permissions. This fix ensures that the menu visibility is properly controlled based on user access rights, allowing planning teams to manage schedules more effectively.
Original PR description
Before: The Schedule by Sales Order menu was not visible to planning users, even if they had the necessary access rights. After: The Schedule by Sales Order menu is now visible to planning users who have the appropriate access rights. Fix: Add the user group so that the menu will now be visible based on the user's access rights. Task:4192098
This fix resolves a problem where the order of insurance solutions in employee contracts was affecting salary calculations for IJM and LAAC insurance types. Previously, changing from multiple insurance solutions to fewer ones could result in incorrect cumulative salary calculations. The system is now position-aware, meaning the number and order of insurance solutions no longer impact the accuracy of payroll calculations.
Original PR description
Currently, order of Many2many insurance_line_ids matters for IJM and LAAC, which can be error prone in the case where you go from example from 2 solutions -> 11,12 to one solution -> 12, the cumulated salaries will not be computed properly in this case. We make the rules Position aware in this PR, meaning that order or quantity of solutions in the contract does not matter anymore.
This fix resolves an issue where customer and sale order information were not automatically populated when portal users created tasks in shared Field Service projects. The problem occurred because the quick task creation form was missing a required field reference, preventing the system from automatically filling in customer details. This update ensures that when users quickly create tasks, all relevant customer and billing information is properly set.
Original PR description
- Install the Field Services (industry_fsm) and sales module. - Create a sale order with the following configuration: - Select any customer. - Select the product 'Junior Architect' (Invoice on…
- Install the Field Services (industry_fsm) and sales module. - Create a sale order with the following configuration: - Select any customer. - Select the product 'Junior Architect' (Invoice on Timesheets). - Confirm the sale order. - On the header of the sale order, click on the project option. - Then, in the left side corner, click on 'Share Editable'. - Share the project to your company. - Log in as a portal user. - Open the projects menu. - Open the project you just shared. - In the kanban view, click on the 'Quick Create Task' button. - Add a task name and click on the edit button. - You will see the form view where the customer and sale order item are not set by default. Issue: ------------------ When logging in as a portal user(project sharing), the fields for Customer and Sale Order Item are not set by default when creating a task via quick create in the Kanban view. Cause: ------------------- The _compute_partner_id function relies on the project_id field to determine the partner_id (customer) for a task. However, in the quick create view, only the partner_id field is mentioned . in the quick view, the project ID is not provided so the partner ID cannot be computed, resulting in an empty field for the partner_id (customer). Solution: ---------------------- add a project_id field in the 'project_sharing_quick_create_task_form_inherit' quick create form view. task-3743360 Forward-Port-Of: odoo/enterprise#57113
This fix prevents invisible fields and text elements from being incorrectly displayed inside button boxes when using the Studio visual editor. When toggling the "show invisible elements" option in Studio, some hidden fields were appearing in button areas where they shouldn't be visible, which has now been corrected.
Original PR description
Steps to reproduce ================== - Install studio,project - Open any task - Open studio - Toggle show invisible elements => Some fields are displayed inside the button box Cause of the issue ================== Some always invisible non buttons elements are sometimes used inside a button box. https://github.com/odoo/odoo/blob/1c685b9ce7483c426fc2db964ef357003229ddc6/addons/project/views/project_task_views.xml#L269-L275 opw-4164661
This fix resolves an issue where the 'Time Spent' label was not displaying in the helpdesk portal when multiple support teams had different timesheet settings. The system now correctly shows the label if any team has time tracking enabled, rather than only checking the first team. This ensures customers see accurate timesheet information regardless of how their tickets are organized.
Original PR description
Steps to reproduce: - Install the helpdesk_sale_timesheet module. - Create two helpdesk teams (e.g. VIP Support and Customer Care). - Enable time billing and timesheets for the VIP Support team only.…
Steps to reproduce: - Install the helpdesk_sale_timesheet module. - Create two helpdesk teams (e.g. VIP Support and Customer Care). - Enable time billing and timesheets for the VIP Support team only. - In the portal view of tickets observe that the "Time Spent" label is missing Issue: - In the portal view you will see the 'Time Spent' label missing. Cause: - In the portal view of tickets the 'Time Spent' label is missing because when data is grouped (e.g. by stage, assignee, or team) it will check for the first group of tickets. It evaluates group in ascending order and if `use_helpdesk_sale_timesheet` is set to false for the first group the 'Time Spent' label will disappears even if it's enabled for other group. Fix: - In this commit we will check the `use_helpdesk_sale_timesheet` field for every ticket in the list. If it is set to true for any ticket the "Time Spent" label will be displayed; otherwise it will remain hidden. limitation : - In this case we need to add the list because removing `any` from the condition would violating our stability policy. task-4058210 Forward-Port-Of: odoo/enterprise#69331