Wednesday, September 9, 2026
37 changes · saas-18.4
Resolved issues and error corrections
Point of Sale users without administrator settings rights could be blocked by an access error when an optional installation-request component was not installed. This fix prevents that unnecessary permission check, allowing authorized Point of Sale users to access the app normally.
Original PR description
Fixes https://github.com/odoo/odoo/issues/238503 Avoid access error if `base_install_request` is not installed Example use case: - Install point_of_sale (without having `base_install_request` installed) - Give user Marc Demo Point of Point of Sale permission but NOT Administration > Settings - Go to Point of Sale ``` Access Error You are not allowed to access 'Module' (ir.module.module) records. This operation is allowed for the following groups: - Administration/Settings Contact your administrator to request access if necessary ``` Please @pedrobaeza and @christian-ramos-tecnativa can you review it? @Tecnativa TT57146 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240587
The website editor now skips unnecessary cleanup for images whose source comes from a saved URL field. This prevents the editor from trying to process external image links it does not manage, reducing save-time errors and preserving image behavior.
Original PR description
As of commit 8e397140, the builder walks every `<img>` of the editable area before saving and strips the shape-related dataset entries that no longer apply. Images rendered by an `image` field are excluded from that pass: their `src` is produced from the record's field value, so the builder neither owns it nor has anything to clean on it. `image_url` fields inherit from `image` fields and are in exactly the same situation, except that their `src` is the URL stored in the field rather than a generated `/web/image` link. They were not excluded, so the cleanup ran on them and tried to resolve image info from an arbitrary, possibly external, URL. This commit excludes `[data-oe-type='image_url'] > img` from the pre-save cleanup as well.
Some partner commission screens are now assigned to the correct source module. This helps ensure the feature is installed, updated, and maintained consistently without confusing ownership of related screens.
This update adjusts spreadsheet-related files to support a fix for FRGI testing. It helps keep spreadsheet behavior and presentation reliable for users, reducing the risk of issues during testing or validation.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes point-of-sale test scenarios search customer records directly from the backend when needed. It prevents test results from depending on the order in which customers load, improving reliability without changing normal user workflows.
Original PR description
Added an explicit config on partner search which explicitly triggers a backend search when enabled to ensure the partner load order doesn't affect the result of tours where it's irrelevant. Runbot-[#233397](https://runbot.odoo.com/odoo/error/233397) Task-[6522073](https://www.odoo.com/odoo/project/1737/tasks/6482065/project.task/6522073) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Calendar bookings now use the employee's current working schedule when no contract dates are set, avoiding false unavailable warnings for users with standard employee records. This helps appointment scheduling work correctly in common setups without requiring contract configuration.
Original PR description
- install appointment and hr without demo data - create a booking for any appointment type via gantt - user partner is always unavailable In 18.3 we merged "on_leave_partner_ids" into "unavailable_partner_ids" @[1] However unavailable_partner_ids takes into account contract periods and considers that not being under contract means you are not available. Whereas on_leave_partner_ids did not. This leads to the warning message being displayed in appointment when the employee of the user has no contract, which is the default. Instead now the field will use the current employee regardless of contracts, as we don't strictly care most of the time. unavailable_partner_ids was previously used only for icon display purposes showing the user as unavailable in calendar attendees selection. Hence changing the logic is not very impactful. [1]: https://github.com/odoo/enterprise/commit/a66b824287f9023c93b7f61607dbb8af520e7ee1 task-5083433
This fix prevents occasional crashes when users switch pages while editing reports in Studio. It makes the editor safely stop style checks when the report page is no longer available, improving stability without changing normal editing behavior.
Original PR description
In studio mode, when editing a report and then changing pages, functions that interact with the report editor are occasionally still executed after the page transition. This causes `this.document.defaultView` to become null. Consequently, trying to call `defaultView.getComputedStyle` throws an error, breaking some tests. This commit adds a fallback check for `this.document.defaultView` and early returns false if either the window view or the target element is missing. runbot-233779
This fixes the UAE corporate tax report setup so tax returns keep the expected Review, Submit, and Pay workflow after upgrades. It helps prevent upgraded databases from showing only the Review step or triggering an error when opening tax returns that were already submitted.
Original PR description
The report is missing a root report that is common in reports from other localizations. Withouth it, the states workflow changes from Review, Submit, Pay in 18.4 to just Review in 19. <img…
The report is missing a root report that is common in reports from other localizations. Withouth it, the states workflow changes from Review, Submit, Pay in 18.4 to just Review in 19.
<img width="594" height="159" alt="image" src="https://github.com/user-attachments/assets/8362e293-0677-45df-bac1-c613ef313a52" />
<img width="571" height="146" alt="image" src="https://github.com/user-attachments/assets/b26a3a7e-c3ca-4512-809f-3db0fc597ba2" />
---
It can also trigger an error after upgrading to 19. To reproduce:
- Install accountant and l10n_ae_reports in 18.4.
- Using an AE company, change a Corporate Tax' state to Submitted.
- Upgrade to 19.
- Navigate to Tax returns.
You will get the error
```
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 926, in _compute_next_state
next_state_index = state_keys.index(record.state) + 1
ValueError: 'submitted' is not in list
```
Since the report linked to return type lacks a root report, it got assigned `generic_state_review` as `states_workflow` that only allows for Review.
---
Please note: I'm not an expert in accounting or localization. I saw an upgrade failing on this, looked at the problem and took an educated guess. I don't know if the root report is missing on purpose for some functional reason. If that's the case, let me know and I will try to do something on the ugprade script for these cases.Employee start and end date searches now better reflect the dates shown by the system instead of relying only on contract dates. This improves calendar-related filtering and makes employee date information more reliable when contracts are not the main reference point.
Original PR description
Currently the computed fields `date_start` and `date_end` don't have a properly matching search function. Instead the search is based on purely the contract start and end date, which makes searching on these fields somewhat useless. Now we attempt to match the computation by picking the min/max start and end date respectively. This is notably useful in calendar where contracts are somewhat irrelevant. task-5079021
The Payroll app no longer shows an error when users open the Payslips menu before any payslips have been created. This makes the first-time or empty-state experience smoother and prevents an unnecessary interruption for payroll users.
Original PR description
This PR fixes a traceback that occurred when opening the Payslips menu in the Payroll app without any existing payslips. Root Cause: The issue was caused by passing a null or undefined payrunId to the PayslipActionHelper component, which was not handled properly. Solution: Since payrunId is optional, we added a conditional check in the parent view (hr_payslip_list_renderer) to only pass the payrunId to PayslipActionHelper if it is defined. Related task: 4919933.
Time off calculations now correctly handle employees with fully flexible working schedules by not forcing a work calendar where none should apply. This helps avoid incorrect leave computations for flexible schedule arrangements.
Original PR description
In case of fully flexible working schedule resource_calendar_id should be false. task-4965122 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Egyptian payroll now calculates basic salary from the employee's contract wage and handles out-of-contract days using actual worked days from the payslip. This prevents incorrect salary amounts when contracts start mid-month, improving payroll accuracy for affected employees.
Original PR description
**Steps:** 1. Install the l10n_eg_hr_payroll module. 2. Create an employment contract starting from 15 Jan, 2026 and generate the payslip for that month. **Issue:** The basic salary is not being computed correctly, It's showing 12k, That will be attendance worked days amount In the Out of Contract calculation, the salary is divided by the total number of days in the month instead of the actual worked days. **Fix:** The basic salary will now be based on the `version.wage`, For the Out of Contract, we will use the total worked days from the payslip instead of the total days in the month. Task-5485615
The Turkish e-Ledger export now fills in line numbers automatically and keeps them continuous across the full fiscal period, including monthly filings. This helps businesses meet GİB expectations and avoids manual numbering errors or inconsistent exports.
Original PR description
Before: the `LineNumber` column of the e-Ledger CSV was always empty, left to be filled after the export. Since the ledger is filed monthly, whatever filled it restarted at 1 every month, while GİB expects the numbering to start once, at the beginning of the fiscal period, and to run unbroken until its end. Now: the column is written by the export. An export starting after the first day of the fiscal period is offset by the number of rows that period already counts, so February continues where January stopped, and a full-year export numbers the same rows identically. The lines are also read in ascending date order. They were sorted by the default order of `account.move.line`, the most recent first, so the first row of the file was the last entry of the period and could not be numbered 1. This reverses `EntryNumberCounter` as well, which now counts from the oldest entry. task-6424730 Forward-Port-Of: odoo/enterprise#130486 Forward-Port-Of: odoo/enterprise#127518
This fixes an editor issue where keyboard shortcuts could still apply formatting to non-HTML fields even though the toolbar correctly disabled those options. It helps prevent accidental changes to page header or footer text when editing blog content.
Original PR description
Problem: Selecting text in non-html fields disables toolbar formatting, but pressing CTRL+B still formats the text. Cause: `formatSelection` did not check if the selection was inside a non-html field before applying formats. Solution: Return early in `formatSelection` if the selection is inside a non-html model field element. Steps to reproduce: 1. Go to /blog and open an article. 2. Open editor and select header/footer text. 3. Press CTRL+B. => Selected text becomes bold. opw-6537402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286675
Odoo now blocks bulk archiving when it would leave an employee with no active version. This keeps employee records accessible and ensures the same safeguard applies whether versions are archived one at a time or together.
Original PR description
Version: saas-18.4 (first affected version) **Issue** When archiving versions for an employee, Odoo correctly prevents archiving the last remaining version when done individually. However, when…
Version: saas-18.4 (first affected version)
**Issue**
When archiving versions for an employee, Odoo correctly prevents archiving
the last remaining version when done individually.
However, when multiple versions are selected and archived at once from the
employee history view, all versions are archived without any validation error.
This leads to an invalid state where an employee has no active versions.
**Steps to Reproduce**
1. Create an employee
- A first version is automatically created.
2. Try to archive this version
- An access error is raised (correct behavior).
3. Create two additional versions for the same employee.
4. Go to Employee History, select all versions, and click Archive.
5. All versions are archived without any error (unexpected behavior).
**Expected Behavior**
Archiving all versions of an employee should always be blocked, regardless of
whether the action is performed on a single version of multiple version at once.
### Solution
Before archiving, the system now verifies that at least one active version will remain for each employee.
If an archive action would remove all active versions, it is prevented with a validation error.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update makes action menus in Discuss and Live Chat look and behave more consistently across messages, threads, attachments, and chat windows. It also adds small visual refinements that make conversations easier to scan and controls easier to recognize.
Original PR description
In discuss, thread / message / composer / call / attachments actions dropdown style all differ visually. This comes from each defining their own template. This becomes hard to fix and improve visual…
In discuss, thread / message / composer / call / attachments actions dropdown style all differ visually. This comes from each defining their own template. This becomes hard to fix and improve visual of action to make discuss more intuitive. This commit defines a generic `mail.DiscussActions` that renders (dropdown) actions. This centralized template allows to put more effort in a nicer look, and is a step towards harmonizing the definition of discuss action registries. TODO: inline style for chat window quick part + message quick part, thread inline actions use "large" mode mobile message actions is not yet considered in this PR. This commit also makes miscellaneous style improvements: - chat bubble message preview uses bubble color of last message - fixes minor discuss sidebar option / actions alignment - chat window thread panel back button is chevron rather than arrow - chat bubble in mobile do not move on click - chat window header "more action" has better visual feedback - message action dropdown orientation takes message alignment in conversation - hashtag / globe channel icon have reduced opacity to match other discuss status icon - image actions button is "..." rather than chevron to be consistent with other discuss "options" buttons' icon. - rounded panels and button
Website live chat now shows the right conversation participants and gives internal users access to more of the same chat options they use in the main system. In the website builder, only one chat panel appears at a time, preventing duplicate conversations and reducing confusion while previewing or editing pages.
Original PR description
Before this commit, chat hub in website was confusing for internal users: - correspondent + avatar for live chat conversations was wrongly computed (e.g. self-operator was considered a visitor) -…
Before this commit, chat hub in website was confusing for internal users: - correspondent + avatar for live chat conversations was wrongly computed (e.g. self-operator was considered a visitor) - many thread and message actions are not available compared to web client. This commit fixes both issues as follow: - many features in web client chat hub are now available for internal users in website chat hub. - computation of correspondent and livechat actors is correct for operators in website chat hub. Making the website chat hub almost feature full-fledged is helpful to solve the duplicated chat hub in the website builder, so that using the website chat hub is barely a regression over the web client chat hub. ---- Before this commit, website builder page was showing 2 chat hubs at once: - chat hub from the web client - chat hub from the live chat on website The website builder is in web client so makes sense to enable chat windows from web client. Some feature are specific to backend and need to be shown while editing the website. The website builder also previews how the website look. Therefore it makes sense to show live chat hub because it's part of the actual website page being previewed. The problem with showing the 2 chat hubs is that chats are duplicated due to being shown in both hubs. The chats are intended to be seen from the website so the underlying problem is showing both chat hubs at once. This commit fixes the issue as follow in website builder: - when not editing the website, show the live chat hub and hide the web client chat hub - when editing the website, show the web client chat hub and hide the live chat hub. This works because web client chat features at desired when actually editing the website. Viewing live chat hub when not editing the website works because this is the actual showing of website with the live chat hub. There's also no feature on website editor that affects the website live chat hub.
The purchase order suggestion wizard now handles actual demand more accurately. It can include products even when no price is set, and it considers overdue outgoing deliveries that still need to be fulfilled, helping buyers avoid missing needed items.
Original PR description
This commit fixes 2 bugs in the purchase order suggestion wizard when it's based on actual demand: 1- it now allows the suggestion wizard to add products without prices to the PO. 2- it now takes into account outgoing deliveries with scheduled date in the past, as long as it's not validated yet. Task-4877088
This fix prevents older background notifications from overwriting newer message edits in Discuss and chatter. Users should see the latest message content more reliably, especially when the system is under heavy load or notifications are delayed.
Original PR description
Before this commit, discuss RPCs like update_content were prone to race-condition that can lead to UI showing outdated content of a message that was just edited. This happens because some store data…
Before this commit, discuss RPCs like update_content were prone to race-condition that can lead to UI showing outdated content of a message that was just edited. This happens because some store data are exclusively feed from return data of RPC whereas some store data are feed from bus notifications. Ordering of data are essentially sound among RPC returns and bus notifications, but not between the 2 groups. Therefore RPC return or bus notifications can come before or after the other one, and the ordering may be wrong and result in wrong store data. In practice bus notifications usually before return of RPCs. Most of discuss code is robust against this ordering, even though there's likely many potential of race conditions that may happen and are genuine bugs. When bus notifications come after returned RPCs, however, problems are more apparent. This may happen when the bus notification queue is slow, but also in tests this is likely to happen because RPCs are simulated with single micro-tick whereas handling of bus notification is usually more than 1 micro-tick. The test "Can edit message comment in chatter" is showing this problem: it's a relatively long test that interacts a lot with message edition, which has the message content being obtained from both bus notifications and RPC returns. When the CPU load is high, test takes much more time to run, e.g. 400ms becomes 2500ms. This CPU load affects barely RPC returns but bus notifications are heavily throttled and therefore causes bus notifications to come much later than expected. Test edits message twice with different content and then once without any change. The high CPU load can make test fail after 3rd edit step because the content of message is the 1st edited content instead of the last. The last edition is coming later in the bus notification, but due to timing constraints of 3 seconds assertion can lead to timeout of test because the message is not showing the most recent edited content. Roughly: 1. message is "original message" 2. message is edited to "edited message" 3. message shows "edited message (edited)" 4. message is edited to "edited again" 5. message shows "edited again (edited)" 6. message editing is started => message content in composer is "edited message" instead of "edited again", so crash after 3 seconds Step 6 fails because message content between 5 and 6 is changed to "edited message" from the bus notification. All previous steps had the message edited relatively quickly (500ms each) by returned RPC. The bus notifications are throttled to about 3 seconds, thus the "edited message" bus notification arrived very late when starting edition in step 5. The composer content is wrong and the contains wait for at least 3 seconds, but due to heavy throttle of bus notifications from CPU load, the test fails. This commit fixes the issue by introducing a `busRpc()` function on bus_service and have message edition flow use this busRpc() rather than `rpc()`. This `busRpc()` function is a special flavour of `rpc()` that awaits until the RPC and related notifications have been received. `busRPC()` works by forging a UUID bus_rpc_uuid that the RPC sends back at end of RPC. The `busRPC()` function waits until this notification is received. This commit ensures ordering of store data received from server is good, because RPC properly awaits bus notification. Store data of RPC return makes sense after these bus notifications, but ideally it should also be sent to bus notification and business code should ignore returned data from RPC, so that ordering of store data is always good even with interleaving if discuss actions. This also solves the race condition in the test "Can edit message comment in chatter", because each assertion of message content ensures we are in the window of data feed by related bus notifications. When a message is being edited the composer is not affected by new message content from store data of bus notifications, but the save of the message edition should necessarily have to await related bus notifications, ensuring no previous bus notifications can be feed after this store data state. Fixes runbot 227618
This fix prevents an error when loading HR sample data after the default Administration department has been deleted. The sample employees can now be created with optional department fields left empty, avoiding disruption for users setting up or testing the Employees app.
Original PR description
Currently, an error occurs when loading scenario data after user deleted administration department. Steps to replicate: - Install `hr` and open `Employees > Departments`. - Delete the…
Currently, an error occurs when loading scenario data after user deleted administration department.
Steps to replicate:
- Install `hr` and open `Employees > Departments`.
- Delete the `Administration` department.
- Open Employees, Delete all the employees and Click `load sample data`.
Error:
```
ValueError: External ID not found in the system: hr.dep_administration
ParseError: while parsing /home/odoo/src/odoo/saas-19.3/addons/hr/data/scenarios/hr_scenario.xml:114, somewhere inside
<record id='employee_mw' model='hr.employee' forcecreate='1'>
<field name='active'>True</field...
```
Cause:
- As the user deleted the administration department before the scenario data was loaded the error occurs from [here].
- In the previous version, this error did not occur because, starting from `saas-18.4`, scenario data is loaded through a server action [1]. In earlier versions, the scenario data was loaded along with the demo data through the settings instead. During demo data loading, any errors are converted into warnings, so no error is raised.
Solution:
- Prevented error from occurring when reference is not found. Since these fields are not required, they can safely remain empty.
[1]: https://github.com/odoo/odoo/blob/9400393a13d238404c9797a906ee11b6afcc761e/addons/hr/views/hr_employee_views.xml#L567
[here]: https://github.com/odoo/odoo/blob/b3d0cf09b491f180d6b6d654026497cc7de6731d/addons/hr/data/scenarios/hr_scenario.xml#L124
sentry-7441124574, 7584820916
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe website link editor now displays relative links exactly as users entered them, rather than converting them into full website addresses. This avoids confusion when reviewing or editing internal links, while full external links still appear normally.
Original PR description
Current behavior before PR: - The input shows the absolute URL resolved by the browser (e.g., `https://example.com/contactus`), even if the user originally entered a relative path like `/contactus`. Desired behavior after PR is merged: - The input now displays the original href attribute as entered by the user. Absolute URLs are still shown in full when explicitly entered. task-4890293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor now avoids repeatedly requesting the same loading spinner image when users hover over sidebar options. This reduces unnecessary browser activity and helps keep the editing experience smoother, especially when cache is disabled or connections are slower.
Original PR description
Since commit [1] ([REF] website: rewrite website builder using owl and new html editor), the loading spinner element was created dynamically each time an option was hovered in the website builder sidebar. Steps to reproduce: 1. Open Website in edit mode 2. Add a snippet 3. Open the browser inspector → Network tab and disable cache. 4. Hover over different options in the sidebar 5. Observe multiple requests to `/web/static/img/spin.svg` After this fix, only one request is made if a spinner is wanted. [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
This fix keeps the editor toolbar open when users select text and apply formatting such as a background color. It restores the text selection at the right time, preventing the toolbar from disappearing unexpectedly and making editing more reliable.
Original PR description
Steps to Reproduce : - Go to To-do, Create New - Type something - Select all using Ctrl + A - Try to apply background color, the Toolbar closes instantly because of reverted step has not proper selection. Current behavior before PR: - Reverting a preview/commit didn’t restore the correct selection because those steps added via addStep() with collapsed selection (this.currentStep). - During revert, revertStepsUntil revert the this last added step and triggers the step_added_handler. - This handler immediately calls updateToolbar() before the manual selection restoration happens, leading to the toolbar closing due to missing selection. Desired behavior after PR is merged: - The selection is restored before adding the consumed step in revertStepUntil, so reverting restores it correctly and keeps the toolbar open. task-4941601 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
A failing automated test for rental invoicing under Anglo-Saxon accounting was corrected to better reflect the full stock delivery workflow. This helps keep rental accounting checks reliable and reduces false build failures without changing customer-facing behavior.
Original PR description
The test test_no_cogs_for_rental_invoice_anglo_saxon was failing because it did not correctly simulate the full Anglo-Saxon workflow for a stockable product. In Anglo-Saxon accounting, the Cost of Goods Sold (COGS) journal entries are generated upon the validation of the stock move (delivery). This commit fixes the test by: Ensuring the product has stock and is correctly configured as a storable product with real-time valuation. after the creation of the sales order runbot-error-231043
Job offer emails now correctly include the employee's name in the email subject. This makes outgoing offer messages clearer for recipients and helps HR teams identify related employee communications more easily.
Original PR description
**Steps to reproduce:** - Go to Employees app and select any employee - Press "Offers" smart button - Create a new job offer and send it by email **Issue:** The employee name is not populated in the email subject. Task: 5407028
Declined signing requests now show the name and email of the person who actually refused the document. This improves clarity in the document history and helps teams accurately track who declined a signature request.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Do sign now on document with other user than logged in user. - Decline the sign request. Issue: - When the signing request is declined, the chatter message does not display the correct name and email of the user who refused the document. - This happens because if the refusing user is different from the responsible user, the fields refusal_name and refusal_email are not set properly. Solution: - Add a fallback to use the currently logged-in user’s name and email when refusal_name or refusal_email are not available. Impact - Ensures the chatter message correctly shows who declined the document. - Improves clarity and traceability in document signing history.
This fix makes action menus in messaging and related apps look more consistent. It improves the user experience by reducing visual inconsistencies when people use message, chat, WhatsApp, and helpdesk conversation actions.
This update fixes a visual inconsistency in the action dropdowns used in Discuss and related messaging areas. It helps provide a cleaner, more consistent experience when users interact with messages across apps such as Knowledge, Helpdesk live chat, and WhatsApp.
Fixed a misspelling in the Helpdesk "Auto Assignment" group name. This improves clarity for users and administrators who see or manage this setting.
Original PR description
This commit fixes the typo in the "Auto Assignment" group. task-6542450 Forward-Port-Of: odoo/enterprise#130880 Forward-Port-Of: odoo/enterprise#130841
The Belgian payroll employee form now displays holiday attest recovery fields correctly on mobile devices. This prevents text fields from wrapping into the wrong column, making the information easier to read and complete on smaller screens.
Original PR description
Issue: the text fields "Holiday Attest xxxx - Simple Holiday Pay to recover in yyyy" were not displayed correctly on mobile devices being wrapped on different column. Task ID: 5108575
Text highlighting now lines up correctly on websites using right-to-left languages such as Arabic. This improves the editing experience by preventing highlight effects from appearing shifted away from the selected text.
Original PR description
Problem: When an element has `direction: rtl`, the text highlight is incorrectly shifted to the right of the text `span`. Cause: The highlight `svg` uses width `1px` and height `1px` but also sets…
Problem: When an element has `direction: rtl`, the text highlight is incorrectly shifted to the right of the text `span`. Cause: The highlight `svg` uses width `1px` and height `1px` but also sets `right: 0px`. This anchors it to the right instead of the top-left, causing the highlight path to overflow incorrectly on RTL text. Solution: Remove `right: 0px` so that the `svg` always anchors at the top-left. This allows the path to overflow properly on the right side, fixing the highlight alignment. Before: <img width="607" height="357" alt="image" src="https://github.com/user-attachments/assets/0896c29b-ff4a-4a43-9a94-1a00c14d6ea0" /> After: <img width="612" height="366" alt="image" src="https://github.com/user-attachments/assets/93fca551-1aca-4f0a-bba5-34b374106b22" /> Steps to reproduce: 1. Change the website language to an RTL language (e.g. Arabic). 2. Add any text snippet. 3. Select some text and open the highlight options from the toolbar. 4. Observe the highlight options are misaligned. opw-5154303 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how Belgian payroll contract template fields are handled so tests no longer reference fields from an optional fleet-related module when it is not installed. It helps keep payroll localisation validation reliable without changing day-to-day payroll functionality.
Original PR description
Issue: The test_be_contract_template_loading test fails due to incorrect fields being passed. Cause: The issue occurs because the _get_whitelist_fields_from_template() method includes the some fields, introduced in this https://github.com/odoo/enterprise/pull/92093. This field comes from the l10n_be_hr_payroll_fleet module, which is not listed as a dependency in all payroll localisations. As a result, the field cannot be found during test execution. Solution: Remove the all that fields from all _get_whitelist_fields_from_template overrides in the localisation modules, and instead include this fields by overriding the function in the l10n_be_hr_payroll_fleet module. build_error-231684
This fix ensures accounting entries imported for one company are not accidentally matched with entries from another company when both have similar document numbers. It prevents multi-company posting errors and helps keep accounting data properly separated between companies.
Original PR description
Steps to reproduce: [account_winbook_import] - create Company A - import winbook file (from ticket) - create Company B - Import same Winbook file - Archive Company A - Post entry ACHAT/2024/12/0001 Issue: Multicompany error Cause: The issue is that we have entries with matching numbers. Since we import multiple times the same winbook archive This block https://github.com/odoo/odoo/blob/6cef5cb2375c223551dc27b3a27927388527f63b/addons/account/models/account_move_line.py#L3164-L3168 retrieves the account_move_line from the other company opw-4980059
The website information page now uses the updated “Edit” terminology instead of the old “Customize” wording. This keeps the guidance aligned with the current interface and helps users follow instructions more easily.
Original PR description
Since we've changed the Customize tab to Edit in `18.4`, this commit adapts the text on /website/info accordingly. task: [6005106](https://www.odoo.com/odoo/project/974/tasks/6005106) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
SEPA Direct Debit XML files no longer include a bank-specific identifier field for all countries. This prevents rejections by Italian banks while keeping the required field for Nordea countries such as Sweden.
Original PR description
### Issue: An unexpected `<SchmeNm><Cd>CUST</Cd></SchmeNm>` node was added inside `<InitgPty><Id><OrgId><Othr>` for all countries Some Italian banks reject SDD files containing this node ### Cause:…
### Issue: An unexpected `<SchmeNm><Cd>CUST</Cd></SchmeNm>` node was added inside `<InitgPty><Id><OrgId><Othr>` for all countries Some Italian banks reject SDD files containing this node ### Cause: https://github.com/odoo/enterprise/commit/3c3c64b511d07fc1ba33c30363972f5b0f7283d6 added `<SchmeNm><Cd>CUST</Cd></SchmeNm>` unconditionally for all countries The original fix was intended for Nordea (Sweden) only, which requires this node explicitly The assumption that other countries would accept it was incorrect ### Steps to reproduce: - Install `account_sepa_direct_debit` and `l10n_it` - Switch to the IT company - In Settings, set SEPA Direct Debit Creditor Identifier to `BE30ZZZ300D000000042` - Create and confirm a Payment (Method: SEPA Direct Debit, any customer and amount) - Create and validate a Batch Payment with that payment - Open the generated PAIN008 XML Before the fix, `<SchmeNm><Cd>CUST</Cd></SchmeNm>` is present opw-6530996 Forward-Port-Of: odoo/enterprise#130304
The time off test now uses fixed dates instead of dates based on when the test runs. This prevents false failures on weekends or non-working days, improving confidence in the system's automated checks without changing user-facing behavior.
Original PR description
## Before: The test relied on relative dates (today + 2 days) when creating a leave request. The behavior depended on the day it was executed. For example, if the test ran on a Friday, the leave request would be created for Sunday, causing the validation to fail because the employee was not supposed to work on that day. ## After: This uses a static date for both the accrual allocation and creating the leave to avoid unnecessary errors. runbot-945745 Forward-Port-Of: odoo/odoo#282190
Pivot report measure options now remain available after users change filters or refresh the view. This prevents configured measures, such as POS order counts, from disappearing from the Measures menu and helps reporting stay consistent.
Original PR description
TL;DR - we lose the measures from arch after a reload, if removed from activeMeasures Step to reproduce: - install pos, create few orders - go to reporting> orders> switch to pivot view - click the…
TL;DR - we lose the measures from arch after a reload, if removed from activeMeasures Step to reproduce: - install pos, create few orders - go to reporting> orders> switch to pivot view - click the `Measures` dropdown, `Order` is already selected - untick it, then apply some filter so that view reloads (ex order date) - reopen `Measures` dropdown, notice `Order` is missing form measures Cause: - view `view_report_pos_order_pivot` has `<field name="order_id" type="measure"/>` in its pivot view https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/point_of_sale/views/pos_order_report_view.xml#L10 - `order_id` is M2O field - Measure is compute from present `activeMeasure` and fields of type `["integer", "float", "monetary"]` https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/utils.js#L89-L120 - when the view is first loaded, `activeMeasure` all the fields with `type="measure"` which is directly passed to pivot's model as a metadata https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/pivot/pivot_arch_parser.js#L59-L60 https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/pivot/pivot_view.js#L41 - when we toggled the `order_id` from measure and reloaded, `order_id` is popped from `activeMeasure` and as it's field type is `many2one` it is not considered for `measures` in `computeReportMeasures` Fix: - maintain the measures from arch separately and feed it to `computeReportMeasures` opw-6416196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285686 Forward-Port-Of: odoo/odoo#278850