Daily updates from Odoo
Friday, October 10, 2025
71 changes · 19.0
Enhancements to existing features
Website users can now create pages with AI through a smoother, more guided flow. This helps teams launch website content faster and with less manual setup.
Website users get an improved experience when creating pages with AI, making it easier to start new website content. This helps teams build pages faster and with less manual setup.
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
Point of Sale users can now mark a card terminal payment as completed when the payment is stuck waiting for card confirmation. This gives staff a fallback when the terminal processed the payment but Odoo did not receive the status update, reducing checkout delays and avoiding unnecessary payment retries.
Original PR description
Current behavior before PR: If we faced an issue with a terminal payment while the `line.payment_status` being "waitingCard", only possible option for the user would be to "Cancel" the payment and try again or choose another payment method. This is an issue for the cases where the payment went through on the terminal but Odoo didn't update the status for some reason. Desired behavior after PR is merged: We add the possibility to "Force done" while the status is "waitingCard" to avoid blocking the user in such situations and have a possible fallback. opw-4978772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229557 Forward-Port-Of: odoo/odoo#228406
This pull request updates the Accounting PDF Reports add-on, including report definitions, account type data, model logic, and translations. It appears intended to refresh or customize accounting reporting capabilities, which may affect how finance teams generate and view PDF financial reports.
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
Users can now close the image description box in the HTML editor by pressing the Escape key. This makes editing images smoother and more consistent with common keyboard behavior.
Original PR description
This PR aims to ensure that image description box gets closed when pressing escape key. task-5114224 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail chat composer now shows relevant channel command suggestions when users type '/'. This makes it easier to discover and use chat commands without needing to remember them manually.
Original PR description
This commit adds the ability to show channel command suggestions when typing '/' in the html composer. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Recruiters can now generate more than one salary offer for the same applicant from the applicant view. This makes it easier to revise or resend offers during the hiring process without unnecessary restrictions.
Original PR description
Purpose: Modified the visibility attribute on the Generate Offer button in the applicant view so the it allows the generation of multiple offers for the same applicant Task ID: 5088931
Additional automated tests were added to confirm that appointment booking capacity, unavailability, cart bookings, invoice confirmation, and event creation work as expected. This helps reduce the risk of booking errors across paid appointments and website appointment sales.
Original PR description
\* = website_appoinment_sale, appointment_account_payment Add tests to ensure correct behaviour for the various scenarios. The following tests are added: - Users/resource's capacity computation when manage capacity is on and off. - Unavailability computation of users/resources in the `calendar.event`. - Check the bookings of user/resource in the cart for the availability after the invoice is confirmed. - Creation of the actual event when the booking from the cart is confirmed. Task-4919317 Forward-Port-Of: odoo/enterprise#91676
Manufacturing teams can now control the order of quality checks and instructions within work operations. This restores a previously available capability, making shop floor guidance easier to organize and follow.
Original PR description
- Sequence was added to give flexibility in ordering quality points inside operations. **Note:** this was already there in past versions, it was just forgotten in the latest redesign: https://www.odoo.com/odoo/project/966/tasks/5005235 Task: 5110982
The employee salary contract testing flow was updated to stay aligned with recent underlying changes. This helps keep automated checks reliable and reduces the risk of unnoticed issues in salary contract workflows.
Original PR description
This commit handles the change in test case due to the modification in the following commit [1]. [1]=https://github.com/odoo/odoo/pull/227819/commits/360b384ba4e24
This update improves internal test helpers used by the website editor so tests wait properly for sidebar updates and related background work. It helps reduce flaky automated tests, making future website editor changes safer and more reliable without changing the user experience.
Original PR description
We need a helper to wait enough Forward-Port-Of: odoo/odoo#226582
Resolved issues and error corrections
This fix prevents errors when generating Mexican CFDI or invoice documents if a related landed cost has not been validated and therefore has no date. It also blocks users from creating landed costs directly from the lot form, reducing the chance of incomplete landed cost records causing document generation failures.
Original PR description
Previous this commit you are able to create and set a landed cost through the lot form view without validating the landed cost. This caused a traceback later on when generating the CFDI or invoice document when trying to get the formatted dates. Since a non validated landed cost might not have a date, this raised an error. This commit targets to fix this issue by expecting that a landed cost might not have a date and also not allow through the form lot view to create a landed cost target: 19.0 -> master task-none (feedback from mial)
Fixes an issue where creating a new bank statement line from a copied bank journal could crash, especially when using a foreign currency. The system now keeps the transaction linked to the correct journal, helping accounting users enter bank transactions reliably.
Original PR description
The system will crash with error when user tries to create new bank statement line. **Steps to produce:** - Install `Invoicing` module without demo data. - Go to `Configuration > Journals` and…
The system will crash with error when user tries to create new bank statement line. **Steps to produce:** - Install `Invoicing` module without demo data. - Go to `Configuration > Journals` and duplicate the default Bank journal to create Bank (Copy). - Go to `Dashboard` and Click on 3 dots of Bank(Copy) and click on `Transactions`. - Create a new transaction and set the Statement also(Create new and assign it). - Go to that statements and Add a line and set the foreign currency as `USD`. **Error:** ```py ValueError: Wrong value for account.bank.statement.journal_id: account.journal(7, 6) ``` **Cause:** - When there are two Bank journals and the user is not in the default one, creating a new transaction in the statement sets the journal for that transaction to the default Bank journal. However, during computation, this causes an error from [here] because `statement.line_ids.journal_id` contains two different journals.. **Solution:** - Added `default_journal_id` to the context to ensure the correct journal is used when creating new transactions. [here]: https://github.com/odoo/odoo/blob/34409128de0bb84cdee309b031b307c46d8b07c7/addons/account/models/account_bank_statement.py#L178 **sentry-6928858335**
This fixes an issue where some deeply nested website content, such as product eCommerce descriptions, could not be translated when a second website language was enabled. Businesses can now reliably translate this content, improving multilingual storefront management.
Original PR description
Scenario: - enable second language on website - go to /shop/1 and try to translate description_ecommerce Result: this is not translatable Cause: Since at least…
Scenario:
- enable second language on website
- go to /shop/1 and try to translate description_ecommerce
Result: this is not translatable
Cause:
Since at least https://github.com/odoo/odoo/commit/b455ea85853dfc19ed01e33986ad270cf80ee5d6 the
contenteditable attribute in ContentEditablePlugin is not set on an
element if it has a contenteditable ancestor.
TranslationPlugin disable all editable nodes containing editable nodes.
So with this combination, if we had a node for example:
```
<div class="oe_editable" data-oe-model="product.template" data-oe-id="1"
data-oe-field="description_ecommerce" data-oe-type="html">
<div>
<span class="oe_editable" data-oe-model="product.template"
data-oe-id="1" data-oe-field="description_ecommerce">
test
</span>
</div>
</div>
```
the contenteditable was added to the parent div.oe_editable, but was
removed by TranslationPlugin so the "test" text was not translatable.
Fix: move the code that adds data-oe-readonly class in the
after_setup_editor_handlers so it is run before contenteditable
attributes are set.
opw-5128618
Forward-Port-Of: odoo/odoo#230169Accessing a course category through an embedded slide link no longer causes an error page. Users are redirected back to the course homepage instead, keeping the learning experience stable when an invalid or category-only slide link is opened.
Original PR description
When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs. Steps to reproduce: --- - Install `website_slides` module - Go to the Website and click on the…
When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs. Steps to reproduce: --- - Install `website_slides` module - Go to the Website and click on the `Courses` menu. - Then go to `/slides/embed/<int:slide_id>` route. (http://localhost:8069/slides/embed/7) - The error will occur. Traceback: --- `ValueError: 7 is not in list` At [1], `slide_content_ids` contains the IDs of `channel content`. However, we are trying to access a slide from the `channel category` in URL. As a result, at [2], when attempting to find the index of the slide in `slide_content_ids`, an error occurs because the slide ID actually belongs to `slide_category_ids` and is not present in `slide_content_ids`. Solution: --- Added a special case for category slides — if the slide is a category, redirect to the channel homepage. [1]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L120 [2]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L121 sentry-6572999628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225374
This fixes a recent issue in the Adyen payment integration caused by an incorrect customization hook. It helps ensure payment provider behavior remains reliable for businesses using Adyen to process payments.
Original PR description
Commit [efc2788](https://github.com/odoo/odoo/commit/efc2788) introduced the bug by bad method override.
The time off request summary card now displays hourly leave amounts in a shorter, clearer format. This prevents overly long text and makes the side summary easier for employees and managers to read.
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 Forward-Port-Of: odoo/odoo#230693 Forward-Port-Of: odoo/odoo#227631
Fixes the website announcement scrolling snippet so it restarts reliably after edits and previews correctly for keyboard users. Translation editing now uses a standard Odoo dialog instead of a browser prompt, making the website builder experience more consistent and accessible.
Original PR description
**[FIX] website: properly restart AnnouncementScroll interaction** Commit [e1cc670] introduced the `s_announcement_scroll` snippet, with an interaction and some options. The way the interaction was…
**[FIX] website: properly restart AnnouncementScroll interaction**
Commit [e1cc670] introduced the `s_announcement_scroll` snippet, with an
interaction and some options. The way the interaction was restarted
after each option change was hacky, which is what this commit intends to
fix.
We also make sure the preview is working both on hover and when focusing
with Tab.
**[FIX] website: use a dialog for AnnouncementScroll translation**
Commit [e1cc670] added the `s_announcement_scroll` snippet, using a
browser prompt to update the translation of its text. We would rather
use an Odoo dialog.
In the same time, we introduce a resource `mark_translatable_nodes`
called in the `TranslationPlugin`. This will allow a better separation
of concerns between what is the core translation setup and what is
specific to some snippets or elements on the page.
**[FIX] website: use `.preview.scss` pattern in add dialog bundle**
Commit [ad6e2d3] extracted preview-specific CSS styles from `.edit.scss`
files, in order to load the strict minimum with the bundle. We will use
the same kind of pattern for the preview styles, by suffixing files with
`.preview.scss`, like what is already the case with `.preview.js`
interactions.
[ad6e2d3]: https://github.com/odoo/odoo/commit/ad6e2d3857a87a0dfec93c2bcc597328ef21ba00
[e1cc670]: https://github.com/odoo/odoo/commit/e1cc6702a4416204e446d51fdfe047d4ebfd402c
task-5069849This fixes Italian fiscal receipt printing when the receipt screen is skipped in Point of Sale. Receipts now print for the completed sale instead of failing or using a newly created order, helping stores avoid missing fiscal tickets during checkout.
Original PR description
This PR fixes two related bugs happening when printing a receipt with the Italian Fiscal printer First, before this PR, if the option to skip the receipt screen was ticked, then the receipt would…
This PR fixes two related bugs happening when printing a receipt with the Italian Fiscal printer First, before this PR, if the option to skip the receipt screen was ticked, then the receipt would never print. This was caused by the printing logic being implemented on the receipt screen instead of on the pos itself. steps to reproduce: 1. install l10n_it_pos 2. configure one pos 3. configure the IT printer 4. select to skip the receipt screen (print automatically) 5. open the pos 6. make a sale => no ticket printed and the chrome console shows a printer error With this new verison the printing logic was moved to the pos so that printing of fiscal receipts with the italian fiscal printer works, even when receipt screen is skipped. This put to light another potential bug related to how the `order` variable was treated. Before this PR, the printReceipt logic in the module would not pass the order to be printed. This can become a problem upon context changes, where `pos.get_order()` does not return the completed order, but a newly created one. This can for example happen when skipping the receipt screen with the option to "print automatically" (iface_print_auto). After this PR, we keep order as an argument, so we always print the last completed order and not a newly created one. opw-4882480 Forward-Port-Of: odoo/enterprise#96346 Forward-Port-Of: odoo/enterprise#91412
This fixes a problem where sending an email with an attached .eml file could fail if the attachment contained accented or other non-ASCII characters. Odoo now handles these attached email files in a way that preserves their content and allows the outgoing message to be sent reliably.
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#230384 Forward-Port-Of: odoo/odoo#223790
Pasted tables now keep the expected Odoo table styling and handle content copied from external tools more reliably. This helps users paste tables from sources like Google Docs without losing formatting or creating empty table cells that behave incorrectly.
Original PR description
### Purpose of this PR: - Ensure that pasted table elements get the standard classes: `table, table-bordered, and o_table.` - When content is pasted from other source (e.g., Google Docs inside iframe), attribute nodes coming from another JavaScript context do not match the `Attr` prototype of the current context. Use `item.nodeType === Node.ATTRIBUTE_NODE` instead of `instanceof Attr` to detect attribute nodes. - Insert a base container into empty `<td>` elements when pasting tables from external sources. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230723 Forward-Port-Of: odoo/odoo#230208
This fix prevents a stock barcode test from failing randomly when validation happens before a previous save is fully complete. It makes automated checks more reliable without changing normal user workflows.
Original PR description
Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is: - We edit a move line lot in the form view; - We save it; -…
Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is: - We edit a move line lot in the form view; - We save it; - We validate the operation. The validation is done by a barcode scan (`OBTVALI`) but since [1](https://github.com/odoo-dev/enterprise/commit/b3a855a870d1861515abaff8683081a39f95558f), barcodes scanned when the user is somewhere else than in the barcode lines view are skipped. With a little bit of bad luck, the tour scans `OBTVALI` while the save from the form view is not finished yet and thus, the scanned barcode is ignored. To reproduce that, run the test `test_scrap_change_source_location` locally in debug mode and add a throttling (eg.: Fast 4G) before to run the tour. To solve the issue, finetune the `validateBarcodeOperation` default trigger, so the error won't happen in this tour and other similar contexts. Runbot build error: [232331](https://runbot.odoo.com/odoo/runbot.build.error/232331) Forward-Port-Of: odoo/enterprise#96542
This fixes an issue in the HTML editor that could trigger a JavaScript error when inserting content. The change helps keep editing actions stable and prevents interruptions for users working with rich text content.
Original PR description
In `dom.insert`, the variable `container` was being redefined to a constant within a `while` loop, making it impossible to use the original variable within the loop. This caused an `Uncaught Javascript Error` ("Cannot access 'container' before initialization") whenever trying to access it within the loop but above the redefinition. This commit renames the constant to a previously unused name.
opw-5053872
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#230085Fixed an issue in bank reconciliation where choosing a write-off account with a default tax could remove an already matched bill or invoice. This helps accounting users keep their reconciliation work intact and avoid repeating matches.
Original PR description
In the Bank reconciliation widget, users can click a button to set the account to write off the remaining balance. However, if the chosen account has a default tax set, the widget will lose any existing matches with invoices. Steps to reproduce: - Have an account with a default tax - Create a bill with a total - Create a bank statement for a greater amount - Open the bank reconciliation widget - In the created statement, first add the bill, then click 'Set Account,' and choose the account with tax Issue: Bill matching will be lost. This occurs because we remove and recreate the matching line, but we don't keep the line to be reconciled. opw-5002624 Forward-Port-Of: odoo/enterprise#96006
The Documents app no longer shows an unused tooltip setting on document tags. This avoids confusion for users while keeping the underlying data model stable for compatibility.
Original PR description
The 'tooltip' field was introduced on document tags categories, but after couple of refactors it ended up unused on document tag. As we cannot remove fields from the data model in stable, this commit removes tooltip from the view and marks it as deprecated in the code. opw-4567814 ## Stems from https://github.com/odoo/odoo/pull/210147 https://github.com/odoo/enterprise/pull/79496 # Merge plan - hide `tooltip` in stable - remove `tooltip` in master Forward-Port-Of: odoo/enterprise#86504
Releasing an unused restaurant table no longer leaves behind a needless draft order. Orders already sent to the kitchen are still handled safely so kitchen records stay accurate, while unused orders are removed cleanly.
Original PR description
Steps to reproduce: ------------------------- - Install POS restaurant. - Open any table to order. - Release the table. Issue: ------- - A draft order is created without purpose or use. Cause: --------- - On releasing the table we were not deleting the order, we were just cancelling the order even if it's not useful. Fix: ----- - We have called a proper function to manage the conditions like - If the order is sent to kitchen it will cancel the kitchen ticket to avoid inaccuracy kitchen side and already recorded on server so it will be cancelled and if the order was not sent to kitchen than there is no need of the order so will be removed totally. - We have corrected condition to send order in kitchen as `last_order_preparation_change` will always have some keys with blank values but we need to send data based on the lines changed in lopc. task: 4774814 Forward-Port-Of: odoo/odoo#230853 Forward-Port-Of: odoo/odoo#209209
This fixes an error that could block validation of deliveries created from Point of Sale orders using the ship-later option. Staff can now complete the picking process for affected POS orders without encountering the stock account error.
Original PR description
Validating a stock picking for a POS order currently raises an error. **Steps to Reproduce:** 1) Install Point of Sale(with Demo) 2) Navigate to POS>Configuration>Settings and enable **Allow Ship…
Validating a stock picking for a POS order currently raises an error. **Steps to Reproduce:** 1) Install Point of Sale(with Demo) 2) Navigate to POS>Configuration>Settings and enable **Allow Ship Later**. 3) Create a Storable product(P1) with 0 quantity and make sure it has a productcategory with **Perpetual (at invoicing)** configured. 4) Open a session having this new product. 5) Select P1 and make payment with the shiplater option and close the session. 6) Open Picking for this order. (POS>Orders>Orders open order and click on **picking** smart button) 7) Set the quantity for the product and click on **Validate**. Error: `KeyError: 'stock_output'` Root Cause: Since [this commit](https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229#diff-f7d6ecfdde1475832cb3ed0b2319dc38ecd1c43459363b4494ba16023041a72fL176), the code was refactored and `stock_output` was removed from `_get_product_accounts`. However, it is still accessed at [1], causing a `KeyError`. Fix: Remove `_action_done` method at [1] as it has no longer significance. [1]- https://github.com/odoo/odoo/blob/b81d119fae5f5194334cee94bacffefeb1cd8c6e/addons/point_of_sale/models/stock_picking.py#L133 sentry-6914404210
The EC Sales report now correctly shows the Code filter again. This helps users narrow down sales report data as expected, matching behavior from the previous version.
Original PR description
Before: EC Sales report Code filter was not visible. As custom_display_config options was defined in the generic ec sales list code inside function `_custom_options_initializer` while it should actually be placed inside `_init_core_custom_options`. After: Like 18.4 now EC Sales report Code filter visible task-5109538
This fixes return deadline handling so completed returns keep their original deadline when company reminder settings change. It also ensures companies with their own return deadline settings generate returns using the correct deadline, improving reliability for multi-company reporting.
Original PR description
And remove _inverse_deadline_days_delay since _compute_deadline already does everything. To Replicate: - open the returns - mark as completed or complete at least one return - change the deadline_days_delay for that return type - It doesn't change the deadline of completed returns this is working as expected - change the account_return_reminder_day of the company - now it updates the deadline of already existing returns.
PayPal now appears correctly during checkout when it is the only available payment option. This prevents duplicate PayPal buttons on desktop and restores the missing button on mobile, helping customers complete purchases reliably.
Original PR description
## Versions 19.0+ ## Issue PayPal payment button appears twice on desktop and doesn't show up on mobile if PayPal is the only payment provider. ## Steps to reproduce - Go to Payment Providers and set up PayPal in test mode (use sandbox credentials) - Ensure PayPal is the only provider enabled by disabling all the other ones (even Demo) - Go to the Website shop and buy a product: - Move to the checkout step and see 2 PayPal buttons rendered on desktop view, none on mobile view. ## Cause Commit 2ca31a8b5566e4994c1e12e518e5e6da8f05e7ed didn't check for the `start` override name change and replaced by `willStart`. opw-5151848
Point-of-sale appointment bookings now use the right capacity setting depending on whether capacity is managed, so staff can add or remove resources more reliably. The update also restores missing placeholder text in POS appointment fields and fixes display issues in appointment views.
Original PR description
The waiting list capacity used to be set indirectly via the `total_capacity_reserved` field In [1] it was removed as it was not otherwise used. Meaning we should have set the default wishlist…
The waiting list capacity used to be set indirectly via the `total_capacity_reserved` field In [1] it was removed as it was not otherwise used. Meaning we should have set the default wishlist capacity instead. While doing that we also noticed a logical issue with only using the wishlist capacity, it does not allow adding or removing resources that don't correspond to the capacity that was originally set. Instead we now actually use total_capacity_reserved when the appointment type manages capacities. And let users use the wishlist capacity otherwise. Which allows them to again select resources freely in both contexts. -------------------------- Additionally we fix the missing placeholder in point-of-sale caused by the placeholder html editor plugin being missing from the minimal html editor used there. As well as an incorrect access to a record name in kanban popover. task-5103532 [1]: https://github.com/odoo/enterprise/commit/2aab4dcfbe8491968f0721741efbab894667aefe
This fixes an issue where links selected from the editor could be incorrectly changed when used from non-Website apps, potentially sending users to the website homepage instead of the intended internal page. The change limits that behavior to the Website app, so backend apps like Knowledge keep their internal links working as expected.
Original PR description
Before this commit: we have the function in website to prefix a frontend url with `@` when clicking on the url in linkpopover. However, this function is usually used inside website. It also affects places where the url is an internal redirecting url like `/knowledge/article/33` and prefixing will lead to the website homepage. After this commit: we also check if the current url of the browser is also a frontend url, which means the user is inside the website app. Frontend links will not be prefixed in the backend pages, e.g. in all other apps except for website. The website patch doesn't influence public users as they won't have access to the website app anyways. task-5048403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224605
Selecting “Remote” as a job location in the website Jobs editor now works without triggering an error. This restores the expected dropdown option and helps recruiters or website editors update job postings reliably.
Original PR description
Steps to reproduce: 1. Go to Website → Jobs. 2. Open any job application. 3. Change the Job Location to the option "Remote". 4. A traceback occurs. Before this commit: When selecting a job location, initially no Many2One field is selected, that's why no many2oneid is find. which results in a null value being returned. This caused a traceback error After this commit: The "Remote" option is explicitly included in the dropdown, restoring the previous behavior. Forward-Port-Of: odoo/odoo#220312
This fixes an issue where a newly added expense error message was not set up correctly. Users should now see the intended error instead of a broken or confusing message when the affected expense validation occurs.
Original PR description
in 953fac5, the new error was not given the proper arguments Forward-Port-Of: odoo/odoo#229488
This fixes an issue where formatting such as bold could disappear when users pasted plain text into an empty formatted area. The editor now keeps the selected style for normal text while still cleaning up empty formatting when media content is inserted.
Original PR description
Problem: When text is inserted inside an empty format, the format is lost. Cause: After https://github.com/odoo/odoo/commit/ae33ca3d38d4a5adaad3015f036321d473713638, any empty format gets removed if content is inserted inside. Solution: Only remove the empty format if a media element is added. This preserves styling when inserting plain text inside an empty format. Steps to reproduce: 1. Copy some text from somewhere. 2. In an empty task description, press CTRL+B. 3. Press CTRL+SHIFT+V. 4. Notice that the text is not bold, even though the format was active. task-5136314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230051
Sales orders and invoices no longer crash when they are created for a contact that has no name. The warning message handling now works safely in this edge case, helping users continue sales and billing workflows without interruption.
Original PR description
When creating a Sale Order or Invoice for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install ``sale_management`` with demo data - Enable ``Sale Warnings`` from…
When creating a Sale Order or Invoice for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install ``sale_management`` with demo data - Enable ``Sale Warnings`` from settings - Open ``Azure Interior`` Contact > In Contact, Add Contact > Type: invoice > Save & close - Create a sale order with the newly created partner AND - Create an invoice with the newly created partner Traceback: ``TypeError: unsupported operand type(s) for +: 'bool' and 'str'`` https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/sale/models/sale_order.py#L822 https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/sale/models/account_move.py#L59 Here, ``partner_id.name`` is ``False``, which leads to string concatenation with a boolean in sale warning messages and results in the above traceback. sentry-6912482256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229529
This fix resolves an issue where the analytic distribution field could fail on payroll salary rules because it expected company information that was not available there. Payroll administrators can now edit analytic allocations on salary rules without encountering that widget error.
Original PR description
Before this commit, the widget analytic_distribution has a field dependency on company_id. But this widget is used for the field analytic_distribution in the model "hr.salary.rule" and this model doesn't have a field "company_id". So to solve this issue, this widget is duplicated (with/without company). task-5155490
When payroll teams split one salary adjustment across multiple employees, each individual record now keeps the selected duration type. This prevents limited-duration adjustments from being incorrectly treated as one-time items, helping payroll records stay accurate.
Original PR description
**Issue** When creating individual attachments from a salary adjustment with multiple employees, the duration_type field was not being copied to the individual records causing all split attachments to default to "One Time" instead of preserving the original duration type. **Steps to reproduce** - Go to Payroll > Employees > Salary Adjustments - Create a new Salary Adjustment for multiple employees - Set Duration to "Limited" and create individual attachments - Open any individual attachment, duration shows "One Time" instead of "Limited" Task ID: 5136664
The spreadsheet dashboard layout now aligns better on medium screens, and filter-heavy search panels are easier to navigate. Mobile users also get a wider back button, making the search panel easier to close.
Original PR description
Current behavior before PR: - On medium screens, the navigation panel (share, favorite) was misaligned With the control panel breadcrumbs, taking up extra space and looking off. - When many filters were applied, the search view had a max height with overflow-y-auto, but users couldn’t scroll back to the top. - On mobile, the back button in the search panel didn’t use the full width, making the clickable area too small to close the panel easily. Desired behavior after PR is merged: - Navigation panel aligns properly with breadcrumbs on medium screens. - Search view allows smooth scrolling to the top with many filters. - Mobile back button now takes full width, improving click usability. Task: [4882429](https://www.odoo.com/odoo/2328/tasks/4882429) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when users open the Offers option for a new Mexican employee without wage or yearly cost information set. The payroll calculation now checks that the gross amount is available before using it, allowing the offer flow to continue instead of crashing.
Original PR description
steps to reproduce:
--------------------
1. Install l10n_mx_hr_payroll and hr_contract_salary (load with demo data)
2. Switch to the Mexican company and create a new employee
3. Click on Offers(new)
issue:
-------
A traceback occurs:
`TypeError('cannot unpack non-iterable NoneType object')`
cause:
-------
https://github.com/odoo/enterprise/blob/71cc92c9526234dcd44ec756375647a67729029f/l10n_mx_hr_payroll/data/salary_rules/hr_salary_rule_regular_pay_data.xml#L531
Unpacking fails because **find_rates(gross, isr_table)** returns `None`
when the [gross amount](https://github.com/odoo/enterprise/blob/8b96c67d0555702e88127a77edb6e3b8ef5e58cc/hr_payroll/models/hr_payslip.py#L1157-L1167) is empty. This occurs if wage or yearly costs
are not defined.
solution:
----------
Check that the gross amount is exists before calling `find_rates`
and unpacking its result.
opw-5128275This change adjusts a rental sales order used in testing so it is no longer treated as fully unpaid or empty and filtered out of the POS orders menu. It helps keep the POS rental flow reliable after recent order filtering changes, with no expected impact on normal business operations.
Original PR description
Because of https://github.com/odoo/odoo/pull/230809, it will cause the quotations/orders menu to filter out any sale orders which have an unpaid amount of 0. The test_rental_pos test tries to create a sale order with a quantity of 0 and then settle it in the POS, but because of the filter, the sale order will not show up in the menu causing the test to fail. This PR is to increase the quantity in the sale order to 1 so that the order shows up and the test can be executed properly. Task-5138081
Videos added inside website masonry text blocks now expand to the full width of their available area. This prevents embedded videos from appearing unexpectedly small and improves the visual consistency of edited website pages.
Original PR description
To reproduce: ============= 1- In Website edit mode, drop the "Masonry" snippet. 2- Add a video in one of the text blocks. -> It will appear smaller than expected, with no way to make it larger Why: ==== The child iframe already had width: 100%, but it can only stretch to 100% of its parent container. If the parent container (.media_iframe_video) doesn't have an explicit width, it defaults to its minimum content size. This issue happens specifically in blocks where the columns are display: flex. As a result, the iframe ends up being too narrow despite having width: 100%. Solution: ========= By adding width: 100% to the container itself, it now fills the grid cell, and the iframe inside fills the container. opw-5104640 Forward-Port-Of: odoo/odoo#229001
The attendance system now checks whether an employee had an active contract before marking them absent for a missed check-in. This prevents incorrect absence records for people who had not yet started their contract, improving payroll and attendance accuracy.
Original PR description
To register absence, the cron looks for all employees that did not check in the previous day. However, it was not checking if the employee was in contract for that day. This commit fixes the issue by adding a check on the contract date start. task-4987428 Forward-Port-Of: odoo/odoo#222062
This fix keeps animated text highlights from making website pages scroll sideways on mobile screens. It improves the editing and viewing experience by ensuring highlighted text stays within the page width.
Original PR description
Steps to reproduce: ==================== 1. Open Website Builder and switch to mobile screen 2. Select any word of a text 3. Apply highlight and animation Bug: - Page becomes scrollable to the right Cause: ======= SVG elements default to a `300px` `width`, which can overflow on smaller screens (e.g. mobile). This commit sets a `width` to prevent horizontal overflow. This is the link for the same issue but for vertical overflow. https://github.com/odoo/odoo/pull/215826 Reference: https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/width opw-5120678 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230299
Public-facing mail pages now display their text in the visitor's selected language. This fixes untranslated labels or messages, improving the experience for users on multilingual websites.
Original PR description
Human-readable content defined in public page components isn't translated. This is because we forgot to give Owl a translation function, so it falls back to returning the source terms as they are (identity function). This commit resolves the issue by providing the missing translation function. Task-4493082 Task-5140665 Forward-Port-Of: odoo/odoo#230266 Forward-Port-Of: odoo/odoo#230129
The website test for switching between websites now uses a standard helper instead of custom steps. This makes automated checks more stable and reduces false failures in the testing pipeline, with no expected change for end users.
Original PR description
`snippet_translation_switching_website` was previously using custom steps to switch the website. Though it worked, it was not very deterministic and broke the tour in a few runbot builds. This commit updates the `snippet_translation_switching_website` tour to use the `testSwitchWebsite` helper function instead of custom steps, providing a more reliable and deterministic way to switch websites. runbot-[229696](https://runbot.odoo.com/odoo/error/229696) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230547
Expense journal posting no longer crashes when a company has no accounting chart configured. Instead, users receive a clear warning directing them to complete the required accounting setup, helping avoid disruption during expense processing.
Original PR description
The system will crash with error when user tries to Post Journal Entries of expense. **Steps to produce:** - Install `Accouting, Expense, Payment provider demo` module without demo data. - Create new…
The system will crash with error when user tries to Post Journal Entries of expense. **Steps to produce:** - Install `Accouting, Expense, Payment provider demo` module without demo data. - Create new company (Do not set the country) and switch to that company. - Set the demo payment provider state to `test`. (You may have to create `new journal` and in that `new `suspense account` also.) - Go to `expense` and create new record. - Set the `paid by` as `company` and also set `account` and `employee`. - Click on `Submit` and then click on `Post Journal Entries`. **Error:** `TypeError: 'NoneType' object is not subscriptable` **Cause:** - When we create new company then there is no default chart accounting template is set until we set the country of the company. **Solution:** - If the Chart template is not set in the company, then we simply raise the `Usererror`. **sentry-6920693674** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes an inappropriate demo account from the UK accounting setup and corrects bank and cash account prefixes so they behave like prefixes rather than full account numbers. This helps avoid confusing or unrealistic account defaults when configuring UK localization.
Original PR description
That account is meant to be a demo data, created in `hr_payroll_account It was probably exported without much consideration during this refactor 1017d6278b665e0f00ec63d7ed94a5aaee500682 Same goes for the bank and cash prefixes: having a full number up to the last digit doesn't make sense for a prefix.
Changing the quotation template on a sales order now removes the previously linked quote calculator spreadsheet. This prevents sales teams from using outdated calculator data tied to the old template and keeps the order aligned with the selected template.
Original PR description
Step to reproduce: - Create a new SO - Add a customer and quotation template to the order - Click on quote calculator smart button - Return to sale order (click on SO number in top left) - Change the quotation template - Result: it does not change the quote calculator that is linked to the new quotation template Cause: - Clicking on Quote Calculator creates a copy of the quotation template spreadsheet and links it to the SO. https://github.com/odoo/enterprise/blob/8bc6098335d283e6d210dc788463a8ef8c559b14/spreadsheet_sale_management/models/sale_order.py#L30-L35 - When the quotation template is later changed, the spreadsheet linked to the old template remains attached to the SO. Fix: - On changing the sale_order_template, the old spreadsheet should be unlinked from the SO. - Keeping it linked is inconsistent, as it does not matches the current template opw-4998587 Forward-Port-Of: odoo/enterprise#95861 Forward-Port-Of: odoo/enterprise#93970
Creating a new Helpdesk ticket could fail when a stage had a positive “Days to rot” setting. This change adds test coverage to ensure that scenario stays fixed, helping teams avoid interruptions when logging support requests.
Original PR description
Currently an error occurs when user creates the helpdesk ticket. Steps to Reproduce: - Install the `helpdesk` module. - Go to `Stages` and, in the `Kanban view`, open the `New Stage` record. - Set a value `greater than 0` in the `Days to rot` field. - Go to `Tickets` and click `New`. `TypeError: unsupported operand type(s) for +: 'bool' and 'datetime.timedelta'` This commit adds a test for this [PR](https://github.com/odoo/odoo/pull/230271). sentry-6927500374
Sales orders linked to multiple manufacturing orders can now open their delivery information without causing an error. This prevents disruption for users managing deliveries from split production runs while preserving existing behavior.
Original PR description
Before this commit: ------------------------- When multiple Manufacturing Orders (MOs) were linked to a single Sales Order, Clicking the Delivery smart button caused a traceback error. Steps to…
Before this commit:
-------------------------
When multiple Manufacturing Orders (MOs) were linked to a single Sales Order,
Clicking the Delivery smart button caused a traceback error.
Steps to reproduce:
-------------------------
1. Install the 'sale' and 'sale_mrp' module.
2. Create a Sales Order (SO) for 10 units of ProductA.
3. Enable Allocation Reports in Manufacturing.
4. Create a Manufacturing Order (MO) for ProductA with 5 units.
- Produce all quantities.
- Assign the produced quantity to the Sales Order.
5. Create a second MO for ProductA with 5 units.
- Produce all quantities.
- Assign the produced quantity to the Sales Order.
6. Return to the Sales Order and click the Delivery smart button, and a
traceback occurs.(ValueError: Expected singleton: stock.reference(42, 43))
Cause of the issue:
--------------------------------------
- The expression self.stock_reference_ids[:-1].id assumed the presence of a
single record.
- When multiple stock.reference records were linked, slicing the recordset
(self.stock_reference_ids[:-1]) returned multiple values, causing a
singleton error during evaluation.
After this commit:
-----------------------
- Removed unnecessary default value handling, as it always returned False,
making it redundant.
- The Delivery smart button now correctly handles multiple MOs linked to the
same SO without causing traceback errors.
- This change only refines the logic for safer multi-record handling without
altering any existing functionality.
Opw-5148852Creating a new Helpdesk ticket could fail when a stage had a positive “Days to rot” setting because the system tried to use missing date values. The fix uses the current date and time when those dates are not yet available, allowing ticket creation to continue normally.
Original PR description
Currently an error occurs when user creates the helpdesk ticket. Steps to Reproduce: - Install the `helpdesk` module. - Go to `Stages` and, in the `Kanban view`, open the `New Stage` record. - Set a…
Currently an error occurs when user creates the helpdesk ticket. Steps to Reproduce: - Install the `helpdesk` module. - Go to `Stages` and, in the `Kanban view`, open the `New Stage` record. - Set a value `greater than 0` in the `Days to rot` field. - Go to `Tickets` and click `New`. `TypeError: unsupported operand type(s) for +: 'bool' and 'datetime.timedelta'` This error occurs when a user sets the Days to rot value greater than zero in a new stage. When creating a helpdesk ticket, the compute method runs and filters the records[1] to check which records have stayed too long in their current stage based on the last stage update date or create date. For the current record, both of these fields are not set now, which raises the error[1]. This commit ensures that if the record does not have a last stage update or create date, the current date and time will be used instead. [1]- https://github.com/odoo/odoo/blob/7748345e11b542b00656d3586767e064c2d1e2e8/addons/mail/models/mail_tracking_duration_mixin.py#L183 sentry-6927500374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payroll now uses the correct work entry date field when finding related records for payslips. This prevents payroll processing issues caused by outdated field references after the work entry data model changed.
Original PR description
There is no more date_start and from in work entries. Use date instead.
Fixed an issue in Mail calls where, after another participant stopped sharing their screen, that person stayed incorrectly highlighted instead of returning the call to the full participant view. This improves meeting clarity by ensuring everyone in the call is shown again as expected.
Original PR description
Before this commit, when another user stops the screen sharing, said user would be now focused (the expected behavior is showing all call participants). Steps to reproduce: 1. Have a call between user A and B 2. As user A start and then stop Screen Share 3. Observe on user B that user A is focused This happened because the activeRtcSession would not be correctly cleared (regression introduced in [1]). This commit fixes the issue by reintroducing the clearing of the activeRtcSession in a more declarative way. [1]: https://github.com/odoo/odoo/pull/221019 task-5090261
This change prevents an analytic distribution field from relying on company information where that information is not available. It helps avoid errors when configuring salary rules, keeping payroll-related setup smoother and more reliable.
Original PR description
Before this commit, the widget analytic_distribution has a field dependency on company_id. But this widget is used for the field analytic_distribution in the model "hr.salary.rule" and this model doesn't have a field "company_id". So to solve this issue, this widget is duplicated (with/without company). task-5155490 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
SEPA direct debit payments now correctly recognize whether a saved mandate is still valid. This prevents valid future-dated mandates from being wrongly rejected and helps avoid unnecessary payment failures.
Original PR description
The check to ensure that the mandate used in a token payment is still valid had two issues: - It was comparing a date (the mandate's end date) with a datetime. - It was incorrectly rejecting mandates expiring in the future, while it should have done the opposite. Forward-Port-Of: odoo/enterprise#96426 Forward-Port-Of: odoo/enterprise#96143
Fixes a problem that could show a blank screen when opening Attendance kiosk mode with debug mode enabled. This helps ensure employees and managers can access the kiosk reliably without being blocked by a page error.
Original PR description
step to reproduce: - install Attendances app - turn on debug mode - go to Attendance -> kiosk mode Observation: - We get a blank screen with error in browser console ``` OwlError: Invalid props for component 'kioskAttendanceApp': 'activeDisplay' is missing (should be a string) ``` Cause: - Commit [1] mistakenly included an unused `activeDisplay` prop. - The component already uses the `active_display` state, so the prop was removed. https://github.com/odoo/odoo/blob/da66ff8b2e60db06872eb926c6f22a6f99a7f879/addons/hr_attendance/static/src/public_kiosk/public_kiosk_app.js#L51-L54 [1] https://github.com/odoo/odoo/commit/bd9351a36cf7394bc5436806d4e6548e6477c497 Issue was identified when fixing https://github.com/odoo/odoo/pull/229225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product names in selection dropdowns now wrap onto multiple lines instead of forcing horizontal scrolling. This makes choosing products with long names cleaner and keeps hover highlighting visually consistent.
Original PR description
Steps to Reproduce: 1. Install `eCommerce`. 2. Add a product with a name longer than 30 characters. 3. Drop the _Add to Cart_ snippet. 4. In Choose record option, search for the product. 5. Hover…
Steps to Reproduce: 1. Install `eCommerce`. 2. Add a product with a name longer than 30 characters. 3. Drop the _Add to Cart_ snippet. 4. In Choose record option, search for the product. 5. Hover over the product name and try to scroll horizontally. Issue: The product name does not wrap, causing horizontal scrolling. Additionally, the hover background is applied only to the visible viewport area, breaking visual consistency. Cause: The dropdown items had `d-flex`, which makes them flex containers. By default, flex containers prevent text from wrapping and force content to stay on a single line, which caused horizontal overflow. Fix: Removed the `d-flex` class from the _DropdownItem_ and added `text-wrap` to allow product names to wrap onto multiple lines. This eliminates horizontal scrolling and ensures the hover background covers the entire item. Additionally, removed the `align-items-center` class from _DropdownItem_ and `text-wrap` from the child div, as they were unnecessary. Behaviour in 18.4: <img width="1042" height="441" alt="image" src="https://github.com/user-attachments/assets/377047d0-0ea0-4ad8-8f6c-7a62ebf56398" />
Point of Sale product search now returns all relevant products that match a search term, not only exact matches. This helps cashiers find and sell the right items faster, especially when product names or variants share similar words.
Original PR description
The POS search only returned products with an exact match (when existing), ignoring other relevant products that partially matched the search string. Steps to reproduce: 1. Create a product "TEST" - Create a variant with attributes value including "TEST" and "OTHER". 2. Create a second product "TEST 2". 3. Open the POS. 4. Search for "TEST". 5. Only "TEST" is shown; "TEST 2" is missing, even with "Search more". To align with the behavior introduced in v18, I’ve removed the exact match condition, as it no longer appears necessary due to the absence of fuzzy search. I’ve also adjusted the logic to perform the search on `product.product` instead of `product.template`. opw-4958141 Forward-Port-Of: odoo/odoo#230749 Forward-Port-Of: odoo/odoo#221520
The timesheet import template has been updated to include a missing description in one of its sample rows. This prevents errors when users import timesheet data using the provided template, making the process smoother and more reliable.
Original PR description
The previous import template for timesheet had a row without description causing an error during import. This commit fills the empty cell of the import template. task-5159539
This fix prevents duplicate Gelato orders from being created when sale order confirmation is retried during concurrent payment processing. Gelato orders are now first created as drafts and only confirmed after the Odoo transaction succeeds, reducing the risk of duplicate fulfillment and customer service issues.
Original PR description
In case on a concurrent update happen in the same transaction as the sale order confirmation (was observed during payment transaction post-processing), we may currently create duplicate Gelato orders on each retry. This commit avoid duplicate order creation by splitting the Gelato order creation in two steps: - during the sale order confirmation we create a 'draft' order on Gelato - on post-commit/post-rollback we either try to confirm or delete the Gelato draft order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228107
Hungarian invoice PDFs no longer fail when an invoice includes section lines. This prevents a printing error and lets users generate invoices normally for Hungarian companies.
Original PR description
When a user tries to print an invoice with section lines for Hungarian company, a traceback occurs. Steps to reproduce the error: - Install ``l10n_hu_edi`` module with demo data and switch to ``HU…
When a user tries to print an invoice with section lines for Hungarian company, a traceback occurs. Steps to reproduce the error: - Install ``l10n_hu_edi`` module with demo data and switch to ``HU Company`` - Create an invoice > Add a seaction >Add a line under that section > Save - Confirm > Print Traceback: ```py QWebError: Error while rendering the template: TypeError: unsupported operand type(s) for *: 'NoneType' and 'int' ``` https://github.com/odoo/odoo/blob/dc6dd927faea1f4501d6c50c586d5ea46bd1fc95/addons/l10n_hu_edi/views/report_invoice.xml#L84-L86 Here, ``current_subtotal`` is used instead of ``section_subtotal``. So, It will lead to the above traceback. ``current_subtotal`` was changed to ``section_subtotal`` in the commit [1], but the t-out attribute in the same block was not changed accordingly. [1]: https://github.com/odoo/odoo/commit/af9bf2ac1939aa8d64c4ba5caa202b229debba3f sentry-6933103730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adjusts an internal Mail app test related to link previews so it is formatted more clearly and runs more reliably. It helps maintain quality around link preview behavior without changing what users see in the product.
Original PR description
Forward-Port-Of: odoo/odoo#230833
Cashiers can now enter password numbers using a physical keyboard when the password popup is shown, instead of being limited to on-screen buttons. This makes POS login and cashier switching faster and less frustrating for staff using keyboard-equipped terminals.
Original PR description
Before this commit, when the NumberPopup was open (for example, when entering the cashier password), the keyboard input was ignored because the overlay manager blocked all keyboard events while any popup was active. As a result, it was only possible to use the on-screen number buttons. After this commit, the keyboard input is allowed when a NumberPopup is open, enabling users to type the password directly using the keyboard. opw-5152235 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230626
Odoo now prevents price rules based on another pricelist from being saved unless that source pricelist is selected. This avoids incorrect product pricing when rules are created outside the standard screens, such as through custom views or integrations.
Original PR description
Before this commit, only a view-level required attribute ensured that pricelist items with `base=='pricelist'` have a `base_pricelist_id` set. Creating pricelist items from a custom view or the API or the shell could result in missing values for this field, causing `_compute_base_price` to incorrectly assume that `base=='list_price'`` This commit introduces a new constraint ensuring any pricelist whose price is `base`d on an "Other Pricelist" has a value for `base_pricelist_id`. Note: in the views, `base_pricelist_id` is required if `compute_price == 'formula' and base == 'pricelist'` but the first condition is not neeeded because `_onchange_compute_price` sets `base` to `'list_price'` when `compute_price!='formula'` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230438
This fixes a visibility issue that could hide payroll accounting distribution settings when Payroll and Accounting were installed independently. Users will now be able to access the expected configuration option, reducing setup confusion.
Original PR description
If payroll and accounting are installed standalone, the application_group is never made visible task-5160204
Social Marketing previews now correctly recognize URLs that include comma-separated parameters and other special characters. This prevents links from being cut off in drafted social posts, reducing preview errors before publishing.
Original PR description
**Steps to reproduce:** - Go to `Social Marketing` app. - Click on `New Post`. - Select Facebook for preview (should not matter). - Write a message with an URL which have comma-separated parameters. (e.g 'TEST URL https://example.be:8080/path/res-123/ext/?param1=v1,v2,v3') - URL is cut on the first comma in the preview. **Issue:** URL regex did not match URLs containing comma-separated query parameters, causing them to be truncated. **Fix:** Updated the regex to include commas. opw-5042131 Forward-Port-Of: odoo/enterprise#94220
This fixes how certain Spanish service sales taxed at 0% VAT are categorized in VAT form 303. The change ensures these sales are treated as not subject to VAT rather than exports, improving accuracy in Spanish tax reporting and correcting the refund sign for the related tax setup.
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#230663 Forward-Port-Of: odoo/odoo#229752
This fixes when French POS order integrity hashes are created so they use the complete final order data. It prevents legitimate POS orders from being wrongly flagged as altered during compliance checks.
Original PR description
Description of the issue/feature this PR addresses:
Starting from version 18.0, inalterability hashes in the FR localization are sometimes calculated with incomplete data, leading to incorrect `l10n_fr_hash`. Related orders are then wrongly flagged as altered when running the POS Inalterability Check.
Current behavior before PR:
When you post a POS order and a related draft order exists, Odoo updates the existing order with the new vals. Because `{'state': 'paid'}` is amongst the new vals, it triggers the generation of the `l10n_fr_hash` before the order is fully processed. For instance, the hash will be generated before a new payment line is added for change with `_process_payment_lines()`.
Desired behavior after PR is merged:
The hash should be generated at the end of the order processing, with the final write in `action_pos_order_paid()`.
Forward-Port-Of: odoo/odoo#230828
Forward-Port-Of: odoo/odoo#226032Code cleanup and technical improvements
The IoT driver code now treats each device identifier as a stable value rather than recalculating or passing it around in multiple places. This internal cleanup reduces inconsistency risk and helps keep IoT device communication and setup more reliable without changing user-facing behavior.
Original PR description
As the IoT identifier is a serial number or a motherboard uuid, it is not meant to change. It then makes more sense for it to be a constant as `IS_WINDOWS` or `IS_LINUX` are. Enterprise PR: odoo/enterprise#96549 Task: 5149362
The Belgian POS blackbox integration now uses a shared identifier value for IoT Box detection instead of recalculating it through an internal method. This is an internal cleanup that improves consistency and maintainability without changing the user experience.
Original PR description
We now use a constant instead of a call to a cached method to get the identifier of the IoT Box. We updated the driver to use this constant. Community PR: odoo/odoo#230346 Task: 5149362