Friday, September 11, 2026
39 changes · master
Resolved issues and error corrections
The website theme color editor now keeps edit buttons visually stable when users navigate with the keyboard. This prevents a small but distracting layout jump, improving usability and polish in the website editor.
Original PR description
Steps to reproduce: - Open the website editor. - Open the theme color picker. - Focus an edit color preset button with the keyboard. => The button shifts when it receives focus. Before this commit, a transparent border reserved space outside focus. Since [1], the focus indicator uses a `box-shadow`, so that border disappeared on focus and changed the button size. After this commit, the obsolete border is removed and the button keeps a stable size when focused. [1]: 8f41224083f198c5d86cdf6f43824b42bdc73d36 task-6259086
Inventory screens for batch and wave operations were adjusted to make navigation and setup clearer. Users will see cleaner filtering in planning views, a visible transfer line image, and easier side-by-side source location settings.
Original PR description
Batches and waves were previously merged (see odoo/odoo#280326).Some details on the UX still needs refinements: - On `stock_picking_batch_action`, there is no `groupby` but instead a `search_default_...` filter that needs to be removed for the gantt view. - The 'Batch Transfer Line' image (prev. Wave Picking) is transparent although they are accessible from this view. - Have side by side the two Source Location settings in the Operation Type form view task-6542620
Manufacturing orders now use the newly generated serial number when production is reset and resumed, instead of accidentally producing with an old serial number. The serial number button label was also clarified so users can better distinguish generating new serials from editing existing ones.
Original PR description
This PR addresses a bug introduced in the PR https://github.com/odoo/odoo/pull/277276 To reproduce the bug: 1- Produce a serial tracked product with serial number 00001 for example. 2- Set MO to…
This PR addresses a bug introduced in the PR https://github.com/odoo/odoo/pull/277276 To reproduce the bug: 1- Produce a serial tracked product with serial number 00001 for example. 2- Set MO to progress. 3- Clear the lot_producing_ids, and generate a new one 00002. 3- Produce again. = The MO produces a product with the old serial number 00001 instead of 00002. This happens because while producing the MO, it finds the move already has its own lot_ids but we need to check it's different than the `lot_producing_ids` generated on the MO to re-assign it again. Side improvement: The button `Generate Serial` is now named `Generate Serial Numbers` and becomes `Edit Serial Numbers` whenever there are already multiple generated serial numbers on the MO. This is more relevant to the user now since they now have the ability to set a done MO to progress and change the quantity to produce hence, it makes sense to edit the serial numbers when they are asked to specify a serial number in that case.
The WhatsApp account screen now only shows the Disconnect option to the right administrators and only for accounts that can safely use it. This prevents manually configured WhatsApp accounts from accidentally losing incoming messages and avoids access errors for regular internal users.
Original PR description
It was previously deprecated in a different commit. task-6544628
Fixes a visibility issue where the Update BoM action could be hidden on manufacturing orders when the PLM module was installed. This ensures users can access the action in the appropriate production stages, reducing workflow confusion.
Original PR description
This PR fixes a bug introduced in the PR: https://github.com/odoo/odoo/pull/277276 where Update BoM action on MO now shows when the MO is also in `progress` or `to_close` states but when the module `mrp_plm` is installed the `invisible` attribute of the button is overridden missing the new states. After this PR, the override is now updated to have the new states where the action should also appear.
When users update the shipment weight while adding shipping to a sales order, the system now saves that change before recalculating carrier rates. This prevents outdated shipping prices from being shown and makes rate comparisons more reliable.
Original PR description
Steps to reproduce: 1. Open a Sales Order 2. Click Add Shipping 3. Click `Get all rates` button 4. Change the weight 5. Click `Get all rates` button again 6. Observe that `get_wizard_carrier_rate` was called with the same weight The problem is that the record is not saved before fetching the rates. This commit ensures it happens every time the button is clicked. Also, some code in the `choose.delivery.carrier` is not reusable. This commit fixes these issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Documents where clicking an already selected item in kanban view could stop showing its details. Users can now repeatedly click a selected document without losing the expected selected, focused, and inspected state.
Original PR description
Reproduce * Open Documents on kanban view * Select a record, it is selected, focused and inspected * Click on the record again, it should remain in the same state but is in fact not inspected anymore. * Click on the record again, it should still be selected, focused and inspected and isn't. Cause: render sequence change on updating records from owl3 refactor. Task-6562749
This fix ensures cash basis tax amounts are properly matched when an invoice is reversed with a credit note, even when the transition account is not set for payment reconciliation. This helps keep accounting records accurate and avoids lingering unreconciled tax balances after reversals.
Original PR description
Steps:
---------
1. Activate Cash Basis
2. Set a tax as being Cash Basis
a. The transition account must have Payment Reconciliation == false
3. Create an Invoice with a tax on it, post it.
4. Create a Credit Note for that invoice, post it
The Tax Amount is not reconciled, but it must be.
If the transition account is Payment Reconciliation == true, it works.
Solution:
---------
Before unreconciling, we store the accounts that were previously stored. During reversal, lines that are not reconciled and are part of the move are auto-reconciled.
Most of the reversal reconciliation logic has been moved in the `_post` method, this is because we want this behavior to apply each time we _post and not only when passing through the wizard with a forced reversal.
task-6499274
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA field grouping setting has been moved from the general HR area to Payroll, so it is managed in the right place. This helps keep employee payroll information organized under the correct module and reduces configuration confusion.
Peruvian point-of-sale receipts now wait for the electronic invoice authorization data needed to print a valid legal receipt. The change keeps checkout efficient by delaying PDFs and emails as before, while ensuring the QR code and summary hash are available immediately on the printed receipt.
Original PR description
In Peru, the printed PoS receipt is the legal electronic invoice/receipt (Factura/Boleta Electronica): it must carry the QR code and the summary hash from the signed e-invoice. Since 19.4, PoS…
In Peru, the printed PoS receipt is the legal electronic invoice/receipt (Factura/Boleta Electronica): it must carry the QR code and the summary hash from the signed e-invoice. Since 19.4, PoS invoice PDF/EDI generation became asynchronous by default (deferred to a cron) to speed up checkout, but l10n_pe_edi_pos was never updated to opt out of that for Peru, so the signed data doesn't exist yet when the receipt is printed right after validating the order. Steps to reproduce: ------------------- * Install l10n_pe_edi and activate SUNAT Signature Provider Setting * Create and validate a PoS order and set "invoice" to true * Print the receipt (Full Receipt or Simplified Receipt) > Observation: Neither receipt includes the QR code or the summary hash, so the printed receipt is no longer a valid electronic document. Why the fix: ------------ Forcing the whole invoice (PDF + email + e-invoice) to be generated synchronously would block checkout on a live SUNAT call, and would leave failed orders with no way to be retried by the deferred-invoice cron. PosOrder._generate_pos_order_invoice() now lets the PDF/email stay deferred to the cron as before, but posts the e-invoice to SUNAT synchronously on its own (no PDF, no email), so the receipt gets its QR code/hash right away. This matches the pattern already used by l10n_sa_edi_pos (generate_pdf=false + a synchronous EDI-only step), as opposed to l10n_co_edi_pos, the only module forcing generate_pdf=true. A chatter message is posted on the invoice if SUNAT rejects it, since calling the EDI step directly bypasses the notification that account.move.send would otherwise post. opw-6426510 Forward-Port-Of: odoo/enterprise#126345
Scheduled financial reports now use the intended company instead of including data from every company available to the scheduler. This helps businesses with multiple companies receive accurate report emails for the selected company only.
Original PR description
This commit https://github.com/odoo/odoo/commit/94ef1127dfa8af17795f39590c8a37edfa117994 changed how with_company() works to ensure it only adds a new company to the allowed companies. This made the reports options include all companies when sent through the cron (since crons have every company enabled by default). This commit fixes this issue by relying on the context key allowed_company_ids instead of with_company(). task-6505248 Forward-Port-Of: odoo/enterprise#129728
The Belgian salary contract demo data now includes the CP200 category in the basic demo setup. This helps ensure demo scenarios better reflect expected Belgian payroll conditions and avoids issues when using or testing the sample data.
The WhatsApp account screen now hides the Disconnect option for manually configured accounts and limits it to WhatsApp administrators. This prevents accidental service disruption where Meta stops sending messages while Odoo still shows the account as configured, and avoids access errors for regular internal users.
Original PR description
Problem: The Disconnect button showed on every account holding a token, so manually configured accounts got it too. Pressing it tells Meta to stop sending messages to the database, then fails while…
Problem: The Disconnect button showed on every account holding a token, so manually configured accounts got it too. Pressing it tells Meta to stop sending messages to the database, then fails while clearing the token, which a manual account needs, so Odoo rolls back while Meta does not. The account keeps looking configured and incoming messages stop, and there is no way back from the interface, Meta only allows re-subscribing through the API. The button relied on `show_disconnect`, a computed field reading `token`, which is restricted to WhatsApp administrators while every internal user has read access on `whatsapp.account`. Opening the account form as a regular user therefore raised an AccessError. Solution: Restrict the header to WhatsApp administrators and test the account fields directly in its `invisible`, which hides the button on manual accounts and removes the need for the computed field. Add a safety check on write access in `button_disconnect`. Hiding a button only removes it from the screen, the method stays callable over RPC, and the request to Meta happens before the write that would have been refused. Task-6544628 Forward-Port-Of: odoo/enterprise#130759
This fix prevents an error when users open the My Events portal page in community-only installations. The event date used for sorting is now available in the community event module, so event registrations can be listed reliably without requiring enterprise add-ons.
Original PR description
Purpose ======= Fix the SQL error when accessing '/my/events' without the enterprise addons. Specification ============= The 'event_begin_date' field is only stored when 'event_enterprise' is installed meaning the 'order by' done on the field when loading the '/my/events' page would fail with an SQL error. => Moving the 'store' on the field from the enterprise module to community. This was previously not spotted as the 'event_enterprise' was auto-installed because all its dependencies were also auto-installed if the enterprise addons was found. Task-6560355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a user fixes an accidental mention in a message, Odoo now correctly removes the replaced contact from the notification list. This prevents unintended recipients from being notified when their name only appears as part of a longer corrected mention.
Original PR description
When a user mentions the wrong partner and corrects it by continuing to type, e.g. picking "John" by mistake, typing further so the text becomes "@ John Doe" and picking "John Doe" in the suggestion…
When a user mentions the wrong partner and corrects it by continuing to type, e.g. picking "John" by mistake, typing further so the text becomes "@ John Doe" and picking "John Doe" in the suggestion popup, the discarded first pick stays in the composer's mentioned partners. On post, mentions are validated by searching the body for "@<name>", and "@ John" is found inside "@ John Doe", so the partner the user tried to replace is kept in the recipients and gets notified even though no mention of them remains visible in the message. Validate mentions from the longest mention text to the shortest, counting the occurrences of each text and blanking them out before looking for shorter ones. A partner whose mention text only appears inside a longer mention is dropped, while distinct partners sharing the same name each consume one occurrence. Steps to reproduce: - Create contacts "John" and "John Doe" - On any record, open the chatter and type "@John", pick "John" by mistake, then keep typing " Doe" and pick "John Doe" in the suggestion popup to correct it - Send the message => The message is also sent to "John" although only "@John Doe" appears in the body. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287267 Forward-Port-Of: odoo/odoo#284239
The product catalog order line now correctly receives stock-related details such as tracking and minimum quantity information. This prevents missing or incorrect information when working with sale order lines in field service planning flows.
Original PR description
- https://github.com/odoo/odoo/pull/287603 See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in Documents where clicking an already selected file in the kanban view could incorrectly remove its inspected state. This keeps the file selection experience consistent and avoids confusion when users review documents.
Original PR description
Reproduce * Open Documents on kanban view * Select a record, it is selected, focused and inspected * Click on the record again, it should remain in the same state but is in fact not inspected anymore. * Click on the record again, it should still be selected, focused and inspected and isn't. Cause: render sequence change on updating records from owl3 refactor. Task-6562749
Event registrations in the customer portal now sort more reliably by event start date. This helps users see events in the expected order and avoids confusion when browsing registrations.
Original PR description
Moving the store on 'event_begin_date' from 'event_enterprise' to 'event (cf com PR) Task-6560355
Time off requests now keep the correct duration when an automation rule creates an activity during save. This prevents one-day requests from incorrectly appearing as zero days, improving reliability for HR workflows that use automated reminders or tasks.
Original PR description
Problem: A time off request is saved with a duration of 0 days instead of 1 day as soon as an automation rule on Time Off has an action that creates an activity. Cause: `_compute_field_value` runs…
Problem: A time off request is saved with a duration of 0 days instead of 1 day as soon as an automation rule on Time Off has an action that creates an activity. Cause: `_compute_field_value` runs the actions while the fields of the computation it wraps are still protected and not written yet. On `hr.leave` the actions run from a computation nested in `_compute_date_from_to`, so `date_from` is empty when the activity notification reads `display_name`, and `_compute_duration` stores 0. Setting `date_from` afterwards does not mark `number_of_days` to compute again since it is protected. Solution: Extract the snapshot `_filter_pre` already does into `_keep_to_compute` and wrap the post filter and the actions with it, so the fields depending on the running computation stay to compute. Same treatment as 488419a5ca49 (odoo/odoo#243611) on the pre filter. Steps to reproduce: - Enable the developer mode. - Go to Settings > Technical > Automation Rules and create a rule on the Time Off model with the trigger On create and edit. - Add an action of type Create Activity, set its Responsible to another user, and save. - Go to Time Off > New, pick an employee and a time off type, and request one working day. - Observe that the request shows a duration of 0 days. Ticket [link](https://www.odoo.com/odoo/project.task/6498783) opw-6498783 Forward-Port-Of: odoo/odoo#287536 Forward-Port-Of: odoo/odoo#286791
New employee versions now appear immediately in the correct place on the timeline based on their effective date. This prevents confusion when HR users add current, past, or future versions and removes the need to refresh the page to see the right order.
Original PR description
**Issue** Creating a new employee version places the timeline tab at the wrong end of the timeline instead of its correct chronological position. It only corrects itself after a page refresh. **Steps to reproduce** 1. Open an employee record. 2. Click the **+** button on the timeline to add a new version. 3. Select an effective date (e.g., between two existing versions) or in the future. 4. The new tab appears at beginning of the timeline instead of in chronological order. **Solution** Override `getSortedItems` in the timeline widget to explicitly sort elements by date during the render cycle. This ensures dynamically added versions are instantly placed in their correct chronological position. Added UI tests to verify the ordering. task-6525190
Inventory overview buttons now appear correctly without requiring batch picking to be enabled. Related settings were also aligned so transport management correctly depends on batch, wave and cluster transfers, reducing configuration confusion.
Original PR description
During the PR [^1], the group `stock.group_stock_picking_batch` was accidentally added on the buttons to quickly see the number of opened pickings by operation type. As result, those buttons weren't displayed until the batch picking setting was enabled. This commit fixes that issue. [^1]: https://github.com/odoo/odoo/pull/282884
Mobile dashboard carousels now use the correct figure size when calculating their layout. This prevents carousel content from appearing at the wrong size on phones, improving readability and usability for dashboard users.
Original PR description
Now the carousels in o-spreadsheet use the figure dimension to compute their layout. It means that the previous implementation of the mobile dashboard where we gave the wrong figure size and relied on the css to resize the figure was not working anymore. This commit correcly size the figure POJO passed as props of the mobile dashboard figures. Task: [6534166](https://www.odoo.com/web#id=6534166&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a purchase stock test setup issue that occurred only in empty databases without demo data. It helps ensure Odoo's automated checks can run reliably in minimal installations, reducing false test failures for developers and maintainers.
Original PR description
Steps to reproduce ------------------ 1. install purchase_stock in a database without demo data 2. run any test in TestReorderingRule 3. observe the error: can't write on invisible field 'tracking' Note: This fix is only relevant when you run the test on an empty database, the demo data enables the Lots & Serial Numbers. Forward-Port-Of: odoo/odoo#286519
This fixes the Record button used for creating or capturing web tours after an internal refactor changed where the recorder is accessed. Business users and testers can again start recording tours from the tour list without hitting a broken action.
Original PR description
… refactor The button called `tour_service.startTourRecorder()`, but that method moved to `TourRecorderPlugin`, exposed on `TourPlugin` as `recorder`. closes odoo/odoo#287203 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 prevents test sessions from being unexpectedly rotated during login checks. It makes automated test results more consistent and reduces false failures, helping teams trust test outcomes without changing customer-facing behavior.
Original PR description
The test harness patches the CryptContext object to spend less time hashing to decrease total test runtime. Because the hash parameters have changed, every first login (per transaction) per user will result in a hash rotation. The session_id is also rotated when the password hash rotates. When multiple requests are sent to the server while a session rotation is underway, the session datastore holds either a valid, or expired, or logged-out user session. This is a source of indeterminism in tests that can be prevented by always returning None value for replacement hash. REF Runbot; https://runbot.odoo.com/odoo/error/242811 REF Runbot; https://runbot.odoo.com/odoo/error/233722 Forward-Port-Of: odoo/odoo#287350 Forward-Port-Of: odoo/odoo#285710
This fix stops manufacturing orders from copying display-only sales order lines onto stock moves. It helps keep manufacturing and inventory records accurate by preventing non-product sales lines from being selected or carried forward.
Original PR description
Issue: ====== before this commit, user was able to select a display SOL and at MO confirmation the SOL was copied to the stock move, so we end up with a stock move linked to a display SOL, which is not correct. Solution: ========= - add a domain on the SOL field as first guard layer - add check on the SOL on MO confirmation to prevent copying a display SOL to the stock move opw-6473017 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287491 Forward-Port-Of: odoo/odoo#286534
Fixes several Belgian payroll issues affecting CP200 sectoral bonuses, including eligibility for departing employees, bonus caps, prorated amounts, and gross income reporting. This helps ensure final payslips, tax forms, and payroll declarations reflect the correct bonus amounts.
Original PR description
- Employment bonus cap read 'BONUS_ONSS' / 'BONUS_TOTAL'. Neither rule exists Use ONSS_BONUS. - Eligibility only checked contract_date_end, which is set on the employee only once the departure is applied. Accept departure_date too, like the eco-vouchers rule. - BONUS_GROSS was missing from the monthly structure: empty total gross on the payslip, and the 281.10 declared the tax without the income. and BONUS_GROSS and BONUS_PP now display only when non zero. - Worked day lines credited only the immediate parent category, every other path walks the whole chain, now it goes up the parent chain recursivly - Drop the unused bonus withholding helper and an unreachable guard in the prorata loop. task - 6032929
Users who request a French PDP migration will now see a clear, consistent message instead of misleading timing information. This helps reduce confusion by avoiding the previous promise that availability would happen "tomorrow" when that was not reliable.
Original PR description
Currently when the user requested a migration, we don't show it in any way to the user, and the only timeline we give ("available tomorrow") is completely false. Because we don't have any field we could use for this client-side (maybe from 19.3 we can use the catch-all-json field) So just make the message same for everybody.
no-task
Forward-Port-Of: odoo/odoo#285599
Forward-Port-Of: odoo/odoo#283594Website builder users can now click inside editable navigation link text without the cursor jumping to the start of the link. This makes editing menu links smoother and prevents small but frustrating text editing interruptions.
Original PR description
Problem: Clicking inside a navigation link in website builder causes the caret to jump to the start of the link element. Cause: `LinkPlugin` unconditionally reset the selection to the start of non-editable link elements, ignoring whether the anchor node was inside an editable child element. Solution: Do not reset selection if the anchor node is inside a `contenteditable` element. Steps to reproduce: - Open website builder. - Click inside a navbar link to place the caret. => Caret no longer jumps to the start of the link. opw-6535386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287479 Forward-Port-Of: odoo/odoo#286527
This update corrects how the Belgian payroll expense module connects to the employee form. It helps ensure mobility budget benefits can be archived without errors caused by the form referencing the wrong underlying view.
Original PR description
…rm view Fix the inherit-id of the hr.employee form view in l10n_be_hr_payroll_expense module to match the correct view id. The previous inherit-id was incorrect, which could lead to issues when trying archive mobility budget benefit task-6542045
Campaigns created from an existing marketing automation template now correctly link their generated mailings to the new campaign. This ensures the Mailings button shows the real number of mailings, helping users verify campaign setup at a glance.
Original PR description
Issue ------ Wrong mailing count in the mailing stat button in the campaign form. How to reproduce ------ 1. Open marketing automation 2. Click `New` to create a new campaign 3. Choose an existing template 4. See the `Mailings` stat button The mailing stat button shows 0 but it must display the number of mailings that are used in that campaign. Fix ------ When loading a template, and after the activites and mailings have been created, set the campaign_id of the created mailings to newly created campaign. task-6564215
Changing a Belgian employee’s contract start date no longer overwrites a manually selected joint committee. This preserves payroll setup choices for student employees while still applying standard defaults when appropriate.
Original PR description
Steps to reproduce: - Create a Belgian employee, select Student and choose a joint committee. - Save the employee, then set or change the contract start date. - The committee is replaced by the default or cleared. Task 6542868
The website mega menu now keeps proper side spacing when viewed on mobile. This prevents menu content from touching the screen edge, improving readability and the overall mobile website editing experience.
Original PR description
Steps to reproduce: - Open a website in mobile preview. - Add a mega menu and select the "Odoo Menu" template. - Open the mega menu. => Its content touches the left edge of the mobile panel. Before this commit, the mega menu rework [1] removed the horizontal padding override required by nested `.container` elements. After this commit, mega menu containers keep the expected grid gutter on mobile. [1]: https://github.com/odoo/odoo/commit/ff5423bc3aa75e47b210ce98f3efba8c75459a5a
This fixes VoIP so the same user can receive calls reliably when signed in from multiple browser tabs or devices. It also aligns allowed extension numbers with the phone service range, preventing invalid extension setups and keeping configuration simpler.
Original PR description
## [FIX] voip: one registration binding per softphone window Asterisk identifies a registration binding by its Contact URI alone: the registrar compares candidates with pjsip_uri_cmp() and names the…
## [FIX] voip: one registration binding per softphone window Asterisk identifies a registration binding by its Contact URI alone: the registrar compares candidates with pjsip_uri_cmp() and names the stored object after the MD5 of that URI. Neither `+sip.instance` nor `reg-id` is consulted, RFC 5626 section 5.4.1 not being implemented on the inbound registrar side. Every window of a user therefore advertised the same Contact and collapsed into a single binding, so only the last one to REGISTER could be rung - across tabs and across devices alike. The discriminator has to be a URI parameter rather than part of the user part: res_pjsip_path.c matches the user part against the AOR name to decide whether to attach the edge proxy's RFC 5626 flow-token Path, and without that Path an inbound INVITE cannot be routed to the browser at all. Parameters after the host are ignored by that lookup yet do make two URIs compare unequal, so `x-odoo-unique` buys distinct bindings at no cost to the Path. It is assigned once per user agent instead of being computed in the configuration getter, so that reading the configuration twice cannot yield two different Contact URIs. ## [FIX] voip: restrict voip.extension range Before this commit: - voip module validates against voip.extension number length: between 100 and 99999 - phone service configures tenants to allow extensions between 10 and 9999 As there is a discrepancy between those 2, we decided to allow the ranges that overlap between both parts. So, after this commit: - voip module allows extensions numbers between 100 and 9999. Rationale We decided to remove the 5-number range on that part instead of adding it in the phone service part, because: - 9900 extension numbers is plenty enough and it can lower a bit the complexity of the asterisk dialplan, which makes the asterisk dialplan regeneration more lightweight - it is easier to add a range in the future than remove one, due to migration nightmare
This fix moves a shared styling helper into the core web module so pages can build correctly even when the editor module is not installed. It prevents styling errors on bare databases and removes an unintended dependency between modules.
Original PR description
Since Commit[1], `bootstrap_review_frontend.scss` calls `increase-contrast()`, which web never defined: it lives in web_editor, now html_editor. This hidden dependency went unnoticed as long as the editor module was auto-installed on every database. The issue surfaced as a side effect of Commit[2] which added `http_routing` to html_editor's dependencies. `http_routing` is not auto-installed, so `html_editor` no longer gets installed on a bare database and `increase-contrast()` is undefined. [1]: https://github.com/odoo/odoo/commit/7c69596e7997 [2]: https://github.com/odoo/odoo/commit/bff477da4753 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a display issue where feature icons could become hard to read when a website used a dark color palette. Icons now keep the right contrast whether they use a custom background color or the default shaped icon background, improving readability and visual consistency.
Original PR description
Steps to reproduce: - Select a dark website color palette. - Drag and drop a "Features" snippet onto the page. => The icons use dark text over their dark `bg-o-color-3` backgrounds. Before this commit, [1] gave shaped icons a dark fallback color to make their default light backgrounds readable. The shaped icon selector was more specific than `bg-o-color-*`, so it also overrode the contrast color computed for explicit backgrounds. After this commit, the fallback applies only without a `bg-*` class. Explicit backgrounds keep their automatically contrasted color while icons with the default background remain readable. [1]: c5e16ae task-6485048 Forward-Port-Of: odoo/odoo#287386
Fixed a visual spacing issue in Marketing Automation timelines that could show an unwanted gap after a related kanban view update. This keeps campaign timelines looking consistent and easier to read for users.
Original PR description
Make the gap reset rule more specific, so no gap shows up after the nested kanban fix in community. COM: https://github.com/odoo/odoo/pull/287428 task-6527607
This update adjusts automated tests so they behave correctly when Odoo is configured to use a custom database notification function. It prevents false test failures in messaging and Viva.com payment flows without changing behavior for end users.
Original PR description
# [FIX] bus: adapt test to custom imbus & cron_trigger notifications Similar as to https://github.com/odoo/odoo/pull/178986, When a custom postgresql function is used (`ODOO_NOTIFY_FUNCTION` environment variable is set), testing to listen to imbus should be skipped # [FIX] pos_viva_com: adapt test to custom imbus notifications Similar as to https://github.com/odoo/odoo/pull/178986, When a custom postgresql function is used (`ODOO_NOTIFY_FUNCTION` environment variable is set), the webhook confirmation notification cannot be relied upon to reach the client via `listen imbus` in time. This makes the client fall back to polling `viva_com_get_payment_status` with the real session id, which the test's mock doesn't expect, causing the tour to time out.
This fixes an issue where some SEPA direct debit payments could be created without the required mandate linked. The change helps ensure direct debit payment flows remain reliable and avoids failures caused by missing mandate information.
Original PR description
When registering a payment (e.g. through the payment register wizard), the mandate was not always linked to the created payment, leaving `mandate_id` empty and breaking SEPA direct debit…
When registering a payment (e.g. through the payment register wizard), the mandate was not always linked to the created payment, leaving `mandate_id` empty and breaking SEPA direct debit flows(`account.direct.debit.mandate()` instead of the expected mandate). During `create`, the `_validate_mandate_id` constraint reads `needs_mandate_of_type`, a non-stored computed field. Its computation triggers a recompute of `payment_method_id`, which re-enters the same constraint while `needs_mandate_of_type` is still being computed. The ORM then protects the field: reading it returns a bogus `False` and caches it. `_compute_mandate_id` consumes that poisoned value and permanently stores an empty `mandate_id`, since its actual dependencies never change afterwards. Fix: make `_compute_needs_mandate_type` and `_compute_mandate_id` depend on `payment_method_line_id` instead of `payment_method_id`, so mandate is computed without reading a field that can be in a protected context. note: I was only able to replicate the runbot error through testing, and not through web ui/functionally. runbot-error-946999 runbot-error-947001 runbot-error-947010 runbot-error-947011 runbot-error-947012 runbot-error-947013 runbot-error-947014 runbot-error-947015 runbot-error-947016