Daily updates from Odoo
Wednesday, March 4, 2026
35 changes · saas-19.1
Resolved issues and error corrections
This update corrects a minor issue in the Documents app where the action title wasn't consistently accurate for different types of account moves. Now, when creating account moves from the Documents app, the action name (like 'Vendor Bills') correctly reflects the move type, improving clarity and usability for users.
Original PR description
Previously, creating account moves from the Documents app opened the account.move list view with a static `Invoices` title, which was not explicit for all move types. Steps to reproduce: 1. Select suitable PDFs in Document App. 2. Click on `Vendor Bill`. 3. See the name of action (below Breadcrumbs) should be `Vendor Bills` instead of `Invoices` This fix adds and uses a mapping based on move_type to set the correct action name (e.g., Vendor Bills) after record creation. task-5983372 Forward-Port-Of: odoo/enterprise#109307 Forward-Port-Of: odoo/enterprise#109180
This update allows managers to automatically launch appraisal campaigns for all their team members, even if they don't select individuals from a list. This simplifies the process for managers and ensures all employees are included in the appraisal cycle. The change includes new tests to verify the functionality.
Original PR description
. Allow the Leader to launch an appraisal campaign for all their employees by default when no specific employees are selected in the list. task-5347755 Forward-Port-Of: odoo/enterprise#100214
This update fixes an issue where flexible resources were incorrectly displaying a total of 40 hours per week. The fix ensures that the system now accurately reflects the employee's scheduled hours (38 hours) when calculating available time. This improves the accuracy of scheduling and resource allocation.
Original PR description
### Steps to reproduce: - Download Planning app - From the employees app, create an employee - Assign that employee a new schedule that is 'Flexible', has 07:36 hours/day 'Avg', and has 'Total' 38 hours/week - Search for that employee in the planning app and hover over their name ### Cause of Issue: The total available hours for that employee show as 40h. This is because when calculating the hours per week for the resource, the resource's schedule is not taken into account but the company's. ### Fix: Add the hours per week for the resource's calendar (if available) in the calculation opw-5954982 Forward-Port-Of: odoo/odoo#250185
This update fixes an issue where resource scheduling wasn't accurately calculating working hours when using full-day periods. The system now calculates the midpoint between start and end times, ensuring correct representation of half-day schedules. This improves the accuracy of resource availability and time tracking.
Original PR description
### Steps to reproduce: - Go to any working schedule of an employee. - Add a working hour line for any day and choose day period as full day. - Change work from 10:00, and work to 18:00. ### Issue: - Resource was explicitly setting 12 if any hour_from/hour_to was missing. - Resource always consider that the working time is 8AM-5PM. ### Fix: - We will calculate the avg of working hours( hour_from + hour_to)/2 - Doing this we will always get the middle of day. task: 5912748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247756
This update fixes a data issue in the Danish (DK) demo company data within Odoo. Specifically, the street number was missing, which was required for proper integration with Nemhandel (the Danish e-commerce platform). This ensures accurate reporting and functionality for users working with the DK demo environment.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task Forward-Port-Of: odoo/odoo#250970
This update fixes inaccuracies in the Bulgarian tax settings within the Odoo accounting system. Specifically, it corrects incorrect tax names and changes the default purchase tax rate to 20% FTC, aligning with current Bulgarian regulations. This ensures accurate tax calculations and compliance for Bulgarian businesses using Odoo.
Original PR description
Fixing incorrect tax names and changing the default purchase tax to 20% FTC instead of 20% PTC. task-5935754 Forward-Port-Of: odoo/odoo#251593 Forward-Port-Of: odoo/odoo#249269
This update corrects a bug where related fields within many2one chains were displaying the wrong model data. Specifically, when creating a chain with duplicate field names, the popover would incorrectly show fields from a different model. This issue was caused by a recent update to support properties in field definitions.
Original PR description
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if…
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected. Steps to reproduce 1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b), model_b.x_studio_test(relation=other_model)`. 2. Create a related field on model_a and click the related icon for the test field. 3. The popover will now be displaying the fields for other_model instead of model_b. Cause: This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). Solution: Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`. opw-ticket 5459944 Forward-Port-Of: odoo/odoo#249185
This update resolves a minor visual issue with the select menu in Odoo, specifically addressing styling inconsistencies when scrolling. The fix ensures a consistent and polished appearance for the select menu across the base and base_import modules. This improves the overall user experience.
Original PR description
Before this commit, the select menu with its dropdown opened had a little style issue when scrolling base_import's select menu had also a style which was a bit off. After this commit, those are fixed part-of-task-5935511 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
This update resolves a minor display issue in the accounting dashboard where the 'Reconnect Bank' button incorrectly appeared for accounts without an expiration date. The fix ensures the button only shows when a valid numerical expiration date is present, improving the user experience.
Original PR description
The aim of this commit is fixing the behavior of Reconnect bank button in accounting dashboard. Before this commit, a synchronization without any expiring date will always show the Reconnect bank button in the accounting dashboard because the expiring due days (in the JS widget) is null and not undefined. This condition led to check the second part of the condition where null <= 0. Which is true in javascript. Now, we are checking the type of expiring due days as first condition, if it's not a number, we don't check the second part of the condition, and then we don't display the Reconnect Bank button. no task id
This update corrects a test case in the quality control module to reflect a recent change in how Odoo handles merging stock transfers. Specifically, transfers now only merge into existing ones when a 'stock reference' is defined. This ensures the test case accurately reflects the current system behavior and avoids potential issues.
Original PR description
Fix the test case to align with the updated picking move merge behavior, where the next transfer merges into an existing one only when a stock reference is set TaskID-5242340 Forward-Port-Of: odoo/enterprise#108520 Forward-Port-Of: odoo/enterprise#99342
This update corrects a bug that prevented drag-and-drop functionality when using Arabic or other RTL languages. The fix adjusts the detection logic to properly identify drops outside of the sidebar, ensuring a consistent user experience regardless of language settings. This improves usability for a wider range of users.
Original PR description
When dropping outside a dropzone but still on the page, the code checks if the drop happened well outside of the sidebar (so on its left). However, in RTL languages, the sidebar is positioned on the left, so we need to check if the drop is on the right side of it instead. The fix checks if the sidebar is at the left edge (the body of the document should have the `o_rtl` class) and verifies the drop position is on the right of the sidebar. Steps to reproduce: - Set your profile to Arabic - Drag and drop a snippet outside of a dropzone => It's not dropped, but it should, as it would with an LTR language. task-5484936 Forward-Port-Of: odoo/odoo#251041 Forward-Port-Of: odoo/odoo#247759
This update resolves an issue where US-specific reports were incorrectly appearing in Odoo databases configured for India. The fix ensures that the necessary US Payroll module is automatically installed when the l10n_in_hr_payroll module is installed, preventing this unintended report visibility.
Original PR description
**Version:** saas-19.1 **Steps to reproduce:** - Create a new database with India as country. - Install l10n_in_hr_payroll. - US company based reports are visible. **Issue:** Reports specific to us payroll localisation are visible for base hr_payroll module **Cause:** The l10n_us module was missing as the auto_install dependency. **Solution:** Added l10n_us as the auto_install dependency in the manifest file. **task-5948747**
This update resolves a technical error that prevented users from hearing incoming ringtones during VoIP calls. The fix ensures the necessary service is correctly initialized, allowing ringtones to play as expected. This improves the user experience for VoIP calls.
Original PR description
requestIncomingRingtone() was calling this.ringtoneService.incoming.play(), but ringtoneService is not defined on UserAgent, leading to: ``` TypeError: Cannot read properties of undefined (reading 'incoming') when handling VOIP:PLAY_INCOMING. ```
This update resolves an issue preventing multiple tax lines on Italian invoices processed through the l10n_it_edi_doi module. Previously, only the DOI tax could be applied. Now, other taxes like Enasarco and RIT can be added to the same line, aligning with Italian tax regulations. This ensures accurate invoice processing for Italian businesses.
Original PR description
We should be able to add more taxes with the 0% on the same line, like the Enasarco and 23% RIT. Indeed in italy it is possible to have invoices with Dichiarazione d'intento togheter with a withholding and Enasarco taxes. See also: odoo/odoo#236251 Ticket [link](https://www.odoo.com/odoo/project.task/5933699) opw-5933699 Forward-Port-Of: odoo/odoo#248586
This update resolves a technical issue within the Odoo Enterprise HR payroll module that prevented users from editing date inputs in a specific form view. The fix ensures the popover is displayed before the input is cleared, restoring full editability. This improves the user experience for payroll processing.
Original PR description
With this additionnal step in tour, we ensure the popover is opened before clear the input. If we not wait for this, the input can be no longer editable. runbot-error-id~234440 Forward-Port-Of: odoo/enterprise#109346
This update resolves an issue where vendor bills from foreign VAT companies were not correctly identifying their country of origin. The fix adds the necessary country code to the beginning of the invoice data, ensuring accurate reporting for JPK (Polish VAT reporting).
Original PR description
PR #81359 fixed the country code for foreign VAT companies by adding the country code to the start. However, this was only fixed for invoices going out, not vendor bills coming in. [opw-5917264](https://www.odoo.com/odoo/project.task/5917264) Forward-Port-Of: odoo/enterprise#109080
This update fixes an issue where employee names weren't consistently displayed across related fields in the HR module. By standardizing the formatting of these names, the system now presents a cleaner and more accurate view of employee information. This improves the user experience and data consistency.
Original PR description
Copy string and help field attributes for virually related employee fields. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that disabled user accounts are no longer incorrectly flagged as blacklisted when checking email communication. This prevents unnecessary restrictions and improves the overall user experience. The change was made to align with previous work and includes new tests for verification.
Original PR description
Same as https://github.com/odoo/odoo/pull/249466, but for v17 and with tests. > When computing wether the user is blacklisted, disabled records must be ignored. > > https://www.loom.com/share/41ea437477f8416f8b50f9ef979d82bf > > > --- > I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr > > @moduon MT-13153 OPW-5952301 Forward-Port-Of: odoo/odoo#250361
This update resolves a test failure within the Belgian payroll module (l10n_be_hr_payroll_fix) by adding a temporary freeze to time calculations. This ensures the holiday attest test now passes, maintaining the correct payroll processing for employees in Belgium. The fix was implemented to address a technical issue identified during automated testing.
Original PR description
Addind freeze_time to Fix holiday attest test that failed on the runbot Forward-Port-Of: odoo/enterprise#107490
This update corrects a display issue where upsell sales orders created from subscriptions incorrectly showed as "Quotation" instead of a standard sales order. The fix ensures that upsell orders now display their correct type, aligning with how initial subscriptions are presented, improving clarity for users.
Original PR description
## Issue When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate. <img width="1330" height="296" alt="5489970"…
## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.
<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />
## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
- Any Customer
- Any Recurring Plan
- Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**
## Cause
The title shown in the preview is defined here:
https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195
The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237
The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.
## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803
<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />
## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.
opw-5489970
Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#106767This update corrects a technical issue preventing stock users with 'Own Documents Only' sales access from successfully opening delivery orders. The fix avoids unnecessary security restrictions by computing the delivery description directly, rather than relying on complex rule overrides. This ensures smooth operation for all users.
Original PR description
### Steps to reproduce: - Create a Stock User with access rights: - Sales: User: Own Documents Only - Inventory: User - With your admin: Create and confirm a sale order for 1 x a consumable. - With…
### Steps to reproduce:
- Create a Stock User with access rights:
- Sales: User: Own Documents Only
- Inventory: User
- With your admin: Create and confirm a sale order for 1 x a consumable.
- With the Stock User open try to open the delivery
#### > Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.
### Cause of the issue:
Sale users `Own Documents Only` are granted read access to the `sale.order` model which is restricted to the `sale.order`'s to which they are the designated sale person or no-one is due to this `ir.rule`: https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale/security/ir_rules.xml#L44-L49 However, the read access of the sale order related to a stock move is required in order to compute its desciption:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/models/stock.py#L26-L31 While this access is suppose to be provided:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/security/ir.model.access.csv#L5 It is overriden by the `ir.rule`.
### Fix:
Since the `_compute_description` overrides rely on numerous independant models such as the `sale.order`, `purchase.order.line`, `product.supplierinfo`, `mrp.bom`, since the `picking_description` does not really carries sensitive informations and since parts of the computes already required to be put in `sudo` for similar reasons see 80c80505fabc4544e41f270169737218e47cad5a, it is preferable to compute the field in sudo rather than adding an `ir.rule` with true leaf on the `sale.order` model for the `stock.group_stock_user`.
opw-5929485
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251471This update fixes a minor issue where installing a new language in Odoo didn't immediately show the language option in the user preference settings. The fix clears all caches after language installation, ensuring the new language appears promptly and avoids confusing the user. This improves the overall usability of the language selection process.
Original PR description
Before this commit, after installing a new language, that language wasn't directly available in the selection field of the user preference form view. An extra reload was necessary to see the new language, which could confuse the user. This was due to the cache. As installing a language isn't a frequent operation, we simply clear all caches when this happens. task~5895416 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#251729
This update fixes an issue where long email addresses in the Point of Sale partner list were difficult to read due to awkward wrapping and inconsistent spacing. The changes now automatically truncate long emails and ensure all text and buttons are vertically aligned for a cleaner, more user-friendly experience.
Original PR description
Before this commit, long email addresses in the POS partner list would wrap awkwardly or expand the row height excessively, making the list difficult to read. Additionally, the vertical alignment between the text and the action buttons was inconsistent. This commit improves the Partner List UI by: - Truncating long email addresses - Adding a `title` attribute so the full email is visible on hover - Vertically centering all cell content to match the buttons. opw-5919153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247964
This update corrects an issue where the display of shift durations in the Planning app was inaccurate when shifts spanned across multiple days. The fix removes outdated logic that truncated shift names, ensuring correct hour representation regardless of the shift's length. This improves the accuracy of shift scheduling and reporting.
Original PR description
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an…
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an employee from 3pm to 2am (over two days) - The hours of the shift are displayed - Modify the shift end to 3am - The hours of the shift aren't displayed ### Cause: Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c). But as the pills are no longer truncated since 17.0, the computation of pill names is faulty. ### Solution: We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it. opw-5881532 Forward-Port-Of: odoo/enterprise#109397 Forward-Port-Of: odoo/enterprise#107233
This update resolves an issue where approval rules for account moves incorrectly activated list view actions. The fix ensures that when an approval rule action is set up, the associated list view action is automatically deactivated, preventing unintended actions. This improves the reliability and accuracy of the approval process.
Original PR description
Following commit odoo/odoo@c442f72479b50855f40ba079800ee9e5a5690753 When putting an approval rule action_post (account.move) the action bound to the list view must be deactivated. opw-5921128 Forward-Port-Of: odoo/enterprise#106853
This update resolves an issue where the Sendcloud shipping API required a minimum product weight of 0.00099. This commit ensures that product weights are always at least 0.001, preventing errors and ensuring accurate shipping calculations through the Sendcloud integration. This improves the reliability of shipments processed through Sendcloud.
Original PR description
The Sendcloud API do not allow parcel details to have a weight value less than 0.00099 . This commit makes sure the products weights are at least 0.001. ref: <img width="1850" height="689" alt="image" src="https://github.com/user-attachments/assets/10242315-3c4d-4670-b77d-8cb429e00891" /> Forward-Port-Of: odoo/enterprise#107676
This update resolves a problem where sales staff couldn't correctly update or reset payment tokens within subscriptions. A technical change in Odoo's data processing now required elevated permissions to calculate the token's display name, leading to an error. This fix ensures the display name is correctly generated, allowing users to manage payment tokens as intended.
Original PR description
Use case: - install `payment_sepa_direct_debit` module. - As salesman go to a subscription and try to change/reset the payment token field. When trying to get the values of the `payment_token_id` fields [`name_search()` call] an `AccessError` is raised saying that we don't have access to `payment.provider` model. Since odoo/odoo@a3eef91230e0, fetch() do compute fields, so for payment token this means that `display_name` will be computed without su=True flag, thus it may raise an `AccessError` if accessing some payment provider fields. So this commit force building token display name as sudo, to ensure it can be correctly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an aesthetic issue with the display of poll results in message lists. Previously, there was an unnecessary gap above the poll result box, which has now been removed. This ensures a cleaner and more professional look for users interacting with polls.
Original PR description
Before this commit, Poll Result in message list had some unwanted spacing between the message header and the poll result box. The bottom spacing is fine but not the top. Before / After <img width="263" height="161" alt="Screenshot 2026-03-04 at 16 44 12" src="https://github.com/user-attachments/assets/b827bc1e-ee67-4f73-bea5-3bfc3ed7ed2d" /> <img width="271" height="150" alt="Screenshot 2026-03-04 at 16 43 57" src="https://github.com/user-attachments/assets/fc816b40-f375-48f3-a283-ea064d2b4cfb" />
This update fixes an issue where the cursor wasn't correctly navigating within long text blocks inside Odoo tables. Previously, users couldn't move up and down within multi-line text cells. This change ensures accurate cursor movement within table cells with long text, improving the user experience.
Original PR description
When navigating inside a table cell, if a single text node is rendered over several lines, the cursor up and down key go directly to the next cell instead of navigating to the (visually) previous or next line of text. This commit determines if the cursor position is within such positions inside a multi-line text node and prevents the table navigation if needed. Steps to reproduce: - Add a table with `/table` - Put a very long text (without paragraph splits) in the center cell, so that the text spans over several lines - Navigate with the up and down arrows => The cursor could not reach distinct lines within the text task-5417834 Forward-Port-Of: odoo/odoo#240764
This update resolves an issue where the website editor wouldn't allow users to change rounded corner values when using themes with unitless '0' values for border-radius. The fix ensures that users can now modify rounded corners without errors, regardless of the theme's styling.
Original PR description
**Problem:** When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the…
**Problem:**
When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the following error occurs: "Cannot convert 'px' units into '' units !"
**Steps to reproduce:**
1. Install and activate the Anelusia theme (or any theme with unitless border-radius: 0)
2. Open the website editor
3. Select any element (e.g., a table in the footer)
4. Try to change the "Rounded Corners" field to any non-zero value
5. Observe the error: "Uncaught Promise > Cannot convert 'px' units into '' units !"
**Current behavior:**
The website editor throws a JavaScript error and prevents changing rounded corners.
**Expected behavior:**
Users should be able to modify rounded corners values without errors, regardless of whether the theme uses unitless or unit-based zero values.
**Cause of the issue:**
Some themes define border-radius variables as unitless `0` (e.g., `$border-radius: 0`). When the website editor's areCssValuesEqual() function in utils_css.js compares the new value (e.g., "10px") with the existing computed value ("0" - unitless), it attempts to convert between units. The getNumericAndUnit() function extracts the unit from "0" as an empty string "", then convertValueToUnit() tries to convert "10px" to "" unit. Since there's no conversion defined for "px" to "" (empty unit), convertNumericToUnit() throws the error.
**Fix:**
Add a special case in areCssValuesEqual() to handle unitless zero values before attempting unit conversion. When the first value is unitless "0", we compare the numeric values directly using Number.EPSILON, avoiding the unit conversion entirely. This allows proper comparison between unitless "0" and values like "10px" or "0px" without errors, while maintaining correct equality checks (0 equals 0px, but 0 does not equal 10px).
opw-5412414
Forward-Port-Of: odoo/odoo#246335This update resolves a technical issue where new chart types added to Odoo weren't clearly labeled in the data selection menus. Previously, it was difficult to distinguish between different chart types. Now, a placeholder name has been added to improve the user experience and make chart type selection more intuitive.
Original PR description
We recently added a lot of chart types that handle Odoo data but we faialed to add a placeholder name (which is handy to differentiate them in the datasource menu). Task-5979722 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#251135
This update corrects a bug that occurred when the 'commercial_partner_id' field was visible on the contact form (using web_studio). Previously, an error would be triggered when using the IAP autocomplete, preventing contact creation. This fix ensures the 'commercial_partner_id' field is always populated, resolving the issue and improving the contact creation process.
Original PR description
Before this commit, when commercial_partner_id is on the view (possible with web_studio), the value by default is False. When the autocomplete widget is used, many fields could be autofilled and raise _onchange_verify_peppol_status, that requires this field. To avoid this issue we review that the value has been filled. Steps to Reproduce: 1. Open the Contacts app 2. Open Studio on the contact form view 3. Add the field commercial_partner_id to the form view (make it visible) 4. Create a new contact 5. Type a name 6. Select a suggestion from the IAP autocomplete 7. An error is raised immediately OPW-[5896847](https://www.odoo.com/odoo/action-4043/5896847) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251590 Forward-Port-Of: odoo/odoo#248895
This update fixes a bug where combo product prices were being incorrectly doubled. The issue stemmed from an error in how prices were calculated within the Point of Sale system. Now, combo prices are accurately displayed, ensuring correct transactions.
Original PR description
Combo product prices were doubled in the `comboTotalPrice` and `comboTotalPriceWithoutTax` getters, as we were summing the `displayPrice` of all the combo lines, including the parent line, which already had its `displayPrice` as the sum of its children. So now, we filter out the parent line in those getters before summing. Forward-Port-Of: odoo/odoo#247347
This update fixes a limitation where managers needed a specific group to access their team's voip call records. By changing the access rule to the standard 'group_user' group, all managers now automatically have access, simplifying permissions and improving usability.
Original PR description
voip_hr defines a record rule that gives managers access to their subordinates' voip.call records. However, this rule is linked to the group 'hr.group_hr_user', which is not granted to all managers. This commit links the rule to the base.group_user group instead, so that all managers can access their subordinates' records without the need for an additional group. [Task-5363640](https://www.odoo.com/odoo/project/5778/tasks/5363640). Forward-Port-Of: odoo/enterprise#100691
This update corrects a previous issue where users lacking sufficient permissions to modify company settings would encounter an error when sending follow-up reports via snail mail. The fix allows for necessary changes to be made with elevated privileges, ensuring reports can be sent reliably for all users. This improves the overall functionality of the snail mail module.
Original PR description
Issue: Before this commit, when sending a follow up report by post, an access error is thrown if the user doesn't have enough access to modify the res.company model Fix: modifying the external_report_layout_id as sudo opw-5482855 Forward-Port-Of: odoo/odoo#248677