Daily updates from Odoo
Tuesday, June 30, 2026
33 changes · saas-19.3
Resolved issues and error corrections
This change prevents an error that could appear when users add properties to certain records, such as project tasks. The system now waits for the needed data to finish loading before showing the properties screen, so the action completes reliably instead of failing.
Original PR description
Description of the issue/feature this PR addresses: This error occurs when a model has properties and a `computed` field or `onchange` method depends on them. `record.update()` is asynchronous. When…
Description of the issue/feature this PR addresses: This error occurs when a model has properties and a `computed` field or `onchange` method depends on them. `record.update()` is asynchronous. When an onchange or computed field is triggered, an additional request is sent to the server, increasing the time required to complete the update. See: https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/model/relational_model/record.js#L1207-L1211 However, `PropertiesField` is rendered before the `update` is completed. See: https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/views/fields/properties/properties_field.js#L86 As a result, the property labels are not yet available and the following traceback is raised: `TypeError: Cannot read properties of undefined (reading 'getRootNode') ` After this commit, the update is awaited before rendering PropertiesField, ensuring that the property labels are available. **Steps to reproduce:** 1. Install the example module. [project_task_property.zip](https://github.com/user-attachments/files/29138424/project_task_property.zip) 2. Open or create a project task. 3. From the Action menu, click `Add Properties`. The error is raised. <img width="1520" height="956" alt="image" src="https://github.com/user-attachments/assets/a3051ddf-5af0-4d3a-8ff7-c3fb4f7a69d2" /> TT63331 @Tecnativa @pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272653 Forward-Port-Of: odoo/odoo#271082
A point-of-sale sales test was moved to the module that now contains the related stock logic. This prevents the automated build from failing and keeps the test aligned with the right feature set.
Original PR description
The test uses `pos_order.picking_ids`, but on saas-19.3 `picking_ids` moved to the `pos_stock` module. `pos_sale` does not depend on `pos_stock`, so the test fails there with AttributeError. Move it to `pos_sale_stock`, which depends on `pos_stock`. Fixing https://runbot.odoo.com/odoo/runbot.build.error/938839
Planning now correctly finds employees by skill even when they do not have a scheduled slot in the selected time range. This prevents missing qualified people from search results and makes staffing searches more reliable.
Original PR description
Issue: ---------------------------------------- Doing a search on skills, the employees with the skill but no slot in the time frame aren't shown. Steps to reproduce:…
Issue:
----------------------------------------
Doing a search on skills, the employees with the skill but no slot in the time frame aren't shown.
Steps to reproduce:
----------------------------------------
- Install `planning_hr_skills`
- Make sure an employee has the skill "English" and no slots
- Open Planning and type "English" in the search bar, click to search on Skills
- The employee does not show up
Cause:
----------------------------------------
Using the search view on skills, a filter on `resource_ids` is in the domain with a `OR`:
https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/views/planning_slot_views.xml#L9
Then a new filter on `resource_ids` is added [here](https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/models/planning_slot.py#L14-L43) to do the search on the skill names: `[('resource_ids', 'in', matching_resource_ids)]`.
The domain is then something like this:
`['&', ('resource_ids', 'in', matching_resource_ids), '|', ('resource_ids', '=', False), ('employee_skill_ids', 'ilike', 'English')]`.
Since fbf8b2ac67c71ca0abfc75df543069696bd2d29b the resulting domain passes through `filter_map_domain()`. `filter_map_domain()` will only keep the leaves on `resource_ids` and the default `AND` will be used between them resulting in:
`['&', ('resource_ids', 'in', matching_resource_ids), ('resource_ids', '=', False)]`
which fetches no resources.
So `_group_expand_resource_ids()` doesn't expand.
Solution:
----------------------------------------
Instead of adding the new leaf to retrieve the resources with the right skills, we replace the leaf on `employee_skill_ids`. This ensures the `OR` operations are kept by `filter_map_domain()`.
opw-6296755
Forward-Port-Of: odoo/enterprise#120669This fix corrects a rounding issue when importing vendor bills from XML and matching them to purchase orders. In some cases, quantities were imported with tiny precision errors that caused a small overstatement in the invoiced amount, which could affect invoice totals and reconciliation.
Original PR description
When importing an XML bill and linkin git to a purcahse order, the invoiced quantity may be computed incorrectly, due to a decimal precision mismatch. Steps to reproduce: - Import an XML bill having a line with quantity 1800.0 - Link to a purchase order with the same line Issue: The invoiced quantity will be computed with 1 cent difference (1800.01) Analysis: Because the system forced a decimal precision of 13 for 'Product Unit of Measure', quantity is imported as 1800.0000000000016. Later, when computing the invoiced quantity, the system round the quantity using 'UP' strategy, rounding the amount to 1800.01 opw-6194824 Forward-Port-Of: odoo/odoo#270916 Forward-Port-Of: odoo/odoo#266283
This change fixes the “undo reconciliation” action so it can reset a reconciled line without being blocked by extra checks. It makes the undo process work more reliably for users who need to reverse a reconciliation.
Original PR description
When undoing the reconciliation from the "undo reconciliation" button. We want to bypass all the checks to be able to reset the line. no task id Forward-Port-Of: odoo/enterprise#121611
This update prevents the Intrastat report from failing when a company has no country set. It corrects how the report query handles that missing value so the report can still run normally.
Original PR description
When there is no `country_id` on the company we get `False`. The generated query then fail at: ``` ... CASE WHEN (code.country_id IS NULL OR code.country_id = false) THEN code.code ELSE NULL END AS commodity_code, ... ``` with: ``` ERROR: operator does not exist: integer = boolean LINE 12: ... WHEN (code.country_id IS NULL OR code.country_id = false) T... ``` Forward-Port-Of: odoo/enterprise#121798 Forward-Port-Of: odoo/enterprise#121608
This fix ensures Quality alerts can be created from incoming emails even when the team’s company is not set. It also adds a clear validation error for missing company information and keeps email alias defaults in sync when the company changes, preventing failed imports.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#120924 Forward-Port-Of: odoo/enterprise#109947
The Planning / Timesheets Analysis report now correctly includes planning slots when an employee uses a duration-based calendar. This fixes missing entries in reports so teams get accurate planning and timesheet analysis.
Original PR description
Issue: ---------------------------------------- The Planning / Timesheets Analysis report doesn't include most of the planning slots if they have a calendar based on duration. Steps to reproduce:…
Issue: ---------------------------------------- The Planning / Timesheets Analysis report doesn't include most of the planning slots if they have a calendar based on duration. Steps to reproduce: ---------------------------------------- - Have a 1 day planning slot (8h-17h) for an employee with a calendar based on duration. - Planning > Reporting > Planning / Timesheets Analysis - The slot is not included in the report Cause: ---------------------------------------- The update of how calendars work in saas-19.2 included the `duration_based` option but the query was not adapted. It still checks if the slot start time is lower than the calendar end time on that day: ```sql F.start_datetime < (d.date::date + (A.hour_to || ' hour')::interval) AND F.end_datetime > (d.date::date + (A.hour_from || ' hour')::interval) ``` But for duration-based calendars `hour_from` and `hour_to` are stored as `0.0`. So `F.start_datetime < (d.date::date + (A.hour_to || ' hour')::interval)` evaluates to False. Solution: ---------------------------------------- If the calendar has `duration_based` to True we only check the date. opw-6217643 Forward-Port-Of: odoo/enterprise#118133
This change adjusts a point of sale test so it uses a single, compatible setup instead of mixing data from different company contexts. It helps prevent test failures in multi-company environments and makes the test suite more reliable.
Original PR description
Making the test only depend on one class setup to avoid potential (already present) multicompany issues. In this case the env.user came from one setup class but was incompatible to use during the setup of the second class that was creating records for another company. By making the test only depend on one of the tests we'll avoid this issue. runbot-939375 Forward-Port-Of: odoo/odoo#268819
This update fixes several issues in the Viva payment integration so receipts and preparation prints are processed correctly after payment. It also ensures the Viva confirmation popup appears in fast payment flows and clears saved popup answers when a user changes their choice, reducing mistakes at checkout.
Original PR description
[FIX] point_of_sale, pos_viva_com: automatic receipt printing 3 Fixes for the app-to-app integration of Viva 1. Under the normal flow the `OrderPaymentValidation` does the payment validation and post…
[FIX] point_of_sale, pos_viva_com: automatic receipt printing 3 Fixes for the app-to-app integration of Viva 1. Under the normal flow the `OrderPaymentValidation` does the payment validation and post validation operations (such as receipt printing or preparation prints). Then it launches the `FeedbackScreen` with the validation promise on the `waitFor` prop. The `pos_viva_com` app-2-app integration does the payment validation on the backend on the callback endpoint. Then it redirects the user directly on the `FeedbackScreen` skipping the normal validation and post validation operations. This means that receipts and preparation prints do not get processed. This PR adds a check on the `FeedbackScreen` to see whether there is anything set on the `waitFor` prop. If the prop is undefined, we can expect that the screen was mounted outside the normal flow, so we run the post validation operations manually. --- 2. Using the fast payment method with Viva would use `order.addPaymentLine` instead of the overloaded `payment_screen.addNewPaymentLine`. So the integration pop up which is defined in the `payment_screen` would never fire. Now I've added a check on `validateOrder` to detect whether we're about to use a `fastPaymentMethod`, in which case it will apply the same behaviour as the override of the `payment_screen.addNewPaymentLine` --- 3. Added a patch for `reloadData` which will remove the answer for the Viva wallet pop up from local storage in case users change their minds or made a mistake Task-[6251297](https://www.odoo.com/odoo/project/1737/tasks/6251297) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267714
This fix ensures the company address appears properly on PDF invoices for the Colombian Folder and Wave layouts. It also preserves the invoice title placement so it is not hidden by the QR code, improving the readability and completeness of invoices sent to DIAN.
Original PR description
Issue: On Wave and Folder layout, the address of the company doesn't appear on invoices. Steps to reproduce: - In a Colombian company, - Set company layout to Folder - Add a long tag line, - Create an invoice, - Send it to DIAN - Export to PDF Current behavior: - Company address is missing in the header Cause: Tag line + logo and address take 100% of the display width. However, loca add a QR code on the left, so it takes QR Code + 100% width. Therefore, address was out of the PDF. Moreover, for Folder layout, some resizing was done and as soon as there was a tag_line, the `rem` was downsized, allowing the invoice title: "Factura Electrónica de Venta SETP/*\*\*/\*\*\*\*" to be displayed entirely. The fix of the previous issue stopped the resizing, then the invoice title got overridden by the QR Code (same as without tag_line before this fix). opw-6239030 Forward-Port-Of: odoo/enterprise#119678
This change prevents a contact from triggering an access error when users switch between companies in a multi-company environment. It ensures meeting information is computed only for records the user is allowed to see, so contact lists and kanban views open normally.
Original PR description
### Steps to reproduce: - Download Calendar and Contacts app - Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies - Go to the Setting -> Users -> Manage…
### Steps to reproduce: - Download Calendar and Contacts app - Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies - Go to the Setting -> Users -> Manage users; make sure the current logged-in user has access to both companies - Create a another user who also have access to both companies - Search for the new user in contacts -> Assign the current company to the contact -> Through the internal link of the company, go to sales and purchase tab -> assign the same company in the company field - Switch the company of the logged in user to the other company - Open the test contact form, use the meeting smart button and create a new meeting - Open the kanban contact view **> Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.** ### Cause of Issue: When trying to view the search results in kanban view, the `meeting_count` is calculated for each contact. Hence,`_compute_meeting_count()` is called which calls `_compute_meeting()`. https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/calendar/models/res_partner.py#L49-L54 Since the above section tries to access `partner.parent_id` each loop, it reaches a `parent_id` that's not accessible for the current user. ### Fix: Since we need to access `parent_id` to be able to calculate meeting count for the full tree of partners, `sudo()` is used to get all partners, but meetings are computed for ancestors who are in `self_ids` only so that we still remain within scope. Same old logic is used to propagate meetings for every ancestor, but dictionary lookups are used to enhance performance. opw-5874204 Forward-Port-Of: odoo/odoo#272832 Forward-Port-Of: odoo/odoo#248985
This update corrects how half-day leave is calculated for French companies, especially when company and employee working schedules do not match. It ensures employees receive the intended leave duration and avoids incorrect reductions or extensions in edge cases.
Original PR description
**Steps to reproduce** - Use a french company with `l10n_fr_hr_holidays` installed - Change the duration type of the time off type set as the "Company Paid Time Off Type" in the French Time Off…
**Steps to reproduce** - Use a french company with `l10n_fr_hr_holidays` installed - Change the duration type of the time off type set as the "Company Paid Time Off Type" in the French Time Off Localization settings to "Half-Day" - Company Working Schedule: - Attendance on a day from 10 to 19, Day Period: Full Day - Part-time employee Working Schedule: - Attendance on the same day from 11 to 12, Day Period: Morning - Attendance on the same day from 13 to 19, Day Period: Afternoon - Create a full day time off for the part time employee on that day, using the time off type set as the "Company Paid Time Off Type" (start am, end pm) -> Excepted: time off duration is 1 day -> Actual: time off duration is 0.89 day **Change** Now that `request_unit_half` of a leave is a simple related to the `request_unit` of the leave type, it becomes important to not rely on a call to `_get_durations` using the company's calendar to compute the leave's duration, as it may not be fully accurate when the company's working hours and employee's working hours are not aligned. Continuation of 05e71eb206eb02a8d15708e6fb532a732a767d6d `_get_fr_date_from_to` is also adapted to take into account multi-day leaves ending in the morning while the employee works in the afternoon (in which case it should not be extended in case the employee doesn't work the next day). opw-6000011 Forward-Port-Of: odoo/odoo#270863 Forward-Port-Of: odoo/odoo#253059
This fix prevents the system from creating the same Belgian ‘Take out’ tax and fiscal position more than once when setting up a restaurant on a branch. It helps branch companies complete the restaurant setup successfully by reusing the existing accounting settings instead of failing on duplicates.
Original PR description
When creating a restaurant with the POS scenario on a company with the Belgian accounting package, we automatically create a new 'Take out' fiscal position and a 'Take out' 6% tax. But when creating a branch for the company and using the same scenario, it will duplicate the 'Take out' fiscal position, and then fail to create because it will try to create a duplicate Tax with the same name and then odoo will complain. After the fix the scenario checks whether the fiscal position and tax already exist on the company, and if they do, it doesn't recreate them. This should let branches use the scenario and then they can use the already existing taxes and FPs. Task [link](https://www.odoo.com/odoo/project.task/5502948) Task-5502948 Forward-Port-Of: odoo/odoo#245848
This change corrects how planned working time is calculated when a slot is edited across hours outside an employee’s schedule. It prevents allocated hours and break time from becoming inaccurate after repeated changes, so planning reports stay reliable.
Original PR description
Issue: ---------------------------------------- When changing multiple times the hours of a slot to include out-of-schedule time. Steps to reproduce: ---------------------------------------- - Have…
Issue: ---------------------------------------- When changing multiple times the hours of a slot to include out-of-schedule time. Steps to reproduce: ---------------------------------------- - Have planning_field_service installed - Have an employee with a schedule from 7am to 3pm - In planning view, create a new slot for this employee from 7am to 3pm (8h) - Change the starting hour to 6am (8h + 1h of break time) - Change it back to 7am - The slot shows 7h07 of allocated hours and 53 minutes of break time Cause: ---------------------------------------- Since 8ca9faabfdf7d15883ba52da47bd8c562cf601de the compute of `allocated_percentage` is overriden in `planning_field_service`. The new compute uses `break_time` to recompute `allocated_percentage`. `break_time` is the not work time over the whole duration of the slot, including hours out of schedule. But the definition of `allocated_percentage` in `planning` is: the percentage of slot hours in schedule which are actually worked. So when changing the start to 6am `allocated_percentage` is still supposed ot be 100% because the employee is working 100% of the hours he is supposed to work considering its schedule. With the actual code `allocated_percentage` is actually computed as 8/9 = 0.88888... because it will take into account the hours out of schedule. As `allocated_percentage` is not recomputed if `allocated_hours` or `break_time` aren't modified by the user. It is then used [here](https://github.com/odoo/enterprise/blob/ae5008bdaf1b87269083f82280c7df44390129ff/planning/models/planning_slot.py#L2865-L2867) to compute the allocated_hours and the number of hours in schedule is divided base onthe percentage. Solution: ---------------------------------------- We only consider the hours in schedule to recompute `allocated_percentage`. `allocated_percentage` was used in `_onchange_break_time()` to get the previous ratio and calculate the allocated hours from which we deduct the break time. We cannot do this now so we also need to compute the working hours. ----------------------------------------- # [FIX] planning_field_service: handle input of negative break_time Issue: ---------------------------------------- When inputting negative break_time for a slot, it's possible to get a traceback. Steps to reproduce: ---------------------------------------- - Have planning_field_service installed - Have an employee with a schedule from 7am to 3pm - In planning view, create a new slot for this employee from 7am to 3pm (8h) - Input 9h of break time - Input -1h of break time - Traceback Cause: ---------------------------------------- When `slot.allocated_hours` is 0 and we input a negative value in `break_time`, the code in `_onchange_break_time()` will give `allocated_hours` the positive value of `break_time` making them opposite. Then in [`_compute_allocated_percentage()`](https://github.com/odoo/enterprise/blob/188dcc5078be7c7fee1a52f86505144d3b6309cf/planning_field_service/models/planning_slot.py#L98) we divide by their sum, which equals 0. Solution: ---------------------------------------- We compute the divider part and check if it's zero in `_compute_allocated_percentage()`. Also add a `max()` in `_onchange_break_time()` to convert the negative break time in allocated hours and resets `break_time` to zero. This ensures the same behavior as inputting negative values in `allocated_hours`. opw-6273559 Forward-Port-Of: odoo/enterprise#121168
This update adjusts the Austrian tax return dates so they match the official filing rules. It now calculates deadlines by month instead of using a fixed 15-day offset, which helps ensure VAT returns and EC sales lists are due at the correct time.
Original PR description
**[FIX] l10n_at_reports: correct Austrian return deadlines** The Austrian localization used a fixed `15 days` rule for both VAT returns and EC sales lists. This does not match the filing deadlines: the VAT return is due on the 15th day of the second following month while the EC sales list is due by the end of the following month (sources below). This fix replaces the hardcoded day offset with month-based deadline computation sources: https://www.usp.gv.at/themen/steuern-finanzen/umsatzsteuer-ueberblick/weitere-informationen-zur-umsatzsteuer/umsaetze-mit-auslandsbezug/zusammenfassende-meldung-zm.html https://www.usp.gv.at/en/themen/steuern-finanzen/umsatzsteuer-ueberblick/weitere-informationen-zur-umsatzsteuer/entstehen-der-steuerschuld-und-pflichten/umsatzsteuervoranmeldung.html opw-6147343 Forward-Port-Of: odoo/enterprise#117212 Forward-Port-Of: odoo/enterprise#116212
This change fixes a timing issue in WhatsApp channel tests where the seen status could be overwritten before the message fully loaded. As a result, the seen indicators now display reliably, reducing flaky behavior in channel conversations.
Original PR description
The "Allow SeenIndicators in WhatsApp Channels" test awaited the bus subscription so the simulated seen notification is no longer dropped, but that exposed a second race between the init RPC and the bus return. openDiscuss does not await the channel data fetch (channels_as_member), whose response carries each member seen_message_id=false. When it is applied after the _sendone seen notification, it clobbers the member back to unseen, the indicators never render, and the assertion times out. Wait for the message to render before simulating the seen notification: the thread message comes from the message fetch, which only runs once the channel (with its members) is loaded, so the seen data is guaranteed applied. This mirrors the message seen indicator tests in mail. https://runbot.odoo.com/odoo/error/242021 Forward-Port-Of: odoo/enterprise#122041
Fixed an issue where opening a shift could trigger an access error for some users when overlapping shifts existed. Users without planning administrator rights will now no longer see conflict warnings, which avoids the error and keeps shift access smooth.
Original PR description
Steps to reproduce: - Create a shift assigned to resources A and B - Create another overlapping shift assigned only to resource B - Login as resource A with internal user access only - Open the first shift Issue: An access error is raised when opening the shift. Cause: The conflict computation fetches overlapping shifts using SQL, which can return shifts that are not accessible to the current user. Solution: Return empty conflict values for users without Planning Administrator access, as conflict warnings are only available to planning managers. task-6313628 Forward-Port-Of: odoo/enterprise#121465
This fix makes the Point of Sale more resilient by safely handling unexpected or invalid input when checking whether an IP address is private. It avoids crashes in cases where the system receives a value that is not a string, helping keep the feature stable for users.
Original PR description
Add an extra guard to isPrivateIp to return false for invalid values. Otherwise it would throw a TB when the provided value is not a string. This fix already exists on 19.0-19.2 from [#256028](https://github.com/odoo/odoo/pull/256028) Task-[6295735](https://www.odoo.com/odoo/project/1737/tasks/6295735) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings the spreadsheet component up to its latest version and includes a set of small fixes and improvements. It addresses issues like color picker behavior, font display on Linux, chart rendering, and find-and-replace selection handling, helping the spreadsheet feel more reliable and consistent for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/446def9ad1 [REL] 19.3.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/446def9ad1 [REL] 19.3.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9af0bc5b97 [FIX] package: 19.3 is no longer the latest version [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9a69c22cd2 [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171) https://github.com/odoo/o-spreadsheet/commit/ae520eaad2 [FIX] sheet: add sheet tab color to custom colors [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171) https://github.com/odoo/o-spreadsheet/commit/54af665a85 [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646) https://github.com/odoo/o-spreadsheet/commit/babbc57eee [FIX] chart: zoomable chart height issue with rjsmin minification [Task: 6306092](https://www.odoo.com/odoo/2328/tasks/6306092) https://github.com/odoo/o-spreadsheet/commit/4fd1a3439e [FIX] package-lock: revert changes [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4dc969c14e [IMP] package: add runbot script [Task: 6316690](https://www.odoo.com/odoo/2328/tasks/6316690) https://github.com/odoo/o-spreadsheet/commit/be5939bcfb [FIX] Find and replace : selection after an UPDATE_CELL [Task: 4818132](https://www.odoo.com/odoo/2328/tasks/4818132) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update stops users from choosing a private task as the parent of another task. It helps keep private work items properly hidden and avoids accidental exposure through task hierarchy relationships.
Original PR description
In this commit, we ensure that private tasks can never be selected as parent tasks. task-5119141 Forward-Port-Of: odoo/odoo#272263 Forward-Port-Of: odoo/odoo#270795
The Point of Sale stock tests were updated so lot tracking is set on the product template instead of the product variant. This keeps the tests working with the current Odoo behavior and helps avoid validation errors during automated testing.
Original PR description
`tracking` is no longer writable on `product.product` on 19.3/master. Update lot-related POS tests to write it on `product.template` instead. original task: 6274744 runbot error: 940485
Financial budget lines can now use accounts classified as Other Expenses. This fixes a selection issue that prevented some valid profit-and-loss accounts from being added to budgets, making budget setup more complete and consistent.
Original PR description
Currently, accounts with the `Other Expenses` account type cannot be selected in financial budget lines. **Steps to reproduce:** - Install the `accountant` module. - Go to `Chart of Accounts` and…
Currently, accounts with the `Other Expenses` account type cannot be selected in financial budget lines. **Steps to reproduce:** - Install the `accountant` module. - Go to `Chart of Accounts` and create a new account with `Type: Other Expenses`. - Go to Accounting > Configuration > Financial Budgets. - Create a new budget and add a budget line. - Try to select the newly created account. **Observation:** Accounts with the `Other Expenses` type are not available for selection in budget lines. **Root Cause:** At [1], the `expense_other` account type is missing from the `account_id` domain. **Expected Behavior:** Financial budgets should allow all Profit & Loss accounts, since the feature relies on P&L reporting. **Reference**: https://www.odoo.com/odoo/project/49/tasks/4314709 **Fix:** This commit ensures that users can add `Other Expenses` accounts to budget lines. [1]: https://github.com/odoo/enterprise/blob/41b66ba081f3938f7e55da209506c637850ae4ec/account_reports/models/budget.py#L114-L120 opw-6313835 Forward-Port-Of: odoo/enterprise#121735
This fixes an issue where a customer's chosen delivery and billing addresses could be replaced when the cart was refreshed after checkout. The selected addresses now stay in place when they still belong to the same customer, preventing incorrect sales orders and reducing order errors.
Original PR description
Steps to reproduce: =================== 1. Add several delivery addresses & billing addresses 2. Add a product to the cart and go to checkout. 3. Select a specific delivery address and a different…
Steps to reproduce: =================== 1. Add several delivery addresses & billing addresses 2. Add a product to the cart and go to checkout. 3. Select a specific delivery address and a different invoice address. 4. Pay and click "Skip" immediately on that page. 5. Open the resulting sales order. => The delivery address is reset to the company's first delivery child instead of the one selected during checkout. Root cause: =========== `partner_shipping_id` and `partner_invoice_id` are stored computed fields (compute + store + readonly=False) that depend on `partner_id`. Any write that includes `partner_id`, even writing the same value, retriggers the compute and overwrites a manually selected address with the result of `partner_id.address_get()`. `_get_and_cache_current_cart` resurrects the customer's draft cart when it is no longer referenced in the session and re-runs `_update_address(partner, ['partner_id'])` on it to refresh the pricelist and fiscal position. Clicking "Skip" runs `sale_reset()`, which clears the session cart key while the order is still draft, so the next cart access takes that abandoned-cart branch and the redundant `partner_id` write discards the selected delivery/invoice address. Waiting a few seconds lets the order reach the 'sale' state first, so the draft search no longer matches and the address is kept, which is why the issue is timing dependent. Fix: ==== In `_update_address`, when partner_id is written, keep the delivery and invoice addresses already set on the cart if they still belong to the new partner's company (same `commercial_partner_id`) by writing them in the same `write()` so the recompute does not override them. Addresses that do not belong to the new partner are still recomputed to the partner's defaults. opw-6267188 Forward-Port-Of: odoo/odoo#270300
This update corrects the alignment of the link popover’s URL field and its icon in Notes. It ensures the input keeps the same height as its container, so the interface looks consistent even when autocomplete is available.
Original PR description
Steps to Reproduce: - open notes - type `/link` to open link popover Issue: - The url input field and its icon are misaligned. Cause: - When url autocomplete are enabled in the link popover, the input field height is reduced, causing it to become smaller than its container. This results in misalignment between the input field and the icon. Solution: - Set the link popover url input height to 100% so it always matches the height of its container, ensuring proper alignment even when autocomplete is avaialble. task-6201175
This fix prevents a crash when portal users open Knowledge articles that include author information in list items. It ensures those users can see shared article content without running into access permission errors.
Original PR description
Problem: Since saas-19.2 (99f38be260c3c5523306e4ffcb4cf18436d40568), portal users crash when opening a Knowledge article containing items with "Created by" or "Last edited by" columns. Cause: Portal…
Problem: Since saas-19.2 (99f38be260c3c5523306e4ffcb4cf18436d40568), portal users crash when opening a Knowledge article containing items with "Created by" or "Last edited by" columns. Cause: Portal users are restricted to their own res.users record. Reading create_uid and last_edition_uid of internal users raises an AccessError. This was not raised in 19.0. Specifically, the `many2one_avatar_user` field widget defines `write_date` in `relatedFields`, which forces the RPC to read the `write_date` field of the target user. Since portal users cannot read other users' records, it raises an AccessError. Solution: Only include `write_date` in the field widget's `relatedFields` if the current user is an internal user. For portal users, `relatedFields` will be empty, avoiding the AccessError. Steps to reproduce: 1. Create a Knowledge article. 2. Add an "Item list" element. 3. Add some items to the list. 4. Share the article with a portal user. 5. Open the article as the portal user. 6. Observe that only the list header is visible and the items are not displayed. opw-6199714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269479
This fix brings back the intended behavior for pages using the `s_nb_column_fixed` class, which hides the column count option in the builder. It ensures that layouts marked this way no longer show an option that should be locked, improving consistency for content editors.
Original PR description
The class 's_nb_column_fixed' was used to hide the column count option, but it got lost during the refactoring and doesn't work since 18.4. This commit restores it. task-6234267 Forward-Port-Of: odoo/odoo#271975 Forward-Port-Of: odoo/odoo#268005
This fix keeps overtime durations more accurate when they are recorded for payroll calculations. It prevents small rounding errors from affecting the amount paid for overtime work.
Original PR description
Overtime duration computed as fractional hours was rounded to 3 decimal places before being stored on the overtime line. Since 1 decimal hour = 3600 seconds, this gives only 3.6 seconds of precision and the rounding can go in the wrong direction due to floating-point representation. The fix consists in replacing the duration rounding to 4 decimals when building overtime work entries so stored durations keep sub-second precision needed for money computation. task-6212231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270417 Forward-Port-Of: odoo/odoo#268889
Overtime hours are now stored with more precise decimal values, so small time differences are not lost before payroll calculations. This helps ensure overtime pay is computed more accurately and consistently.
Original PR description
Overtime duration computed as fractional hours was rounded to 3 decimal places before being stored on the overtime line. Since 1 decimal hour = 3600 seconds, this gives only 3.6 seconds of precision and the rounding can go in the wrong direction due to floating-point representation. The fix consists in replacing the duration rounding to 4 decimals when building overtime work entries so stored durations keep sub-second precision needed for money computation. task-6212231 Forward-Port-Of: odoo/enterprise#120786 Forward-Port-Of: odoo/enterprise#119721
This update corrects how the Peru address fields are linked in the website checkout form. It prevents an error that could stop customers from completing checkout after upgrading, ensuring the page loads correctly again.
Original PR description
Issue: ------ `l10n_pe.address_form_fields` inherits from `portal.address_form_fields` but targets a `<div>` element that has been moved to `portal_address_extended.address_extended_form_fields` in…
Issue:
------
`l10n_pe.address_form_fields` inherits from `portal.address_form_fields` but targets a `<div>` element that has been moved to `portal_address_extended.address_extended_form_fields` in [saas~19.2].
Traceback:
----------
```py
Error while rendering the template:
ValueError: Element '<div id="div_city_id">' cannot be located in parent view (view: l10n_pe.address_form_fields)
Template: website_sale.address
Reference: 1973
Path: /t/t/div/div/form/div/t
Element: <t t-call="website_sale.address_form_fields"/>
```
Steps to reproduce:
-------------------
1. Install `l10n_pe` and `website` in v19
2. Upgrade to v19.2
3. Go to the website and add a product to the cart
4. Go to checkout → Traceback
Root cause:
-----------
The view is adapting an element owned by a sibling view, making the inheritance hierarchy conceptually wrong and fragile.
Solution:
---------
Update the `inherit_id` of `l10n_pe.address_form_fields` to `portal_address_extended.address_extended_form_fields` so it correctly inherits from the view that owns the targeted element.
opw: [6302145]
[saas~19.2]: https://github.com/odoo/odoo/commit/026c6f9f2a388ee509a135c53e38f5bb3d08ff73#diff-83bb066f4477532b76aadd957ae736d0c0b67bc66b48d6f47c035e8cfb4773deR7-R21
[6302145]: https://www.odoo.com/odoo/70/tasks/6302145?debug=1
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#271246This fix prevents cost-of-goods-sold entries from being treated like regular tax base lines when bills are confirmed. As a result, manually adjusted taxes on vendor bills are no longer overwritten during the accounting update, reducing unexpected changes for users.
Original PR description
## Description of the issue/feature this PR addresses: Setup plus video 1. Go to settings, enable "Automatic Valuation" and "Storeable Locations". 2. Navigate to Product Categories. 3. Create a new…
## Description of the issue/feature this PR addresses: Setup plus video 1. Go to settings, enable "Automatic Valuation" and "Storeable Locations". 2. Navigate to Product Categories. 3. Create a new product category with the costing method Standard Price and the inventory valuation Automatic. 4. Navigate to Products, click into any product. 5. Add the new product category to this product under General Information. 6. Add any tax in the purchase tax field. 7. In the Accounting tab of the product, add any account to the Price Difference Account field. https://drive.google.com/file/d/1i2DHEt0g9G5Edad_QB3QaFkOT49cbMAZ/view?usp=sharing Instructions to reproduce error 1. Navigate to Purchase. 2. Add a customer, then add the configured product. 3. Add a tax to the line. Ensure that the tax and price_unit are nonzero. 4. Confirm the order. 5. Receive the product. 6. Create the bill. 7. Edit the tax on the vendor bill, then save the changes. Notice that the changes are kept. 8. Select Confirm. Notice that the changes to the tax line are not kept, and that the COGS lines appeared (with taxes applied to them). 9. Reset the bill to draft. 10. Click into the configured product and remove the product category. 11. Repeat steps 7-8 . No COGS lines, and the tax line is the manually set value. ## Current behavior before PR: COGS lines with taxes have no net effect on any tax lines as they cancel each other out. However, their creation triggers the recalculation of all tax lines, undoing any manual adjustments to tax lines. ## Desired behavior after PR is merged: This commit ensures that COGS lines are not considered base tax lines, so that their creation does not trigger the recalculation of other base tax lines. opw-5387248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271262 Forward-Port-Of: odoo/odoo#262442
This update makes the public chat test flow more reliable by ensuring the attachment menu closes before the message is sent. It also corrects a test setup issue so the right conversation data is updated between runs, helping prevent flaky failures during automated testing.
Original PR description
Attempt at fixing the following race condition. It's not clear what causes it, but these changes make the test more robust and might help future investigations. discuss_channel_public_tour opens the composer "More Actions" menu to attach files but feeds the hidden file input directly, so the menu is never closed and is still open when Send is clicked. Close it and wait for it to disappear before sending, to avoid clicking Send while the dropdown is dismissing. Also fix _open_group_page_as_user, which updated the last message body of self.channel instead of self.group between the two tour runs. https://runbot.odoo.com/odoo/error/243436 Forward-Port-Of: odoo/odoo#272606 Forward-Port-Of: odoo/odoo#272425
This change prevents Romanian-specific stock batch behavior from being applied in situations where it should not be. It fixes an error that affected automated system checks and helps keep the stock workflow stable.
Original PR description
The Romanian specifics were applied without condition which caused runbot errors. Note that this was revealed later on (saas-19.3) after a change in the generic stock test setup. runbot-241098 Forward-Port-Of: odoo/odoo#271985