Daily updates from Odoo
Wednesday, October 8, 2025
263 changes
10 changes
Enhancements to existing features
When an employee signs a Belgian salary package contract, selected company car details are now reliably recorded in the employee activity history even when the contract version was already prepared. Offer summaries also show the selected car and bike names, making package details clearer for HR and employees.
Original PR description
As when signing the employee contract, the version related to that contract is already created and we just set the version active, the value of the car does not change, so the tracking is not triggered and it's not added into the chatter. This PR force the car_id and ordered_car_id to be tracked by adding the initial value the employee precommit tracking values, before the version is activated (so before the employee get the new values from the newly active version). Also, this PR adds the selected car and bike names to the offer summary. Task-4962922
Resolved issues and error corrections
The update ensures page components finish loading before edit-mode change tracking resumes. This prevents pages such as the login screen from being incorrectly marked as modified, reducing confusion for website editors.
Original PR description
*web, website Before this commit, `PublicComponentInteraction` was not awaiting the mounting of Owl components. Consequently, the DOM mutations generated by the components were not always ignored. After this commit, the mounting is awaited before restarting the mutation listener. ** HOW TO REPRODUCE THE PROBLEM ** One case were the problem is evident is the `/web/login` page. 1. Navigate to `/web/login` 2. Enter edit mode 3. Inspect the page searching for `o_dirty` 4. The page is already dirty. This happened because of `UserSwitch` not being awaited.
The stock quantities list now highlights only products that actually have an overdue removal date. This prevents regular products from being incorrectly shown in red for stock users, making the list easier to read and reducing confusion.
Original PR description
Description of the issue/feature this PR addresses: For stock users (not admins), the stock quantities list view display red lines for every product. Current behavior before PR: <img width="2243" height="217" alt="image" src="https://github.com/user-attachments/assets/330c591c-6ef4-46cb-8336-fa39fb483333" /> Desired behavior after PR is merged: Red lines are only displayed for products with a removal date and a removal date < current date <img width="2241" height="290" alt="image" src="https://github.com/user-attachments/assets/fe37adc7-e736-447e-a21e-e2fae984e074" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228992
This update fixes a backend issue where certain request parameter names could conflict with core remote call fields. It helps ensure affected Odoo web requests are handled reliably without disrupting normal business workflows.
Original PR description
Backport 1bb69de64165b18fca7d00164c5299e58c48d40f > 44:18.716 INFO o.t.result: 0 failed, 0 error(s) of 12 tests when loading database 'odoo-backport-json2-name-collison'
This update adjusts how AI-related functions are called so they are easier to customize and better aligned with newer versions. It is an internal reliability fix with no expected direct impact on day-to-day users.
Original PR description
To ease the override and compatibility with what is done in 19.0, we call the function with kwargs instead of args. Forward-Port-Of: odoo/enterprise#96528
This fixes a problem where Google address suggestions could fail during eCommerce checkout if Google returned address details in an unexpected order. The autocomplete now chooses recognized address information first and better handles regional city formats, reducing checkout address entry errors.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I…
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I haven't been able to reproduce it myself, but others have. > It appears that the order Google provides place types isn't always the same. Issue ----- You may get a `KeyError`, trying to fetch `standard_data['country']`. Cause ----- The fields get sorted by type, and we try to sort `country` before `state`, so that the `country` key should be present when we get to `state`. The likely issue is that Google often provides multiple types per field, and we only keep the first one, assuming it to be the most relevant one, but the API documentation makes no guarantees about the array's order[^1]. For example, if a field were to have `political` in front of `country`, we would keep the `political` type, only to ignore it later on, as we have no mapping for it. [^1]: https://developers.google.com/maps/documentation/places/web-service/place-types#address-types Solution -------- 1. Iterate over the types, and get the first one that's part of `FIELDS_MAPPING` 2. Before searching for a `state`, ensure `country` has already been set, otherwise log a warning. 3. Extra: add `postal_town` as a type, which gets used instead of `locality` in some countries like Sweden. opw-4880651 Forward-Port-Of: odoo/odoo#230134 Forward-Port-Of: odoo/odoo#217171
This fix prevents valid accented characters, such as ü, from being removed from legal names used in Mexican electronic invoicing. It helps ensure company names match official SAT records and reduces the risk of rejected or incorrect documents.
Original PR description
Previous commit (#95207) removed accents for names including character ü which indeed is a recognized character for SAT opw-5125107 Forward-Port-Of: odoo/enterprise#96043
Loyalty discounts and coupons now use a consistent date check during checkout and payment confirmation, preventing valid orders from failing because of timezone differences. Expired coupons are also removed from orders at the right time, so payment totals stay accurate and customers are not charged incorrectly.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California…
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California before 7:00 UTC; 4. add the product to your cart; 5. go to checkout; 6. pay for the order. Issue ----- Order cannot be confirmed due to incomplete payment. Cause ----- The `_frontend_pre_dispatch` method of `website` adds a timezone value to the context based on the request's `geoip`. This context value then gets used to find applicable loyalty programs via `Date.context_today`, and applies them to the order. Then after payment was initiated, the order gets validated again using server time (UTC), which now considers the applied program expired, and removes the reward before confirming the order. Consequently, with the discount removed, the paid amount no longer matches the order total, thus the order remains unconfirmed. Solution -------- If the order has a confirmed transaction, use its `create_date` to verify loyalty expiration dates. For time zone, instead of `Date.context_today`, using whatever `tz` value is in the context, use a helper function which retrieves the current day in the company's timezone. For website orders, if defined, use the eCommerce salesperson's time zone instead. Also fix an issue where expired coupon lines weren't getting removed from the order. opw-4765873 opw-4781346 opw-4939268 Forward-Port-Of: odoo/odoo#229749 Forward-Port-Of: odoo/odoo#222428
This fixes an issue where computing taxes on an invoice could fail when no tax was found for a customer's ZIP code. The system now handles the missing tax details safely, helping users complete invoice tax calculations without interruption.
Original PR description
Currently, an error occurs when computing taxes for an invoice. **Error:** `KeyError: 'manual_tax_amounts'` **Cause:** When a user clicks the `Compute Tax` button, the system calculates the tax for…
Currently, an error occurs when computing taxes for an invoice.
**Error:**
`KeyError: 'manual_tax_amounts'`
**Cause:**
When a user clicks the `Compute Tax` button, the system calculates the tax for that invoice, including the `manual_tax_amount` [1]. However, if no tax is found for a given customer ZIP code, the `tax_values_list` becomes empty [2]. As a result, `manual_tax_amounts` in the base line also becomes empty.
Later, when the system tries to fetch the `manual_tax_amounts` key from extra_tax_data, it raises a KeyError [2], because the key no longer exists.
Additionally, the condition in [3] indicates that there is no guarantee that the `manual_tax_amounts` key will always be present in the base_line.
**FIX:**
This commit ensures that if the manual_tax_amounts key does not exist, an empty dictionary {} is used instead. This prevents the KeyError from occurring during tax computation.
[1]- https://github.com/odoo/enterprise/blob/b17b6b4e5ca3085d831fc763457496b5c5b639c5/account_external_tax/models/account_external_tax_mixin.py#L155-L163
[2]- https://github.com/odoo/enterprise/blob/a51aee8f6e8bce2aa699d3199d6723495464a762/account_external_tax/models/account_external_tax_mixin.py#L88
[3]- https://github.com/odoo/odoo/blob/241c170dbece8c1652db9ca1aa935b2106ede532/addons/account/models/account_tax.py#L1330
sentry-6919182805Fixed an issue that blocked users from editing properties on several demo job offers in the Recruitment app. These demo jobs now correctly use the current company, preventing the warning and allowing configuration changes as expected.
Original PR description
Steps to reproduce: - Go to the Recruitment app - Open the configuration panel for the demo offer for CTO, Consultant, Experienced Developer or Human Resources Manager - Click on the cogwheel - Select "Edit properties" - A warning appears and you can't edit properties Reason: The definition of the job demo data sets the "company_id" field to False, which causes an error when you try to edit the properties. How it was fixed: By removing the explicit value of False for the field "company_id", it will auto assign the field to the current company and allow the properties to be edited correctly. Task ID: 5093032
14 changes
Resolved issues and error corrections
Fixed an issue where products tracked by serial number could incorrectly pass a quality check after the user marked it as failed during receipt processing. This helps ensure failed items are correctly identified and handled, reducing the risk of defective stock being accepted.
Original PR description
Serial number tracked product are marked as pass even when they fail a move_line type of check. ### Steps to reproduce: * Create a product tracked by serial number * For this product create a control…
Serial number tracked product are marked as pass even when they fail a move_line type of check. ### Steps to reproduce: * Create a product tracked by serial number * For this product create a control point: - Control per quantity - Operations : Receipts * Create a receipt for this product * Mark the receipt as Todo * Start the Quality check from the receipt, without using the smart button. * Fail the Quality check * The Quality check still passes ### Issue: When validating a quality check and it fails: https://github.com/odoo/enterprise/blob/d48228127c239e45938551d9bbac734afab8b31a/quality_control/wizard/quality_check_wizard.py#L84-L92 I will not go through the standard process with show_faillure_message where the user can select failed_qty, it directly goes to confirme_fail>_move_to_failure_location: https://github.com/odoo/enterprise/commit/49149580d34ec5583559fa0288356fec6cb2c514#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L455-R457 In our case since failed_qty is still at 0 this new condition transfer the quality check to pass. In the case of serial numbers, the quality check is done one by one, the failed_qty can be retrived from check.move_line_id.quantity opw-5015266
This fixes an issue in the Turkish Nilvera integration where some server errors could fail to display correctly because the system referenced the wrong response field. Businesses using this integration should now receive the intended error message instead of an unexpected failure.
Original PR description
The http response object doesn't have a `code` attribute, this commit fixes this typo which has already been fixed in 19.0 as a part of #222869 task-5050516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228088
Fixes bank reconciliation screens so filtered statement lines expand correctly, summaries reappear when filters are cleared, and irrelevant buttons are hidden. It also prevents errors when opening the general ledger from reconciliation by using the correct journal context.
Original PR description
When you open a statement line from a reconciled move, it opens the bank reconciliation widget with only the selected statement line, which is unfolded by default. However, there are a few issues with this behavior, which are fixed in this commit: 1 - When entering the bank reconciliation widget, the initial line is unfolded. If you remove the filter, all the other lines become unfolded as well. This should not be the case; only the original line should remain unfolded. 2 - By default, the statement summary line is hidden. When the filter is removed, the summary remains hidden. We now ensure the summary is displayed again when the filter is cleared. 3 - The Statement button on the statement line (which is meant to create a new statement) doesn't make any sense when there is only one line. It is now hidden in this case. task-5108118
The AI assistant now includes planned activities and chatter content when preparing context for HTML field suggestions. This helps generated responses better reflect the latest follow-ups, tasks, and conversation history on the record.
Original PR description
Append any planned activities to the chatter messages to be sent as a part of the prompt's context with the rest of the messages. task-id-5079055
The checkout address autocomplete now better handles Google address results when Google returns address labels in an unexpected order. This helps prevent checkout errors and improves address completion for locations where city information may be provided differently, such as Sweden.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I…
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I haven't been able to reproduce it myself, but others have. > It appears that the order Google provides place types isn't always the same. Issue ----- You may get a `KeyError`, trying to fetch `standard_data['country']`. Cause ----- The fields get sorted by type, and we try to sort `country` before `state`, so that the `country` key should be present when we get to `state`. The likely issue is that Google often provides multiple types per field, and we only keep the first one, assuming it to be the most relevant one, but the API documentation makes no guarantees about the array's order[^1]. For example, if a field were to have `political` in front of `country`, we would keep the `political` type, only to ignore it later on, as we have no mapping for it. [^1]: https://developers.google.com/maps/documentation/places/web-service/place-types#address-types Solution -------- 1. Iterate over the types, and get the first one that's part of `FIELDS_MAPPING` 2. Before searching for a `state`, ensure `country` has already been set, otherwise log a warning. 3. Extra: add `postal_town` as a type, which gets used instead of `locality` in some countries like Sweden. opw-4880651 Forward-Port-Of: odoo/odoo#230134 Forward-Port-Of: odoo/odoo#217171
Stock quantity lines are no longer incorrectly highlighted in red for every product for regular stock users. The warning color now appears only when a product has an expired removal date, making the list clearer and helping users focus on items that need attention.
Original PR description
Description of the issue/feature this PR addresses: For stock users (not admins), the stock quantities list view display red lines for every product. Current behavior before PR: <img width="2243" height="217" alt="image" src="https://github.com/user-attachments/assets/330c591c-6ef4-46cb-8336-fa39fb483333" /> Desired behavior after PR is merged: Red lines are only displayed for products with a removal date and a removal date < current date <img width="2241" height="290" alt="image" src="https://github.com/user-attachments/assets/fe37adc7-e736-447e-a21e-e2fae984e074" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228992
Group headers in the Gantt view now keep their sticky behavior even when timelines are wider than the screen. This improves usability, especially on mobile devices, by keeping context visible while users scroll.
Original PR description
Gantt group headers could stop being sticky because their width was fixed based on the number and size of columns. Even though they were set to position: sticky, oversized headers could no longer remain aligned when scrolling, as they extended beyond the viewport and were constrained by the document width. This was especially noticeable on mobile, where group headers are often wider than the screen. The fix applies a max-width style to these headers, capping their size to the available space so they remain sticky without overflowing the document. task-4970992 Forward-Port-Of: odoo/enterprise#96425 Forward-Port-Of: odoo/enterprise#96015
Subcontracted manufacturing orders can no longer be unbuilt, preventing accounting entries from being created with missing balancing lines. This avoids inaccurate stock valuation and accounting records for subcontracting flows that are not intended to support unbuild operations.
Original PR description
**Problem:** unbuilding a Manufactring order created through a subcontracting process gives the wrong account move lines **Steps to reproduce:** - create a storable product (the comp) and set a cost…
**Problem:** unbuilding a Manufactring order created through a subcontracting process gives the wrong account move lines **Steps to reproduce:** - create a storable product (the comp) and set a cost - create a storable product (the final product), set a cost and set a vendor - for the final product set the category as avco and automated - for the final product create a bill of materials subcontracted and set the same vendor - for the components add the comp for a quantity of 1 - create a Purchase order for the final product and the same vendor and confirm - validate the receipt - From the receipt click on the valuation smart button and click on the book widget of the line of the final product - notice how there is 3 journal items line including one crediting "stock interim (Received)" - unarchive the operation type "subcontracting" - open Manufacturing/Manufacturing Orders, delete the "to do" filter and search for a Manufacturing order with your final product - unbuild it - Open accounting/journal entries and select the journal entry for the unbuild **Current behavior:** There is only two account lines. There is no line balancing the "Stock Interim" line of the manufacturing order. **Cause of the issue:** The override of _generate_valuation_lines_data in mrp_subcontracted_account adds the stock interim line on the manufacturing order. However when unbuilding, the qty is negative so we exit the function https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/mrp_subcontracting_account/models/stock_move.py#L20 **fix** Because subcontracted Manufacturing orders are not meant to be unbuilt, we prevent it opw-4998137 Forward-Port-Of: odoo/odoo#230062
The Belgian salary configurator now shows gross salary only when the active company is Belgian. This prevents incorrect payroll values from being used in other company contexts and helps HR teams see the expected salary information during contract setup.
Original PR description
Gross Salary did not appear previously as the extending function _get_compute_results in 10n_be_hr_contract_salary was returning the l10n_be_wage_with_mobility_budget right away without checking which company we are in. This change made sure before proceeding that we are in the correct active company, Belgian one in our case. task-4987491
The employee private address section now keeps city, state, and ZIP fields aligned on the same row. This improves readability and makes the employee form look cleaner and more consistent.
Original PR description
Wrap private address city, state, and zip fields in a flexbox container to ensure proper horizontal alignment on the employee form view. task-5082714
This update fixes the layout of private address details on the employee form. City, state, and ZIP code now line up horizontally, making the form easier to read and use.
Original PR description
Wrap private address city, state, and zip fields in a flexbox container to ensure proper horizontal alignment on the employee form view. task-5082714
This update ensures the correct domestic tax setup is selected for companies in the UAE, Mexico, Cambodia, and Italy. It improves tax accuracy by ordering fiscal positions properly, dynamically prioritizing the UAE position based on company location, and removing a duplicate Italian setup.
Original PR description
Since the fiscal position sequence is used to determin the domestic fiscal position, and hence, the domestic taxes - it is important to properly sequence the fiscal positions. This commit fixes the following localizations: **AE** Sequences are added making Dubai the domestic fiscal position. However this needs to be improved to automatically prioritize the fiscal position based on the company's state. **IT** (l10n_it_edi_doi) An additional domestic fiscal position was mistakenly added. The correct domestic FP is defined in it's dependency module l10n_it. The duplicate FP is removed. **MX** Sequences are added **KH** Sequences are added No Task - l10n's identified by the fiscal position checks in `test_all_l10n` 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
The time off request summary card now formats hour-based leave values more clearly. This prevents overly long text in the side panel, making requests easier for employees and managers to review.
Original PR description
On a time off request, there is a summary on the side. Problem: if we have time off in hours, the display is not adapted and the text is too long. This commit fixes the issue to display the hours correctly. task-5092855 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
Fixes the display of time off warning messages so they appear consistently when employees create leave requests, including the India-specific sandwich leave alert. This reduces confusion by ensuring important alerts are visible in the right place with proper spacing.
Original PR description
Issue: The sandwich leave alert for l10n India was incorrectly shown folded when creating a new time off entry for Indian companies. Additionally, the leave_type_increases_duration alert lacked proper top margin, causing inconsistent spacing. Steps to Reproduce: - For the sandwich alert: When shown, it appears folded automatically when creating a new time off entry (only for Indian companies). - For leave_type_increases_duration: When displayed, it lacks top margin. Fixes: - Moved the sandwich leave alert to the header alongside other alerts for consistency. - Adapted margins for all alerts. Task ID: 5071899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
Public and portal users can now print or export Knowledge articles without seeing blank pages or broken formatting. This improves access to shared documentation and ensures external users receive readable article exports.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing CSS rules (Public View)** The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode. ### Fix This PR fixes problems 2, 3 and 4 by: * Removing the unused/irrelevant planning print styles * Ensuring `web.assets_web_print` is loaded in portal * Creating a new print bundle for the frontend view * Hiding the knowledge header in the public view when printing (to improve layout) The first issue is tackled in odoo/odoo#223434 opw-4816241 Forward-Port-Of: odoo/enterprise#92665
Creating a goal from an employee's appraisal now automatically selects the employee from that appraisal instead of the current user. Creating a goal directly from the Goals menu leaves employee and manager fields empty, preventing incorrect assignments and reducing cleanup work.
Original PR description
If you go on _appraisals -> any employee -> goals smart button -> new_, it will populate the employee field with the current user. Instead, the field should be filled by the appraisal's user. If the goal is created from the "Goals" menu item directly, then no user / manager should be put by default in the goal's fields. I changed the field's default value to use the employee already passed in the context. I also added some tests to make sure the bug doesn't happen again. task-5048292
20 changes
Enhancements to existing features
When users upload XML bills from bank reconciliation, the system now automatically activates the bill currency if it was inactive. This removes a manual step, speeds up bill upload, and makes the reconciliation workflow smoother.
Original PR description
Before: - When the user uploads an XML file from the bank reconciliation widget using 'Upload Bills' button and a currency of that bill is not active, then we ask the user to activate that currency manually. - Since users know the currency of Bill at the moment, we should directly activate the currency. After: - Now we activate the currency of Bill directly if it is not active, without asking to the user. Impact: - Improves user experience by not manually activating the currency of the bill. - Save users' time when uploading Bills in the bank reconciliation line. Task-5108103 Forward-Port-Of: odoo/enterprise#95513
Resolved issues and error corrections
This change moves HR-dependent scheduling tests into the HR-specific project module so builds no longer fail when the HR app is not installed. It helps keep automated testing reliable across different installation setups without changing business functionality.
Original PR description
Steps to reproduce: - start test_auto_schedule_flex_resource when hr not installed. => `AttributeError: 'res.users' object has no attribute 'action_create_employee' Source: - action_create_employee comes from hr, but the test is in project_enterprise Fix: - tests related to hr moved to project_enterprise_hr
Outgoing stock movements split across multiple lots or serial numbers now allocate costs only to the relevant lot. This prevents overstated or distorted lot costs and gives businesses more accurate inventory valuation.
Original PR description
Description of the issue/feature this PR addresses: If "out" moves have more than one lot (i.e. two move lines for one move), then the lot cost calculations go way askew. Current behavior before PR: Lot cost calculations work by taking a subset of a stock move value, up to the quantity of just that lot. When recalcing lot cost, for "in moves" the value correctly uses a "portion" of the cost from the move. But for "out moves", it does not - assuming the FULL move is for a single lot. If multiple lots or serial numbers are on a single move, then it should apportion that too. Desired behavior after PR is merged: The out moves check the move lines for those for the specific lot, and only include a portion of the out in the calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mexican electronic invoicing now keeps valid accented characters, such as ü, in legal names. This prevents compliant customer or company names from being altered and helps avoid issues with SAT validation.
Original PR description
Previous commit (#95207) removed accents for names including character ü which indeed is a recognized character for SAT opw-5125107 Forward-Port-Of: odoo/enterprise#96043
This update adjusts an internal website performance test so it no longer fails because of small query count differences caused by optional installed add-ons. It helps keep automated testing reliable without changing customer-facing behavior.
Original PR description
The difference query is not relevant to the overall performance of the page. This difference depends on how you run the tests with the other addons installed. issue: AssertionError: 36 != 37
Saudi invoices that include section lines can now be printed without causing an error. This ensures businesses using Saudi localization can generate compliant invoice documents reliably, even when invoices are organized into sections.
Original PR description
### Issue: Printing a Saudi invoice with section lines results in a traceback. ### Steps to reproduce: - Install l10n_sa and switch to a Saudi company - Create an invoice with section lines for a Saudi partner - Click "Print" ### Cause: To compute the totals for the section lines, we try to use the field `child_ids` but it was removed in [this commit](https://github.com/odoo/odoo/commit/572680aa30d41900223f1bea36e410e5c0270b37) for performance issues. ### Solution: Use `_get_section_lines()` added by the same commit. opw-5140406
The Join and Reject buttons shown in chat calls now keep the intended pill-shaped style and no longer appear oversized. This makes call actions clearer and more consistent for users when returning to conversations with active calls.
Original PR description
Before this commit, "Join" and "Reject" call actions with label, which are shown on chat with a call for which the user has already joined a call at least once, had wrong style. This happens because:…
Before this commit, "Join" and "Reject" call actions with label, which are shown on chat with a call for which the user has already joined a call at least once, had wrong style. This happens because: 1. they use `.rounded-pill` and `.rounded-start/end-3`, and the `.rounded-3` are behaving as `rounded-0` when with `rounded-pill` 2. buttons are bigger than expected, because of `aspect-ratio: 1` The `.rounded-3` and non-intentional: the button must be pill-shaped. This commit fixes this by making the condition for `.rounded-3` more specific, i.e. not consider join-leave-call buttons that are circled and pilled. For the sizing, this comes from recent change [1] that fixed issue in Picture-in-Picture were the buttons have different size than in the browser tab. The fix made by [1] affects more buttons than expected, such as the "Join" and "Reject" buttons. More investigation is necessary to understand why buttons have different sizes in picture-in-picture, but in the meantime it's best to remove the `aspect-ratio: 1`, as the current bug is more important to fix than the sizing of picture-in-picture buttons. Task-5149688 [1]: https://github.com/odoo/odoo/pull/228657/files#diff-94618ed43461f410ce199f94861d88901c7d868045d6bfe5614e134498e856aaR37 Before <img width="174" height="132" alt="Screenshot 2025-10-07 at 14 33 12" src="https://github.com/user-attachments/assets/ed228673-7cde-45a1-91e3-2438b258373b" /> After <img width="171" height="128" alt="Screenshot 2025-10-07 at 15 50 30" src="https://github.com/user-attachments/assets/b8882714-24a7-4fea-8442-2c915a9519b9" />
Stock quantity lists now only highlight products in red when they have a removal date that is already past due. This prevents regular products from being incorrectly flagged for stock users, making the list easier to read and helping teams focus on genuinely expired items.
Original PR description
Description of the issue/feature this PR addresses: For stock users (not admins), the stock quantities list view display red lines for every product. Current behavior before PR: <img width="2243" height="217" alt="image" src="https://github.com/user-attachments/assets/330c591c-6ef4-46cb-8336-fa39fb483333" /> Desired behavior after PR is merged: Red lines are only displayed for products with a removal date and a removal date < current date <img width="2241" height="290" alt="image" src="https://github.com/user-attachments/assets/fe37adc7-e736-447e-a21e-e2fae984e074" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228992
This fix prevents scheduled inventory valuation closing from crashing when the required journal or valuation account has not been configured. Businesses get a safer process with clearer handling of incomplete settings, reducing unexpected accounting interruptions.
Original PR description
When the journal is not set in the inventory valuation settings, running the cron ``Stock Account: Inventory Valuation Closing`` results in a traceback. Steps to reproduce the error: - Install…
When the journal is not set in the inventory valuation settings, running the cron ``Stock Account: Inventory Valuation Closing`` results in a traceback. Steps to reproduce the error: - Install ``accountant`` and ``stock`` modules - Go to Settings > Inventory Valuation > Periodicity: Daily > Unset the Journal > Save - Run the cron ``Stock Account: Inventory Valuation Closing`` Traceback: ```py NotNullViolation: null value in column "journal_id" of relation "account_move" violates not-null constraint ``` https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/stock_account/models/res_company.py#L57-L63 This occurs because when the journal is unset, ``journal_id`` becomes null, leading to the above error when the cron runs. Error also occurs when the Valuation Account is unset. Traceback: ```py CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_accountable_required_fields" ``` sentry-6925934391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Chrome-specific issue where background videos in the ecommerce category showcase could flicker when visitors hovered between blocks. The change keeps the video display steady, improving the visual polish of website pages using this snippet.
Original PR description
**[FIX] website: stabilize showcase background video in Chrome** Steps to reproduce: - Drop the "s_ecomm_categories_showcase" snippet. - Change its background to a video. - Hover between the different blocks. - Bug: the video flicker on hover. Before this commit Chrome kept resizing the iframe, making the video flicker on hover. After this commit we freeze the iframe sizing in pixels so Chrome keeps the video stable. task-5104176
Event description links are now formatted so they work reliably in email clients such as Gmail. This prevents broken or confusing event URLs for recipients, helping attendees access event information without issue.
Original PR description
When website_event is installed an anchor tag is added inside the event description which is guaranteed to break the url in the gmail client. We now quote the description appropriately so that there's no confusion. task-5092759 Forward-Port-Of: odoo/odoo#229979 Forward-Port-Of: odoo/odoo#228359
Google address suggestions can list address details in different orders, which sometimes caused checkout address completion to fail. This fix picks recognized address fields more reliably, preventing errors and improving address handling for customers in countries with different locality formats.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I…
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I haven't been able to reproduce it myself, but others have. > It appears that the order Google provides place types isn't always the same. Issue ----- You may get a `KeyError`, trying to fetch `standard_data['country']`. Cause ----- The fields get sorted by type, and we try to sort `country` before `state`, so that the `country` key should be present when we get to `state`. The likely issue is that Google often provides multiple types per field, and we only keep the first one, assuming it to be the most relevant one, but the API documentation makes no guarantees about the array's order[^1]. For example, if a field were to have `political` in front of `country`, we would keep the `political` type, only to ignore it later on, as we have no mapping for it. [^1]: https://developers.google.com/maps/documentation/places/web-service/place-types#address-types Solution -------- 1. Iterate over the types, and get the first one that's part of `FIELDS_MAPPING` 2. Before searching for a `state`, ensure `country` has already been set, otherwise log a warning. 3. Extra: add `postal_town` as a type, which gets used instead of `locality` in some countries like Sweden. opw-4880651 Forward-Port-Of: odoo/odoo#230134 Forward-Port-Of: odoo/odoo#217171
The point of sale preset form now displays key fields more cleanly, especially on mobile screens and when time-based order management is disabled. This makes setup easier for restaurant or shop staff by avoiding overlapping labels, misplaced inputs, and confusing placeholder text.
Original PR description
In this commit: -------------- - The preparation capacity field was not properly displayed when manage orders by time is disabled, now we have added a additional class to make ui proper. task: 5077509
This fix changes how AI tool functions receive their inputs, making them easier to customize and better aligned with the current version. It helps reduce compatibility issues for implementations that extend or override AI behavior.
Original PR description
To ease the override and compatibility with what is done in 19.0, we call the function with kwargs instead of args. Forward-Port-Of: odoo/enterprise#96528
This fix prevents an error in the Indian withholding workflow when the action is opened without any selected records. Users now receive a clear message instead of encountering a confusing failure, helping avoid interruption during tax-related processing.
Original PR description
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190579 Forward-Port-Of: odoo/odoo#190324
Loyalty discounts and coupons now use a consistent date when checking expiration, preventing valid checkout payments from failing because of timezone differences. Expired coupons are also removed at the right time, so order totals stay accurate before payment is completed.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California…
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California before 7:00 UTC; 4. add the product to your cart; 5. go to checkout; 6. pay for the order. Issue ----- Order cannot be confirmed due to incomplete payment. Cause ----- The `_frontend_pre_dispatch` method of `website` adds a timezone value to the context based on the request's `geoip`. This context value then gets used to find applicable loyalty programs via `Date.context_today`, and applies them to the order. Then after payment was initiated, the order gets validated again using server time (UTC), which now considers the applied program expired, and removes the reward before confirming the order. Consequently, with the discount removed, the paid amount no longer matches the order total, thus the order remains unconfirmed. Solution -------- If the order has a confirmed transaction, use its `create_date` to verify loyalty expiration dates. For time zone, instead of `Date.context_today`, using whatever `tz` value is in the context, use a helper function which retrieves the current day in the company's timezone. For website orders, if defined, use the eCommerce salesperson's time zone instead. Also fix an issue where expired coupon lines weren't getting removed from the order. opw-4765873 opw-4781346 opw-4939268 Forward-Port-Of: odoo/odoo#229749 Forward-Port-Of: odoo/odoo#222428
The video call interface now highlights the fullscreen button directly instead of drawing attention to the overflow menu. This makes it clearer for users how to switch to fullscreen during Discuss calls.
Original PR description
Before this commit, when someone enabled video for the 1st time in a discuss conversation, the "..." call action had pulse animation. This is there to incite using the fullscreen mode, which was in the "..." in the past. Now that this button is in the bottom right of call view and immediately available, the pulse effect can be immediately moved to the fullscreen button. Before  After 
The Indian payroll demo contract now lists Mitchell Admin as the HR Responsible instead of OdooBot. This makes the sample offer signing flow better match a realistic logged-in user experience.
Original PR description
Currently, OdooBot is set as the HR Responsible in the default contract template demo data. To make the offer signing process more realistic and aligned with the login user, OdooBot is replaced with Mitchell Admin. task-5095841
Payroll payment reports can now be generated when an employee has multiple bank accounts with a 100% and 0% salary split. This prevents report failures and ensures all configured bank accounts can be included correctly in the CSV output.
Original PR description
-When generating a payment report CSV for user with multiple bank accounts that have a salary split of 100%/0%, a traceback occurs. -The logic has been adjusted so that bank account of 0% split percentage can be included in the payment report.
Code cleanup and technical improvements
This update reorganizes how embedded action settings are managed so they are easier to maintain and less prone to mistakes. It also adds automated checks to help ensure project-related settings are copied, removed, saved, and retrieved correctly.
Original PR description
In this PR, we rework the embedded actions settings logic in the control panel, to use a "pure" class that contains all the state and logic related to these settings. We also rework the `ResUserSettings` mock model in `web` to make it generic and use it in other modules, like in `mail`. Finally, we add Python tests to ensure the correct behavior of the embedded actions settings when copying/removing projects and when setting/getting those settings from the DB (check validity of fields and correctness). We also add some checks in the JS tests to ensure that the embedded actions settings are correctly set. task-5003800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
11 changes
Enhancements to existing features
End-of-service and provision calculations now exclude unpaid leave and unpaid sick leave days, making UAE payroll results more accurate. The end-of-service payslip also displays the total unpaid leave days, improving transparency for payroll review.
Original PR description
This commit excludes the Out Of Contract Unpaid Leaves and Unpaid Sick Leave days from the EoS and EoS Provision Salary Rule Calculations. We also show the total number of unpaid leave days on the EoS payslip. task-4886104
Resolved issues and error corrections
This fixes an error that could block users from saving a manufacturing order after starting one operation and editing another. Manufacturing order dates now only use operations that are actually scheduled, avoiding crashes and keeping production timing accurate.
Original PR description
**Steps to reproduce:** 1. In Settings, enable "Work Orders". 2. Create a product with a BOM that has 2 operations: op1 and op2. 3. Create and confirm an MO for 1 unit. 4. Start op1 and change the…
**Steps to reproduce:** 1. In Settings, enable "Work Orders". 2. Create a product with a BOM that has 2 operations: op1 and op2. 3. Create and confirm an MO for 1 unit. 4. Start op1 and change the Real Duration of op2. 5. Try to save. **Issue:** - Traceback : `'<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause of the issue:** Starting the first operation launches a call of the `button_start` method creating a `resource.calendar.leaves` to set on the `leave_id` of this first operation: https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_workorder.py#L630-L641 Then, setting the duration of the second operation from the form view of the MO and saving triggers a call of the write of the MO containing the `[Command.update(op_2.id, new_duration)]` as vals.This, in turn, calls `_plan_workorders`: https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L939-L942 while the first operation has a set `leave_id` but the second do not However, the `min` operator will be applied to both the set and the unset values, comparing a `boolean` with a `datetime`: https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L1581-L1588 **Solution:** Only workorders with a `leave_id` (i.e., those planned in work-center schedule) should be considered when computing MO `date_start` and `date_finished`. Workorders without a `leave_id` are not yet scheduled and therefore should not influence MO start and end dates. As both `date_start` and `date_finished` of a workorder are related to the `leave_id` record. As per `mrp_workorder._compute_dates`, these dates reflect the work-center scheduling (`leave_id.date_from` and `leave_id.date_to`). https://github.com/odoo/odoo/blob/6a075fa3c090920499ccbd5fe673819da7e3f95e/addons/mrp/models/mrp_workorder.py#L250-L260 Therefore, when computing MO dates, it logically follows that only workorders with an assigned `leave_id` should be used. This avoids mixing unscheduled operations (`leave_id = False`) with scheduled ones, preventing invalid comparisons and ensuring accurate production timing. **opw-5068080**
The Barcode app now shows post-validation helper messages as readable text instead of exposing raw HTML. This improves clarity for inventory users validating filtered transfers and avoids a confusing interface issue.
Original PR description
Issue: ------ When validating a transfer after filtering by scanning a product, the empty help message was shown as raw HTML instead of parsed text. Steps to reproduce: ------------------- 1. Install Barcode. 2. In Inventory, create a receipt with product Pedal Bin. 3. Click Mark as Todo. 4. Open Barcode → Operations → Receipts. 5. Scan the barcode of Pedal Bin. 6. Open the receipt and validate. The helper text is displayed in raw format. Cause: ------ The server returned the help text as a plain HTML string. Since JSON serialization strips Python markup objects, the client received raw HTML, which was not parsed and therefore rendered as-is. Fix: ---- The web client now wraps the help text with `markup()` before display, ensuring the message is parsed and shown in a readable format. opw-5090075
Product tax fields now make it clear which company each sale or purchase tax belongs to when users work with multiple companies. This helps accounting users choose the correct tax and avoid confusion in multi-company environments.
Original PR description
Backport of some changes included here https://github.com/odoo/odoo/commit/2cf73ba8fe50288a0ea9d0ad4b8aeb51bc345740 The goal of this pr is to see for which company belongs each sale/purchase tax in a…
Backport of some changes included here https://github.com/odoo/odoo/commit/2cf73ba8fe50288a0ea9d0ad4b8aeb51bc345740 The goal of this pr is to see for which company belongs each sale/purchase tax in a product when more than one company is selected. This pr solves odoo task #4829985 and this issue https://github.com/odoo/odoo/issues/147673 Steps to reproduce: 1) Go to runbot odoo enterprise 18 instance and select companies "My Belgian Company" and "My Company (San Francisco)" taking position in "My Belgian Company". 2) Go to "Accounting / Customers / Products" and get into product with name "Bolt" and internal reference "CONS_89957". There is shown two taxes in "Sale Taxes" and "Purchase Taxes" fields but is not possible to distinguish for which company belongs each tax. Current behavior: It can not be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected. Expected behavior: It can be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected. Task Adhoc side: 52262 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
Odoo now handles attached email files containing accented or other non-English characters correctly. This prevents email sending failures when users attach saved email messages in the chatter, improving reliability for international communication.
Original PR description
The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with…
The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with non-ASCII characters could not be serialized ### Steps to reproduce 1. Send an email via the chatter with a `.eml` file attached containing non-ASCII characters (e.g., "é") in its body. The sending of that email will fail with a `UnicodeEncodeError` error ### Cause Commit 6197233ef1611ddd974cfdb06ae2568e4af369de attempted to fix an issue where `.eml` (`message/rfc822`) attachments were not RFC-compliant. It did this by forcing the `Content-Transfer-Encoding` to `binary` for the raw byte content of the attachment. While this worked for simple ASCII attachments, it failed for attachments containing non-ASCII characters. When Python's `email` library later tried to serialize the entire message, it treated the attachment's content as an opaque binary blob. It did not understand the character encoding within that blob, leading to a `UnicodeEncodeError` during the final serialization process. ### Fix Instead of attaching the raw bytes, we now: * Parse `.eml` contents using `email.parser.BytesParser`, producing a proper `Message` object. * Attach the parsed message directly, letting the email library handle correct encoding and transfer settings automatically. opw-4655868 Forward-Port-Of: odoo/odoo#223790
This fix updates Spanish VAT handling so certain non-EU service sales are reported in the correct VAT category instead of being treated as exports. It also corrects the refund sign for the related non-subject VAT service tax, improving accuracy in Modelo 303 tax filings.
Original PR description
The s_iva_e tax (IVA 0% Extracomunitaria (Servicios)) is configured as no_sujeto_loc, but is reported as "Exportacion" in modelo 303. There might have been the idea that we need a tax for services that are just a complement to some goods, but this tax is not used that way in practice. So, it is better to treat it as a duplicate of the s_iva_ns tax (Not Subject To VAT (services)) where we also see that the refund sign was wrong. opw-5079297 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#229752
UrbanPiper POS orders now apply the correct product taxes when a point of sale is configured under a company branch. This prevents undercharged orders in multi-branch setups and also supports taxes that are split into sub-taxes, such as GST components.
Original PR description
Steps to reproduce: --- - Install `pos_urban_piper`. - Create a branch under *Main Company*. - Switch to the new branch. - Create a POS config in this branch and set up UrbanPiper. - Sync "Apple Pie". - Place an order with "Apple Pie". Issue: --- - The 15% tax defined on Apple Pie is not applied on the orderline. Cause: --- - While creating the order line, the tax company was compared directly with the POS config’s company. In this case, the tax belongs to the parent company, while the POS config belongs to a child company. Fix: --- - Compare the `root_id` of both companies instead of the direct company ID to ensure taxes are applied correctly in multi-branch setups. - Additionally, handled the case where a main tax has sub-taxes (e.g., 5% GST split into 2.5% SGST and 2.5% CGST). In such cases, we now fetch the tax type from the sub-taxes instead of the main tax. Task-5050682
This fixes an issue where changing the style of text inside certain formatted elements could create invalid page structure. Users editing website or document content should now get cleaner, more predictable formatting when applying paragraph styles.
Original PR description
Before this commit we would insert a block inside of a phrasing content if it's displayed as a block and we change its font style. For example, if we tried to modify text inside of a `<small>` that has `display: block` style, it would insert a new block inside of it. Steps to see the issue: - Have an open editor with `<small>Text</small>` content, that has `display: block` style - Select "Text" and change the font style to paragraph => It will be `<small><p>Text</p></small>` which is not valid HTML, and it will be parsed by a browser as `<small></small><p>Text</p>`, which is not the expected behavior. task-5123274
Loyalty discounts and coupons now use a consistent date reference during website checkout, so valid promotions are not removed after payment because of timezone differences. This prevents paid orders from getting stuck as unconfirmed and ensures expired coupons are removed at the right time.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California…
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California before 7:00 UTC; 4. add the product to your cart; 5. go to checkout; 6. pay for the order. Issue ----- Order cannot be confirmed due to incomplete payment. Cause ----- The `_frontend_pre_dispatch` method of `website` adds a timezone value to the context based on the request's `geoip`. This context value then gets used to find applicable loyalty programs via `Date.context_today`, and applies them to the order. Then after payment was initiated, the order gets validated again using server time (UTC), which now considers the applied program expired, and removes the reward before confirming the order. Consequently, with the discount removed, the paid amount no longer matches the order total, thus the order remains unconfirmed. Solution -------- If the order has a confirmed transaction, use its `create_date` to verify loyalty expiration dates. For time zone, instead of `Date.context_today`, using whatever `tz` value is in the context, use a helper function which retrieves the current day in the company's timezone. For website orders, if defined, use the eCommerce salesperson's time zone instead. Also fix an issue where expired coupon lines weren't getting removed from the order. opw-4765873 opw-4781346 opw-4939268 Forward-Port-Of: odoo/odoo#222428
Reports now properly show one-to-many field values, matching the behavior already available for similar linked record fields. This fixes missing or incorrect report content for businesses that rely on these fields in printed or exported documents.
Original PR description
For now, `One2Many` fields are not displayed correctly in reports. This is because for other types of fields (`ManyToMany`, `ManyToOne`, etc.), there are Converter classes (`ManyToManyConverter`) `ir.qweb.field.many2many` that implement `value_to_html`. However, for `OneToMany` fields, no implementation is present. This commit adds a `OneToManyConverter`, which is essentially the same as the `ManyToMany `one. opw-5098466 Forward-Port-Of: odoo/odoo#229289
A typo was corrected in the Attendance department grouping option. This helps users group attendance records by department reliably when reviewing employee attendance data.
Original PR description
- Fixed typo in groupby for 'department' task-id - 5109185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
6 changes
Resolved issues and error corrections
This fixes French localization time-off calculations so leave-related timesheet entries use the employee's actual work schedule, even when it starts earlier or ends later than the company schedule. It prevents incorrect worked-hour totals, helping payroll and timesheet records reflect the correct absence duration.
Original PR description
This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry (`account.analytic.line`) creation, and the duration field is created using the company schedule.…
This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry (`account.analytic.line`) creation, and the duration field is created using the company schedule. The reason is the case which the employee schedule starts before company scheudle or ends after it. To reproduce the bug: 1- Make a db with fr company (install l10n_fr) 2- Make two working schedule: - Company schedule with working day on Monday from 8:00-12:00 13:00-17:00 - Employee schedule with working day on Monday from 8:30-12:25 13:30-17:15 3- Assign company schedule to company in `Company Working Hours` in Setting and apply employee schedule to an employee from `Payroll` tab of employee 4- Allocate some time off to the employee and take a time off on Monday 5- Check the work entries for the day you took the day off on timesheet app 6- 7:24 `Worked Hour` is shown instead of 7:40 The bug occurs because in calling `adjust_date_range`, the case which employee's schedule ends after company schedule is not considered. opw-4868643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The hierarchy view now handles circular reporting relationships, such as an employee being set as their own manager, without crashing or getting stuck. This improves reliability for users viewing organization charts and other hierarchy-based screens.
Original PR description
This commit fixes some traceback errors in the web_hierarchy module by refining the cycle detection of records in hierarchies. Infinite loops in case of a cycle's presence in the `removeChildNodes` and `processNode` methods are now prevented. Additionally, tree re-rooting in case of the presence of two nodes in the same tree, which implies a cycle's existence, is now avoided. There was an edge case where an employee could be their own manager, creating two child nodes of that employee. The case is now handled by making sure that records are unique for each parent ID in the `recordsPerParentId` object. task-5022670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Survey respondents can now submit a multiple-choice question with a written comment when comments are allowed as an answer, even when roaming is enabled. This prevents incorrect required-answer warnings and adds stronger validation to stop multiple answers on single-choice questions.
Original PR description
Issue: When answering a question with a comment in multiple choice with roaming activated for the survey, the UI will display a warning message that says the question requires an answer. Cause: The backend creates a skipped record if none of the pre-created answers is chosen. Solution: Don't create a skipped record if a comment counts as an answer and a comment is provided. Added validation of input and unittests Task-5062984
The Dutch localization now uses the correct default accounts for deferred expenses and income. This helps Dutch companies post deferred amounts to the right balance sheet accounts and improves the accuracy of financial reporting.
Original PR description
The default deferred accounts in the Dutch localization were incorrect. This commit sets the proper accounts and adjusts the `account_type` of the default deferred expense account from "Prepayments" to "Current Assets". task-5152529 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from creating new Swiss payroll workplace names directly from the contract form when that shortcut could trigger an error. Users can still select existing workplace records, reducing confusion and avoiding failed contract updates.
Original PR description
The _rec_name was previously set to partner_id, causing type errors when typing a new workplace name in a Many2one field. Couldn't change it to anything else, as one should have to create a new field in that stable version and this is not the best practice. As a workaround, the corresponding field in the l10n_ch_hr_contract_views.xml is removed from it the quick_create to prevent the creation of new names on the fly. task-5043056
This fixes an issue where custom hour or half-day selections could be cleared when an employee changed the time off type. The change helps users keep their intended leave request settings and reduces accidental re-entry.
Original PR description
- made the value of checkboxes for `request_unit_half` and `request_unit_hours` stay the same when switching between timeoffs that can have hourly type task-id: 5085389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr