Daily updates from Odoo
Thursday, June 18, 2026
124 changes
24 changes
Enhancements to existing features
This update enhances navigation between sold assets and related customer invoices. Now, invoices linked to a sold asset will display a direct link to the asset within the invoice chatter, and vice-versa. This streamlines workflows by providing easier access to relevant financial information.
Original PR description
This commit improves the navigation from a sold asset to the customer invoice and vice versa. A reference link of the sold asset is added to the chatter of each invoice used in sale. Also, all invoices used in sale are added as reference link to the asset's chatter. task-4413649 Forward-Port-Of: odoo/enterprise#118665
Resolved issues and error corrections
This update optimizes a key process within Odoo's accounting module, specifically when validating journal entries. By caching a frequently used calculation, the system now responds more quickly, particularly when handling multiple journal entries or lines. This results in a smoother and faster user experience.
Original PR description
The method `get_relevant_plans` is called in `_validate_distribution`, which is often called in loops, for instance when validating the analytic distribution of multiple journal entries or of journal entries with multiple lines. That method is doing a lot of work by filtering all the plans and all the applicabilities every time, which can be avoided since the `kwargs` are likely to often be the same ones. Forward-Port-Of: odoo/odoo#269155
This update resolves an issue where navigating between tasks in Odoo caused errors due to outdated information being restored from the browser's session storage. The fix ensures that only dynamic actions are reused, preventing problems with context values and improving the overall stability of task navigation. This enhances the user experience by reducing unexpected errors.
Original PR description
Steps to reproduce: - Open any project task - Click a project notification that opens another task (requires the corresponding notification preference to be enabled) - Use the browser's Back and Forward buttons => Traceback: active_id is undefined When navigating to a form view via a URL (e.g. `/odoo/m-<model>/<id>`), the action service looks up the last action from session storage and reuses it if the model matches. This behavior, introduced in a4b179a7118916aac032ad252c0e421d452e553c, does not discriminate between dynamic and non-dynamic actions. Non-dynamic actions (those with an id) may rely on context values such as active_id that are only valid in their original execution context. Restoring such an action during browser history navigation causes a traceback because active_id is undefined. Fix by only reusing the session-stored action when it is a dynamic action (no id). Forward-Port-Of: odoo/odoo#270521 Forward-Port-Of: odoo/odoo#270076
A previous error message in the Odoo loyalty program was confusing for users, leading to frustration. This update corrects the error message to provide clearer guidance when discount codes aren't applied due to minimum purchase requirements. This ensures a smoother experience for customers using the loyalty program.
Original PR description
Issue: Error message was ambiguous and left users wondering what was wrong. Steps to reproduce: Set a discount code where the conditional rule is set to "minimum purchase" among specified products. Then, spend an amount larger than this on unrelated products and try to apply the discount code. "A minimum of x(currency) should be purchased to get reward" Cause: Poor error message caused ambiguity Solution: Corrected the error message so that the user can better understand where the issue is. opw-6290514 Forward-Port-Of: odoo/odoo#269319
This update fixes a potential issue where Odoo would incorrectly try to install auto-install modules if a required dependency was missing. Now, if an auto-install module has a missing dependency, it won't be marked for installation, preventing installation errors and ensuring a smoother database setup process.
Original PR description
Let's consider an auto-install module `A` having 2 dependencies, one to `base` and the second to custom module `B`. If module `B` is not present in the addons path (i.e is unknown), during a new database initialization module `A` would still be marked as `to install`. This commit ensures that if an auto-install module has a missing dependency, it will not be marked as `to install`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270346
This update corrects a minor issue within the Odoo Sale Project module's testing environment. A test was referencing a field that wasn't present in the community version of the module. Removing this reference ensures the tests run correctly and prevents potential errors.
Original PR description
The domain in the `test_group_expand_sales_order` test was using a field (`planned_date_begin`) that was not available in community. Since the domain is not relevant to the test, simply removing it fixes the issue. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/241204 task-6311159
This update resolves an issue where related fields weren't correctly updating after changes were made in Odoo Studio. Specifically, when using Studio, the system didn't properly reflect new choices added to related fields. This fix ensures that related fields are consistently updated, regardless of how they were initially created.
Original PR description
This is because webclient knows the current value (c), but not the new available choices, still with the previous one (a, b). Actually this works correctly if the field is created within a model…
This is because webclient knows the current value (c), but not the new
available choices, still with the previous one (a, b).
Actually this works correctly if the field is created within a model
class.
```py
if model_cls._setup_done__ and field._base_fields__:
# the field has been created by model_classes._setup() as
# Field(_base_fields__=...); restore it to force its setup
name = field.name
base_fields = field._base_fields__
field.__dict__.clear()
field.__init__(_base_fields__=base_fields)
field._toplevel = True
field.__set_name__(model_cls, name)
field._setup_done = False
models_field_depends_done.discard(model_cls)
```
It does not works with studio because there are no parent class
(`_base_fields__`), so the if is not reached.
A solution would be to check if the field is a manually created related
and mark the whole model for setup unlike when `_base_fields__` is
present where we only setup this specific field.
opw-6293768
Forward-Port-Of: odoo/odoo#270349This update resolves a bug that caused the Odoo application to crash when opening articles with embedded account reports. The fix prevents a change to the report's name during setup, ensuring stability and proper component functionality. This improves the user experience for reporting features.
Original PR description
When opening an article containing an embedded account report component, the application crashes because the `name` prop is mutated during the component `setup`, which is not allowed.
Steps to reproduce:
1. Create a new audit report
2. Open the "Journal Audit" article containing an embedded account report
=> The following exception is raised:
```
Uncaught (in promise) TypeError: setting getter-only property "name"
setup account_report.js:15
```
To fix the issue, the translation of the `name` prop is moved to `getProps`, which prepares component props before mounting. This ensures the value is already translated at instantiation time, avoids any mutation during setup, and preserves prop immutability throughout the component lifecycle.
Ref: odoo/enterprise#109962
Task-6292898
Forward-Port-Of: odoo/enterprise#120077This update eliminates a frustrating popup that appeared during refund order creation in Point of Sale. Now, refund processes for both direct sales and refunds proceed without interruption, improving the user experience and efficiency for our sales teams.
Original PR description
Before this commit: =================== - Preset selection popup was shown when creating refund orders. - Refund process was interrupted by unnecessary preset selection. After this commit: ================== - Preset selection popup no longer appears for refund orders. - Direct sale refund orders proceed smoothly. Task - 6170816
This update fixes an issue where employee attendance records were incorrectly recorded due to timezone discrepancies. The system now accurately stores attendance check-in/out times in UTC, ensuring accurate reporting and scheduling. This improves the reliability of attendance data.
Original PR description
This commit includes the following: - BioTime returns punch_time as naive local time in the employee's timezone, but it was stored verbatim and treated as UTC, so attendance check-in/out times were off by the timezone offset. - Convert punch_time through the employee's timezone to UTC before storing, via the new _punch_time_to_utc helper. Task-6181807
This update fixes an issue where order-level customer notes weren't appearing on preparation tickets. The fix ensures that all customer notes, including internal notes, are now printed on these tickets, improving communication with the kitchen staff. It also prevents unnecessary tickets from being generated when notes are updated.
Original PR description
Steps to Reproduce: - Open Restaurant POS configured with a preparation printer. - Create a new order and add a customer note at the order level. - Send the order for preparation. Issue: - The order-level customer note is not printed on the preparation ticket. Fix: - Ensure the customer note is included in the preparation ticket. - Prevent additional preparation tickets from being printed when the customer note (or internal note) is modified alongside order lines. Task-5960046 Forward-Port-Of: odoo/odoo#250063
This update resolves an error that occurred on the `/partners` website page after upgrading to version 19.2. The issue stemmed from a change in how website templates are managed during upgrades, specifically related to a technical element called 't-call'. This fix ensures a smoother upgrade process and prevents website access problems.
Original PR description
**Issue:** Currently, an error occurs when users access the `/partners` website page after upgrading a database with the `website_crm_partner_assign` module (including demo data) to saas-19.2. **Root…
**Issue:**
Currently, an error occurs when users access the `/partners` website page
after upgrading a database with the `website_crm_partner_assign`
module (including demo data) to saas-19.2.
**Root cause:**
This issue occurs because recent changes introduced in PR [1] added a
new template as id `index_layout`. Inside this template, a `t-call` element
was using a nested `t-set` element to define `additional_title`. We were
referencing this `t-set` element in the XPath of the `index` template to
override the value of `additional_title`.
However, recent changes removed the `t-set` from the `t-call` and replaced
it with a direct variable assignment inside the `t-call`. During the upgrade,
the migration script automatically moves the `additional_title` attribute
into `t-call` and removes the `t-set` from the `t-call` (see the script and
related changes in [2]).
As a result, the XPath expression that targets the `t-set` element fails
because the referenced element no longer exists, which causes the error.
**Solution:**
This commit fixes the issue by moving the `t-set` element outside the `t-call`
and passing its value as an attribute of the `t-call` during the upgrade.
The `t-set` element is preserved to maintain compatibility with custom `XPath`
expressions that may target it, prenet XPath target errors after the upgrade.
The upgrade-specific behavior is enabled only when `config.get('upgrade_path')`
is set, allowing the code to detect that it is running in an upgrade context.
[1]: https://github.com/odoo/odoo/commit/711c3baad58f3e0f1dc39cb90eb8176aba91e9dd
[2]: https://github.com/odoo/odoo/pull/235469/changes#diff-29ae6f0bcf846a2fcaffc38fdd0d3b19ea328c133ff4dfe18cc9725715f34dd9
Sentry-7400315548
Forward-Port-Of: odoo/odoo#268864This update corrects a visual issue where employee profile images were stretched in the employee form. The change ensures images display correctly and consistently with other employee views, improving the overall user experience. This fix was implemented as part of a broader redesign effort.
Original PR description
Vertical images were stretched due to changes made during the form view's redesign (a58ed7d) and after adding a fixed size (6d40ab9). We've added an `.object-fit-contain` class to fix this issue and a rounded border to make the image's aligned with other similar views. task-5418517 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270126 Forward-Port-Of: odoo/odoo#262033
This update ensures that Odoo can properly create functional indexes using the 'unaccent' PostgreSQL function. Previously, the system wasn't correctly recognizing when 'unaccent' was available for indexing, leading to potential performance issues. This fix ensures indexes are created only when the function is properly configured for use.
Original PR description
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index. The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is…
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index.
The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is started with the `--unaccent` flag during database creation.
However, it is also possible to start `odoo-bin` with an existing database where the `unaccent` extension is already installed, but the function was never marked as `IMMUTABLE`.
In that case, `unaccent` can still be used in conditions such as `WHERE` clauses, but it cannot be used in functional indexes.
`has_unaccent()` actually has three possible states:
```py
class FunctionStatus(IntEnum):
MISSING = 0 # function is not present (falsy)
PRESENT = 1 # function is present but not indexable (not immutable)
INDEXABLE = 2 # function is present and indexable (immutable)
```
Therefore, checking only `if has_unaccent()` before creating an index using `unaccent` is not enough. The index should only be created when `has_unaccent()` returns `FunctionStatus.INDEXABLE`.
task-6307060
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#270420
Forward-Port-Of: odoo/odoo#270278This update corrects a duplication of functionality within the Web Studio module. The abstract field, previously a separate addition, has been removed as it's now correctly implemented in the base Odoo module. This ensures consistency and simplifies the Web Studio experience.
Original PR description
The abstract field was added in odoo/odoo#186121 in the base module. Removing the overwrite here. runbot-940119 Backport of https://github.com/odoo/enterprise/pull/120708
This update fixes an issue where the field selector expanded beyond the display edges. The change removes a previously added style rule, allowing the selector to properly utilize its intended maximum height and display correctly. This ensures a consistent and functional user experience.
Original PR description
Prior to this commit, the field selector would expand vertically to the edges or beyond the edges of the display. That was caused by the addition of the `o_popover` class in the scss selector in the file of the component. It was originally done to avoid having this style applied on touch devices but most of the changes of the original PR got reverted. This commit removes the extra popover class in the css selection and thus allows the `max-height` rule that was defined there to properly apply to the component. Task-6277505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the rental and subscription status badges were overlapping in sales orders. The fix replaces a positioning method with a simpler float-end approach, ensuring both badges are correctly displayed without interference. This improves the visual clarity of sales order information.
Original PR description
Steps to produce: --- - Install the `Rental` and `Subscription` modules. - Create a rental product and a subscription product. - Create a sales order containing both products and set a rental period.…
Steps to produce: --- - Install the `Rental` and `Subscription` modules. - Create a rental product and a subscription product. - Create a sales order containing both products and set a rental period. - Confirm the sales order. Issue: --- - The rental status badge overlaps the subscription status badge. Root cause: --- - The rental status badge uses the position-absolute CSS class to place it at the end of the header. When the subscription status badge is also displayed in the same area, both badges are positioned at the same location, causing them to overlap. - After [commit], this issue is introduced. Solution: --- - Replace position-absolute with float-end so the badges remain right-aligned without overlapping. [commit]: https://github.com/odoo/enterprise/commit/32ab15dc1f26af0e3d510ec859b1ec428068e9b5 Before: --- <img width="122" height="64" alt="image" src="https://github.com/user-attachments/assets/e6b47c9e-ed59-4a4b-a95c-0318cc43660e" /> After: --- <img width="175" height="57" alt="image" src="https://github.com/user-attachments/assets/ea98f7a1-67f6-4b2b-b699-1f2cd3376d8f" /> opw-6295212 ---
This pull request addresses a bug in the testing of POS orders that have been partially refunded. The fix ensures accurate calculations when handling refunds on POS orders, preventing potential discrepancies in reported amounts. This improves the reliability of our point-of-sale reporting.
Original PR description
runbot-939926 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical error preventing the 'XML Polizas (SAT)' export from functioning correctly for Innovacion Company users. The fix ensures the export process correctly handles file data types, allowing users to successfully generate and download their required financial reports. This improves the reliability of a key accounting reporting feature.
Original PR description
How to reproduce it: - Install l10n_mx_reports and select Innovacion Company - Go to accounting app > reporting and Open the General Ledger report - Trigger the "XML Polizas (SAT)" export, fill in the wizard (export type and order/process number) and click Export - A traceback is raised instead of downloading the file: TypeError: ... report_data: use BinaryValue instead of bytes This error happens because export_xml writes the generated file to the report_data field as raw bytes. After the introduction of BinaryValue, no longer accepts bytes values (unless raw field) for Binary fields and now expects a BinaryValue, causing the traceback. The write was modified on refactoring PR, but not correctly and there wasn't a test targeting the url action part so it was not flagged. This commit fixes the issue by wrapping the content in BinaryBytes (since is a BinaryValue) before assigning it to report_data and added tests covering the single and multiple period cases. task-6297731
This update fixes a visual issue where downloaded PDF invoices and debit notes incorrectly displayed 'INVOICE DINV...' instead of 'DEBIT NOTE DINV...'. This change ensures that debit notes are clearly distinguishable from invoices in printed and sent documents, improving clarity for our customers.
Original PR description
### Steps to reproduce the issue: 1. Download Invoice and Debit Notes 2. Go to an invoice (or create a new one) 3. Create a debit note for that invoice and print it or send it 4. In the PDF the title is 'INVOICE DINV....' instead of 'DEBIT NOTE DINV...' ### Reason to introduce the fix: Differentiate debit notes from invoices. opw-6252239 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268207
This update prevents users who aren't designated approvers from directly accepting or rejecting approval requests through the system's activity interface. Previously, this allowed unintended actions, causing errors. This change improves security and ensures that approval workflows are handled correctly by authorized personnel.
Original PR description
Currently when a user submits an approval request, an activity is created for the approver who can validate or refuse the request directly from the activity, however these options are also visible to other users who will trigger an error if interacting with the options. This commit removes these options for users who are not the approver. **Steps to reproduce:** - Log in as admin - Go to approvals - Select dropdown menu of General Approval and Edit - Change documents to optionnal - Make sure admin is in the approvers list - Log in as demo - Go to approvals -> General Approval -> New Request - Submit the request - You'll see an activity be created for admin, with Accept and Refuse options - If you select any of these options you will get an access error opw-5423528 Forward-Port-Of: odoo/enterprise#120643 Forward-Port-Of: odoo/enterprise#109047
This update ensures that binary files uploaded through forms now correctly store their filenames. Previously, this functionality was limited to manual fields, causing issues with mimetype detection and hindering the use of these fields in SaaS modules. This change improves data accuracy and simplifies future migrations.
Original PR description
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual…
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual fields, which limits the usage of those fields in standard and is particularly problematic when Saas modules that use this feature are migrated to Python. Not storing the filename can lead to incorrect mimetype guesses. Given that a more appropriate condition has already been added in [2], it should no longer be necessary to restrict this feature to manual fields. This commit removes that restriction to allow standard binary fields to store their filename when uploaded through a form. Current behavior before PR: When uploading a file to a non-manual binary field that has a related '_filename' field, the filename will not be stored, which can later lead to incorrectly guessing the mimetype of the file. Desired behavior after PR is merged: Uploading a file to a non-manual binary field that has a related '_filename' field stores the filename of the file. Task related to this issue: https://www.odoo.com/odoo/project.task/5917543 [1] https://github.com/odoo/odoo/commit/0e2f3b144581c47d25a99cecdd7e058a3d55bcc3 [2] https://github.com/odoo/odoo/commit/1bcab2f42eebf98127416e54f31cd6e351938b7f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268014
This update resolves an issue where SEPA QR codes were occasionally displaying incorrect decimal places due to floating-point precision problems in the underlying calculations. The fix ensures the QR code accurately reflects the vendor bill payment amount with the correct currency precision, improving data accuracy for payments.
Original PR description
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of…
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of respecting the currency's expected precision. This occurs because the `amount` variable in `_get_qr_vals` was being converted directly using `str(amount)`. Due to Python's floating-point arithmetic, the float value in memory can contain decimal drift. Directly casting it to a string exposes this drift in the payload. This commit resolves the issue by replacing `str(amount)` with `float_repr(amount, currency.decimal_places)`. This safely bypasses the float representation issue, ensuring the string strictly respects the currency's configured decimal precision before being injected into the QR code. opw-5504258 **Steps to reproduce:** - Select company “My Belgian Company” - Create a 23% purchase tax - Create vendor bill - Select Vendor “BE Company CoA” - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73 - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show **Current behavior before PR:** - When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift. **Desired behavior after PR is merged:** - The SEPA QR code is generated with the correct number of decimal places. Forward-Port-Of: odoo/odoo#269190 Forward-Port-Of: odoo/odoo#267293
This update fixes an issue where the /checklist command was not functioning in the CRM's activity note editor. The change reverts a recent update that inlined activity note content, causing the checklist to be disabled. Now, the checklist command is correctly available within activity notes, allowing users to easily add checklist items.
Original PR description
In 19.0 the /checklist command does not appear in the activity note editor. The note fields of activities, the schedule activity wizard and activity plan templates were moved to widget="html_mail" by…
In 19.0 the /checklist command does not appear in the activity note editor. The note fields of activities, the schedule activity wizard and activity plan templates were moved to widget="html_mail" by https://github.com/odoo/odoo/commit/2f61560ab45576191394510016c38a7442b95ec8, https://github.com/odoo/odoo/commit/35d673dccdc0f0c2a06cb0732e3148370f035af9 and https://github.com/odoo/odoo/commit/4d3a6156d07dc47bb2399d1907e2a47869827933 to render attachment overviews statically instead of with embedded components. html_mail is made for email bodies, it inlines the content on save and it disables the checklist since https://github.com/odoo/odoo/commit/f94f695ca9fc9a894a837640df2e4160e561f1ab because checklists do not survive the inlining of outgoing emails. The activity note is not an email body, so it gets both side effects for nothing. Keep the default html widget on these note fields and pass the embedded_components option as false, which is the only part of html_mail the attachment commits needed. The checklist works again, the note is not inlined on save anymore, and the attachment overview still renders statically. The widgets used for real email bodies keep the checklist disabled. Steps to reproduce: 0. Install the CRM module. 1. Open a lead from the CRM pipeline. 2. Click Activity to open the Schedule Activity dialog. 3. Click inside the Log a note field and type /checklist. => Checklist doesn't appear. Ticket [link](https://www.odoo.com/odoo/project.task/6139971) opw-6139971 Forward-Port-Of: odoo/odoo#261071
8 changes
Enhancements to existing features
This update enhances navigation between sales assets and customer invoices. Now, invoices linked to a sale asset will display a direct link to the asset's details within the invoice chatter, and vice-versa. This streamlines workflows and provides easier access to related information.
Original PR description
This commit improves the navigation from a sold asset to the customer invoice and vice versa. A reference link of the sold asset is added to the chatter of each invoice used in sale. Also, all invoices used in sale are added as reference link to the asset's chatter. task-4413649 Forward-Port-Of: odoo/enterprise#118665
This update optimizes how Odoo identifies relevant analytic plans, resulting in faster processing of journal entries and distributions. The change avoids redundant filtering, leading to a noticeable performance boost, especially when handling multiple journal entries simultaneously. This improves overall system responsiveness.
Original PR description
The method `get_relevant_plans` is called in `_validate_distribution`, which is often called in loops, for instance when validating the analytic distribution of multiple journal entries or of journal entries with multiple lines. That method is doing a lot of work by filtering all the plans and all the applicabilities every time, which can be avoided since the `kwargs` are likely to often be the same ones. Forward-Port-Of: odoo/odoo#269155
Resolved issues and error corrections
This update resolves an issue where navigating between tasks in Odoo caused errors due to outdated information being restored from the user's browser session. The fix ensures that only dynamic actions are reused, preventing errors related to invalid context data and improving the reliability of task switching.
Original PR description
Steps to reproduce: - Open any project task - Click a project notification that opens another task (requires the corresponding notification preference to be enabled) - Use the browser's Back and Forward buttons => Traceback: active_id is undefined When navigating to a form view via a URL (e.g. `/odoo/m-<model>/<id>`), the action service looks up the last action from session storage and reuses it if the model matches. This behavior, introduced in a4b179a7118916aac032ad252c0e421d452e553c, does not discriminate between dynamic and non-dynamic actions. Non-dynamic actions (those with an id) may rely on context values such as active_id that are only valid in their original execution context. Restoring such an action during browser history navigation causes a traceback because active_id is undefined. Fix by only reusing the session-stored action when it is a dynamic action (no id). Forward-Port-Of: odoo/odoo#270521 Forward-Port-Of: odoo/odoo#270076
This update resolves an issue where SEPA QR codes were occasionally displaying incorrect decimal places due to floating-point calculations in the system. The change ensures the QR code amount accurately reflects the currency's precision, preventing potential payment errors. This improves the reliability of vendor bill payments via QR code scanning.
Original PR description
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of…
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of respecting the currency's expected precision. This occurs because the `amount` variable in `_get_qr_vals` was being converted directly using `str(amount)`. Due to Python's floating-point arithmetic, the float value in memory can contain decimal drift. Directly casting it to a string exposes this drift in the payload. This commit resolves the issue by replacing `str(amount)` with `float_repr(amount, currency.decimal_places)`. This safely bypasses the float representation issue, ensuring the string strictly respects the currency's configured decimal precision before being injected into the QR code. opw-5504258 **Steps to reproduce:** - Select company “My Belgian Company” - Create a 23% purchase tax - Create vendor bill - Select Vendor “BE Company CoA” - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73 - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show **Current behavior before PR:** - When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift. **Desired behavior after PR is merged:** - The SEPA QR code is generated with the correct number of decimal places. Forward-Port-Of: odoo/odoo#267293
This update ensures that Odoo correctly checks the status of Belgian Peppol partners (EAS 9925) to prevent communication issues. Previously, the system didn't re-evaluate 'not-valid' statuses, leading to unreachable partners. This fix resolves this issue by proactively verifying partner status, ensuring seamless Peppol integration.
Original PR description
Some partners were registered on Peppol with EAS 9925 (Belgian VAT) but have since moved to 0208. They became unreachable via Peppol because we only recomputed their status when it was still `not_verified`, so a stored `not_valid` status was never re-checked. This fix forces the re-checking of the status for partners having EAS 9925 and a `not_valid` status. task-6296017 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where Odoo would incorrectly try to install auto-install modules if a required dependency was missing. Now, if an auto-install module has a dependency that isn't present, it won't be marked for installation, preventing installation errors and improving the reliability of database setup.
Original PR description
Let's consider an auto-install module `A` having 2 dependencies, one to `base` and the second to custom module `B`. If module `B` is not present in the addons path (i.e is unknown), during a new database initialization module `A` would still be marked as `to install`. This commit ensures that if an auto-install module has a missing dependency, it will not be marked as `to install`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270346
This update ensures that Odoo can properly create functional indexes using the `unaccent` PostgreSQL function. Previously, the system wasn't correctly recognizing when `unaccent` was available for indexing, leading to potential performance issues. This fix guarantees that indexes are created only when the function is fully supported, improving search efficiency.
Original PR description
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index. The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is…
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index.
The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is started with the `--unaccent` flag during database creation.
However, it is also possible to start `odoo-bin` with an existing database where the `unaccent` extension is already installed, but the function was never marked as `IMMUTABLE`.
In that case, `unaccent` can still be used in conditions such as `WHERE` clauses, but it cannot be used in functional indexes.
`has_unaccent()` actually has three possible states:
```py
class FunctionStatus(IntEnum):
MISSING = 0 # function is not present (falsy)
PRESENT = 1 # function is present but not indexable (not immutable)
INDEXABLE = 2 # function is present and indexable (immutable)
```
Therefore, checking only `if has_unaccent()` before creating an index using `unaccent` is not enough. The index should only be created when `has_unaccent()` returns `FunctionStatus.INDEXABLE`.
task-6307060
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#270420
Forward-Port-Of: odoo/odoo#270278This update ensures that purchase order prices correctly maintain the precision of product costs, even for small amounts like $0.001235. Previously, these prices were rounded, leading to inaccurate purchase calculations. This change aligns purchase order pricing with sales order pricing, improving data accuracy and financial reporting.
Original PR description
Commit 07da917f6e331 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased. For…
Commit 07da917f6e331 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased. For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`. However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision. This is inconsistent with sales: sale order lines preserve very small unit prices correctly. **Current behavior before PR:** A product with `standard_price = 0.001235` keeps that value on the product form. When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost. The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line. **Desired behavior after PR is merged:** Purchase order lines preserve the computed unit price precision, just like sale order lines already do. A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267941
17 changes
Enhancements to existing features
This update enhances navigation between customer invoices and sold assets. Now, invoices linked to a sold asset are directly accessible from the asset's chatter, and vice versa. This streamlines workflows and provides easier access to related financial information.
Original PR description
This commit improves the navigation from a sold asset to the customer invoice and vice versa. A reference link of the sold asset is added to the chatter of each invoice used in sale. Also, all invoices used in sale are added as reference link to the asset's chatter. task-4413649 Forward-Port-Of: odoo/enterprise#118665
This update optimizes a key process in Odoo's accounting system, specifically when validating journal entries. By caching a frequently used calculation, the system now responds more quickly, especially when handling multiple journal entries or complex transactions. This results in a smoother and more efficient user experience.
Original PR description
The method `get_relevant_plans` is called in `_validate_distribution`, which is often called in loops, for instance when validating the analytic distribution of multiple journal entries or of journal entries with multiple lines. That method is doing a lot of work by filtering all the plans and all the applicabilities every time, which can be avoided since the `kwargs` are likely to often be the same ones. Forward-Port-Of: odoo/odoo#269155
Resolved issues and error corrections
This update resolves a minor issue where real-time updates to the ‘Looking for Help’ live chat views could occasionally be missed due to timing differences. Because these views have been replaced with a dedicated discussion category, this fix is considered a minor improvement and doesn’t impact core functionality. The related tests have been removed.
Original PR description
Some tours check that real time updates work for kanban/list views of looking for help live chats. However, there can be a race condition between the time the view is loaded, and the time the bus subscription is made on the server. As a result, there is a small window where updates can be missed. A proper solution would be to wait for the subscription to be made to load the view, but the server doesn't provide any acknowledgement for subscriptions. Since those views have been removed in favor of a dedicated discuss category, the issue is considered minor and not worth fixing. This commit removes the related tests. runbot-234681 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#270332
This update resolves an issue where navigating between tasks in Odoo caused errors due to outdated information being restored from the user's browser session. The fix ensures that only dynamic actions are reused, preventing errors related to invalid context data and improving the reliability of task switching.
Original PR description
Steps to reproduce: - Open any project task - Click a project notification that opens another task (requires the corresponding notification preference to be enabled) - Use the browser's Back and Forward buttons => Traceback: active_id is undefined When navigating to a form view via a URL (e.g. `/odoo/m-<model>/<id>`), the action service looks up the last action from session storage and reuses it if the model matches. This behavior, introduced in a4b179a7118916aac032ad252c0e421d452e553c, does not discriminate between dynamic and non-dynamic actions. Non-dynamic actions (those with an id) may rely on context values such as active_id that are only valid in their original execution context. Restoring such an action during browser history navigation causes a traceback because active_id is undefined. Fix by only reusing the session-stored action when it is a dynamic action (no id). Forward-Port-Of: odoo/odoo#270521 Forward-Port-Of: odoo/odoo#270076
This update fixes a potential issue where Odoo would incorrectly try to install auto-install modules if a required dependency was missing. Now, if an auto-install module has a missing dependency, it won't be marked for installation, preventing installation errors and ensuring a smoother database setup.
Original PR description
Let's consider an auto-install module `A` having 2 dependencies, one to `base` and the second to custom module `B`. If module `B` is not present in the addons path (i.e is unknown), during a new database initialization module `A` would still be marked as `to install`. This commit ensures that if an auto-install module has a missing dependency, it will not be marked as `to install`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270346
This update resolves a bug that caused the Odoo application to crash when opening articles containing embedded account reports. The fix ensures that component data is properly initialized, preventing unintended changes during setup and maintaining stability. This improves the reliability of the accounting module.
Original PR description
When opening an article containing an embedded account report component, the application crashes because the `name` prop is mutated during the component `setup`, which is not allowed.
Steps to reproduce:
1. Create a new audit report
2. Open the "Journal Audit" article containing an embedded account report
=> The following exception is raised:
```
Uncaught (in promise) TypeError: setting getter-only property "name"
setup account_report.js:15
```
To fix the issue, the translation of the `name` prop is moved to `getProps`, which prepares component props before mounting. This ensures the value is already translated at instantiation time, avoids any mutation during setup, and preserves prop immutability throughout the component lifecycle.
Ref: odoo/enterprise#109962
Task-6292898
Forward-Port-Of: odoo/enterprise#120077This update resolves an issue where saving job page descriptions with all content removed resulted in a 'Document is empty' validation error. The fix ensures that empty, whitespace-only HTML fields are handled correctly during the save process, preventing this error and allowing users to successfully update job descriptions. This improves the overall usability of the recruitment module.
Original PR description
Steps to reproduce: =================== 1. Edit a job page. 2. Delete every `s_rating` block. 3. Save. => Validation Error: Document is empty. Cause: ====== Deleting the last snippet inside an…
Steps to reproduce: =================== 1. Edit a job page. 2. Delete every `s_rating` block. 3. Save. => Validation Error: Document is empty. Cause: ====== Deleting the last snippet inside an editable HTML field (e.g. the last `s_rating` block in the `website_rating` field of a job page) leaves the field's editable container with only whitespace text nodes. On save, it writes that whitespace to the record and then calls `_copy_custom_snippet_translations`, which does `html.fromstring(lang_value)` on the whitespace and raises `lxml.etree.ParserError: Document is empty`, re-raised as `ValidationError`. The user sees a "Validation Error" dialog and can't finish saving. The previous fix for the analogous "Document is empty" symptom on product description editing (commit [1]) added a `cleanupEmptyStructures` `on_removed_handlers` that strips whitespace from `.oe_empty` containers after element removal. That selector covers `oe_structure.oe_empty` containers but not editable HTML field savables (`[data-oe-type="html"]`), which don't carry an `oe_empty` class when they originally had content. As a result, fields like `hr.job.website_rating` still hit the failing parse path. Solution: ========= Extend the cleanup selector to also include `[data-oe-type="html"]` so HTML-field editables are normalized to genuinely empty after the last inner snippet is removed. [1]: https://github.com/odoo/odoo/commit/53d5cc7eed635f64038bf0315f6863011879c529 opw-6244892 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267397
This update ensures that Odoo can properly create functional indexes using the `unaccent` PostgreSQL function. Previously, indexes couldn't be created correctly in certain database setups, leading to performance issues. This fix addresses a technical detail to optimize index creation and improve search performance.
Original PR description
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index. The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is…
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index.
The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is started with the `--unaccent` flag during database creation.
However, it is also possible to start `odoo-bin` with an existing database where the `unaccent` extension is already installed, but the function was never marked as `IMMUTABLE`.
In that case, `unaccent` can still be used in conditions such as `WHERE` clauses, but it cannot be used in functional indexes.
`has_unaccent()` actually has three possible states:
```py
class FunctionStatus(IntEnum):
MISSING = 0 # function is not present (falsy)
PRESENT = 1 # function is present but not indexable (not immutable)
INDEXABLE = 2 # function is present and indexable (immutable)
```
Therefore, checking only `if has_unaccent()` before creating an index using `unaccent` is not enough. The index should only be created when `has_unaccent()` returns `FunctionStatus.INDEXABLE`.
task-6307060
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#270420
Forward-Port-Of: odoo/odoo#270278This update resolves a bug where characters were intermittently disappearing from SelectMenu input fields during autocomplete updates. The fix ensures the input field accurately reflects user input by updating the value immediately and resetting the field when empty, improving the user experience for data entry.
Original PR description
Step to reproduce: 1. Install `website_link` 2. Open Website > Site > Link Tracker 3. Type in text into any pre-defined field (Campaign, Medium, Source) 4. Observe that the input is not showing all…
Step to reproduce: 1. Install `website_link` 2. Open Website > Site > Link Tracker 3. Type in text into any pre-defined field (Campaign, Medium, Source) 4. Observe that the input is not showing all the typed characters Issue: - It's randomly removing characters, for example, type "1234567890" and observe Cause: - SelectMenu updates its internal searchValue only inside the debounced onInput handler `debouncedOnInput`. When an autocomplete callback reloads choices before that debounce fires, the component rerenders with a stale searchValue and writes that outdated value back into the controlled input, overwriting newer characters already typed by the user. Solution: - Update searchValue immediately on every raw input event and keep only the search callback debounced. - Also reset searchValue to null when a required single-select is blurred while empty, so the input falls back to the selected choice label instead of staying visually cleared. opw-6000540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255819
This update resolves an issue where the FEC export generated empty lines with zero balances for certain accounts. The fix ensures that all account openings are correctly represented in the export file, preventing potential errors in financial reporting. This improves the accuracy of the FEC data used for tax filing.
Original PR description
Steps to reproduce: - Use a French company (l10n_fr_account installed) - Post prior-year entries so that an account/partner nets to zero at the start of the next fiscal year (e.g. a customer invoice fully paid the same year, or a misc entry debiting and crediting the same balance-sheet account), and keep another account/partner with a non-zero opening - Open the FEC export wizard, set Start Date to the first day of the next year - Generate the FEC file and look at the "Balance initiale" (OUVERTURE) lines Issue: One of the exported line in as empty one with `...|0,00|0,00|..`` opw-6083991 Forward-Port-Of: odoo/odoo#268510
This update fixes alignment issues within the Timesheet Assistant, specifically in the 'By Project' and 'Chronological' views. The changes ensure that time entries and descriptions wrap correctly, even with lengthy project details. Additionally, a margin start has been added to the 'No (non-)billable time recorded' section for better visual clarity.
Original PR description
# [FIX] timesheet_grid: alignment issues in assistant This commit resolves the following alignment issues in the Timesheet Assistant: - View "By Project", the time wraps if description too long - View "Chronological", the time wraps if descriptions too long and project / task is not truncated - No timesheet recorded does not have a margin start # [FIX] sale_timesheet_enterprise: alignment issues in assistant This commit adds margin start on the "No (non-)billable time recorded" information. task-6264756
This update resolves a bug where the link editor unexpectedly appeared after creating multiple tracked links. The fix ensures the editor is only active when editing a single link, preventing confusion and improving the user experience. This change enhances the reliability of the Link Tracker feature.
Original PR description
Steps to reproduce: - Go to the Link Tracker page - Generate a first tracked link - Click on the button to start editing the code - Click on "create another tracker" - Generate a second tracked link => When you access the screen to see/edit the tracked link url, the buttons "ok" and "cancel" are already present. Clicking on "ok" display a traceback. To fix this issue, this commit also cancels edition when clicking on "create another tracker". task-4531974 Forward-Port-Of: odoo/odoo#269886 Forward-Port-Of: odoo/odoo#268573
This update fixes an issue where binary files uploaded through forms weren't correctly storing their filenames. Previously, this was limited to manual fields, causing problems with mimetype guessing and migration to Python. Now, standard binary fields can store filenames, ensuring accurate file handling and compatibility.
Original PR description
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual…
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual fields, which limits the usage of those fields in standard and is particularly problematic when Saas modules that use this feature are migrated to Python. Not storing the filename can lead to incorrect mimetype guesses. Given that a more appropriate condition has already been added in [2], it should no longer be necessary to restrict this feature to manual fields. This commit removes that restriction to allow standard binary fields to store their filename when uploaded through a form. Current behavior before PR: When uploading a file to a non-manual binary field that has a related '_filename' field, the filename will not be stored, which can later lead to incorrectly guessing the mimetype of the file. Desired behavior after PR is merged: Uploading a file to a non-manual binary field that has a related '_filename' field stores the filename of the file. Task related to this issue: https://www.odoo.com/odoo/project.task/5917543 [1] https://github.com/odoo/odoo/commit/0e2f3b144581c47d25a99cecdd7e058a3d55bcc3 [2] https://github.com/odoo/odoo/commit/1bcab2f42eebf98127416e54f31cd6e351938b7f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268014
This update reverses a recent change that prevented the blog footer from being editable within the Odoo website builder. The previous update used a technical setting to restrict access, which was causing inconvenience for users. This reversion restores the original functionality.
Original PR description
This reverts commit[1] which introduced not_activable_element_selectors resource in html_builder and used it to make the blog footer not selectable in the builder. [1]:https://github.com/odoo/odoo/commit/87d0c49a6 Forward-Port-Of: odoo/odoo#268024
This update fixes an issue where half-day leave durations were incorrectly calculated for part-time employees with differing work schedules. The change ensures accurate time off duration reporting by adjusting how the system determines leave length, particularly when employee and company working hours don't align. This improves the reliability of leave tracking.
Original PR description
**Steps to reproduce** - Use a french company with `l10n_fr_hr_holidays` installed - Change the duration type of the time off type set as the "Company Paid Time Off Type" in the French Time Off…
**Steps to reproduce** - Use a french company with `l10n_fr_hr_holidays` installed - Change the duration type of the time off type set as the "Company Paid Time Off Type" in the French Time Off Localization settings to "Half-Day" - Company Working Schedule: - Attendance on a day from 10 to 19, Day Period: Full Day - Part-time employee Working Schedule: - Attendance on the same day from 11 to 12, Day Period: Morning - Attendance on the same day from 13 to 19, Day Period: Afternoon - Create a full day time off for the part time employee on that day, using the time off type set as the "Company Paid Time Off Type" (start am, end pm) -> Excepted: time off duration is 1 day -> Actual: time off duration is 0.89 day **Change** Now that `request_unit_half` of a leave is a simple related to the `request_unit` of the leave type, it becomes important to not rely on a call to `_get_durations` using the company's calendar to compute the leave's duration, as it may not be fully accurate when the company's working hours and employee's working hours are not aligned. Continuation of 05e71eb206eb02a8d15708e6fb532a732a767d6d `_get_fr_date_from_to` is also adapted to take into account multi-day leaves ending in the morning while the employee works in the afternoon (in which case it should not be extended in case the employee doesn't work the next day). opw-6000011 Forward-Port-Of: odoo/odoo#253059
This update fixes an issue where the /checklist command was not functioning in the CRM's activity note editor. The change restores the checklist functionality while maintaining the static attachment rendering previously implemented. This ensures users can effectively utilize the activity note feature for task tracking.
Original PR description
In 19.0 the /checklist command does not appear in the activity note editor. The note fields of activities, the schedule activity wizard and activity plan templates were moved to widget="html_mail" by…
In 19.0 the /checklist command does not appear in the activity note editor. The note fields of activities, the schedule activity wizard and activity plan templates were moved to widget="html_mail" by https://github.com/odoo/odoo/commit/2f61560ab45576191394510016c38a7442b95ec8, https://github.com/odoo/odoo/commit/35d673dccdc0f0c2a06cb0732e3148370f035af9 and https://github.com/odoo/odoo/commit/4d3a6156d07dc47bb2399d1907e2a47869827933 to render attachment overviews statically instead of with embedded components. html_mail is made for email bodies, it inlines the content on save and it disables the checklist since https://github.com/odoo/odoo/commit/f94f695ca9fc9a894a837640df2e4160e561f1ab because checklists do not survive the inlining of outgoing emails. The activity note is not an email body, so it gets both side effects for nothing. Keep the default html widget on these note fields and pass the embedded_components option as false, which is the only part of html_mail the attachment commits needed. The checklist works again, the note is not inlined on save anymore, and the attachment overview still renders statically. The widgets used for real email bodies keep the checklist disabled. Steps to reproduce: 0. Install the CRM module. 1. Open a lead from the CRM pipeline. 2. Click Activity to open the Schedule Activity dialog. 3. Click inside the Log a note field and type /checklist. => Checklist doesn't appear. Ticket [link](https://www.odoo.com/odoo/project.task/6139971) opw-6139971 Forward-Port-Of: odoo/odoo#261071
This update fixes an issue where logged-in users could accidentally trigger a signup attempt via the website configuration. Now, when a user accesses the signup page, a warning message appears, and the submit button is disabled, preventing any further action. This improves the user experience and prevents potential data inconsistencies.
Original PR description
Steps to reproduce: 1.Log in to the backend as an Admin (or any authenticated user). 2.Navigate to Website -> Configuration -> System Pages and open the Signup page. 3.Fill in the signup form and submit it. 4.After successfully signing up, click the Logout button. 5.Observe that a "405 Method Not Allowed" error is displayed. Before this commit: When an already logged-in user accessed the signup page through the System Pages menu and submitted the signup form, clicking the Logout button afterward resulted in a 405 Method Not Allowed error. After this commit: When an already logged-in user accesses the signup or login page, a warning message is displayed and the Sign Up or Log In button is disabled, preventing the form from being submitted. task-6023075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This update corrects an issue where sign templates using auto-filled values (like 0 or False) weren't correctly populated. A previous fix unintentionally treated these falsy values as empty, leading to incorrect sign data. Now, the system properly preserves these values, ensuring accurate sign document completion.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the auto field value is 0 or False. - Send the…
Version: - saas-18.4 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the auto field value is 0 or False. - Send the document for signing and try to sign it - Observe that the readonly field is not populated with the auto-filled value. Issue: - Readonly sign items using auto-filled values from a linked record could not be validated when the value was 0 or False. Instead of using these values, the sign item kept its default value. Cause: - A previous fix was added to avoid replacing existing values with empty auto-filled values. However, the check also considered valid falsy values such as 0 and False as empty, so they were not populated into the sign item. Fix: - Only treat empty strings as missing auto-filled values. This allows valid values such as 0 and False to be populated correctly. Since the sign item value is stored in a text field, False is converted to the string "False" before storing it, ensuring it is preserved and correctly available during the signing flow.
6 changes
Resolved issues and error corrections
This update fixes a potential issue where Odoo would incorrectly try to install auto-install modules if a required dependency was missing. Now, if an auto-install module has a missing dependency, it won't be marked for installation, preventing installation errors and improving the stability of new database setups.
Original PR description
Let's consider an auto-install module `A` having 2 dependencies, one to `base` and the second to custom module `B`. If module `B` is not present in the addons path (i.e is unknown), during a new database initialization module `A` would still be marked as `to install`. This commit ensures that if an auto-install module has a missing dependency, it will not be marked as `to install`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270346
This update ensures that purchase order prices, like sales orders, correctly maintain the precision of low-value product costs (e.g., $0.001235). Previously, these prices were rounded, leading to inaccurate calculations. This change improves the reliability of purchase order pricing and reduces potential discrepancies.
Original PR description
**Description of the issue/feature this PR addresses:** Odoo 19.0 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product…
**Description of the issue/feature this PR addresses:** Odoo 19.0 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased. For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`. However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision. This is inconsistent with sales: sale order lines preserve very small unit prices correctly. https://github.com/user-attachments/assets/03d13596-d72b-4aee-bd37-7910a5842456 **Current behavior before PR:** A product with `standard_price = 0.001235` keeps that value on the product form. When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost. The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line. **Desired behavior after PR is merged:** Purchase order lines preserve the computed unit price precision, just like sale order lines already do. A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269066 Forward-Port-Of: odoo/odoo#267664
This update resolves an issue where website interactions were missing events due to asynchronous processing. The fix now buffers and replays missed events, enhancing the stability and reliability of website tours and interactions. This reduces potential instability and improves the overall user experience.
Original PR description
Interactions are meant to be small piece of code that attaches themselves to some part of the current page in a website. They have a lifecycle, in which, we only attach event listeners after the interaction had the time to prepare itself (with willStart). The problem is that since it is asynchronous, all real events that may be dispatched in the meantime will be ignored. In this commit, we simply keep track of all click events and call each corresponding handler if necessary. It should help reduce instability in tours. 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 update fixes a visual issue where debit notes generated as PDFs incorrectly displayed 'INVOICE' instead of 'DEBIT NOTE'. This change ensures that invoices and debit notes are clearly differentiated in printed and emailed documents, improving clarity for customers and internal teams. The fix was driven by a customer request to improve the presentation of debit notes.
Original PR description
### Steps to reproduce the issue: 1. Download Invoice and Debit Notes 2. Go to an invoice (or create a new one) 3. Create a debit note for that invoice and print it or send it 4. In the PDF the title is 'INVOICE DINV....' instead of 'DEBIT NOTE DINV...' ### Reason to introduce the fix: Differentiate debit notes from invoices. opw-6252239 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268207
This update resolves an issue preventing users from utilizing the 'today' date operator within Odoo automation workflows. The fix adds the necessary 'context_today' value to the automation's execution context, ensuring the automation functions correctly based on the current date. This improves automation flexibility and functionality.
Original PR description
Steps: - Install web_studio and base_automation - Create a new automation - - Example: Update record on create - - Example: Apply on (`created_on = today`) - Trigger this automation - traceback context_today is undefined. Fix similar to https://github.com/odoo/odoo/pull/204172 base_automation uses safe_eval with a custom context which is missing `context_today` value, this fix add it. It also remove `.to_utc()` since it's purely client-side and this notion doesn't exist in the python server opw-6227927
This update ensures that binary files uploaded through forms now correctly store their filenames. Previously, this feature was limited to manual fields, causing issues with mimetype guessing and potential problems when migrating SaaS modules. This change improves the reliability of file uploads and supports broader usage across Odoo.
Original PR description
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual…
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual fields, which limits the usage of those fields in standard and is particularly problematic when Saas modules that use this feature are migrated to Python. Not storing the filename can lead to incorrect mimetype guesses. Given that a more appropriate condition has already been added in [2], it should no longer be necessary to restrict this feature to manual fields. This commit removes that restriction to allow standard binary fields to store their filename when uploaded through a form. Current behavior before PR: When uploading a file to a non-manual binary field that has a related '_filename' field, the filename will not be stored, which can later lead to incorrectly guessing the mimetype of the file. Desired behavior after PR is merged: Uploading a file to a non-manual binary field that has a related '_filename' field stores the filename of the file. Task related to this issue: https://www.odoo.com/odoo/project.task/5917543 [1] https://github.com/odoo/odoo/commit/0e2f3b144581c47d25a99cecdd7e058a3d55bcc3 [2] https://github.com/odoo/odoo/commit/1bcab2f42eebf98127416e54f31cd6e351938b7f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268014
1 change
Resolved issues and error corrections
This update resolves a technical issue related to how Odoo handles SEPA Direct Debit mandates. Specifically, it ensures that the correct partner bank is associated with each mandate, improving the reliability and accuracy of direct debit processing. This change enhances the security and stability of financial transactions.
Original PR description
Forward-Port-Of: odoo/enterprise#120901
22 changes
Enhancements to existing features
This update simplifies Partner Ledger reports for US and Canada users by removing the unnecessary display of account codes. The 'Show Account' filter is now automatically toggled off for these localizations, ensuring a cleaner report view and reducing visual clutter. This change improves the user experience for our key customers in these regions.
Original PR description
Purpose: US and Canada localizations don't use account codes, so it has no value on the report and creates visual clutter. Thus, a "Show Account" filter for Partner Ledger reports will be added in the Posted Entries dropdown, similar to Aged Payable and Aged Receivable reports. Current Behavior: The account code always appear as a column on partner ledgers for all countries. Expected Behavior: By default, companies in US and Canada will have the "Show Account" filter toggled off. All other countries will have the filter toggled on. task-6128250
This update streamlines how Odoo responds to events within the browser by replacing older listener methods with a more modern approach. Specifically, it enhances the responsiveness of key modules like Documents, Knowledge, and Sales, improving overall user experience. This change focuses on internal technical improvements.
Original PR description
* documents,iap_extract,knowledge,mrp_workorder,room,sign,social, spreadsheet_edition,spreadsheet_sale_management,timesheet_grid, web_enterprise,web_gantt,web_grid,web_studio,website_knowledge This commit converts useExternalListener to useListener where the target is window or document.
This update simplifies currency conversion within our financial reports. By centralizing currency rates in the `account.move.line` fields, we've eliminated redundant and complex report-specific calculations. This change improves report efficiency and reduces the risk of errors when currency exchange rates update.
Original PR description
Now that currency conversion is implemented in the `consolidation_rate` and `consolidation_balance` fields on `account.move.line`, the per-report boilerplate — manually joining the currency table and wrapping each column with `_currency_table_apply_rate` — is redundant. Replace it by passing `Query` objects through to the report queries and referencing the new fields directly. The conversion logic now lives in a single field definition; if the underlying rate mechanism changes, no report needs to be touched. The per-report diff is intentionally minimal: each site just drops the manual join and replaces the wrapped expression with the field reference.
Resolved issues and error corrections
This update fixes a minor issue in the demo data for the Odoo Enterprise HR payroll module. Specifically, a reference to an employee type was incorrect, preventing demo records for non-permanent employees from functioning properly. This change ensures the demo data accurately reflects the system's configuration.
Original PR description
The non-permanent employee demo records referenced a missing XML id l10n_id_contract_type_non_permanent for employee_type_id. Point them at the actual record, l10n_id_employee_type_non_permanent. task-6215687
This update resolves an issue where the project ID field was incorrectly marked as optional in the timesheet view. The system now correctly enforces the requirement for a project ID, ensuring accurate timesheet tracking and reporting. This change improves data integrity within the Enterprise module.
Original PR description
`project_id` is always required in the parent timesheet view. Setting it to `optional="hide"` in this inherited view is invalid. task-6113642
This update ensures that staff members, designated as part of an appointment type, are automatically added as attendees to new appointments created through the Gantt view. Previously, this step was manual. This change improves the user experience by streamlining appointment creation and ensuring staff are always included.
Original PR description
### Steps to reproduce: - Install 'Appointment' app - Configure an Appointment Type with your user as staff member - Go to the Appointments Gantt view - Click on the 'New' button to create a new…
### Steps to reproduce: - Install 'Appointment' app - Configure an Appointment Type with your user as staff member - Go to the Appointments Gantt view - Click on the 'New' button to create a new appointment > The staff member is not automatically added to the meeting's attendees (guests) list. ### Cause of Issue: When generating the default values for a new calendar event from the Gantt view (indicated by `booking_gantt_create_record` in the context), the base `default_get` method doesn't account for auto-adding staff members in obvious cases (when there's only one staff member available or the current user is one of the staff). ### Fix: Override `default_get` in `calendar.event` to automatically add these staff members when they are the only available option, providing a smarter and more seamless UX. opw-6181794 Note: the same PR was done for 18.0, but now this is moving it to master since it's more of a feature not a fix. Original PR: https://github.com/odoo/enterprise/pull/118331
This update improves the clarity of payslip reports by ensuring all line rates are consistently displayed with two decimal places. Previously, trailing zeros were shown, which was visually confusing. This change provides a more professional and accurate representation of employee compensation.
Original PR description
Problem: A lot of trailing zeros were displayed on the rate of each payslip line, in the salary tab of the payslip form. Solution: At first, it was decided to remove trailing zeros. But in the end, we chose to always display 2 decimal places. Task-6310227
This update resolves a technical issue that previously caused errors when users attempted to copy heading links within the knowledge editor. The change removes a dependency on the HistoryPlugin, streamlining the process and ensuring a smoother user experience. This improves the reliability of the knowledge editor for all users.
Original PR description
Prevent traceback when clicking the button to copy a heading link to the clipboard. Technical - Commit https://github.com/odoo/enterprise/commit/70bb74faecadea768bb17a4feb69fa327623ab5d removed the history dependency, although commit() is provided by HistoryPlugin and still requires it. Task-6267431
This change resolves a potential issue during software updates. A previous version of the Point of Sale module caused conflicts with the new stable version, leading to upgrade script errors. Renaming the 'obox_pos' module ensures compatibility and a smooth update process.
Original PR description
A stable module `obox_point_of_sale` was added in saas-19.3 but in master a module `obox_pos` is also present. This will cause some big upgrade script in the FW of `obox_point_of_sale` so renaming the module in master to prevent this error.
This update resolves a problem where test data from one test case was incorrectly carried over to subsequent tests, leading to unreliable results. The fix ensures that the test environment is properly reset after each test, preventing this 'cross-test pollution' and improving the stability of our testing process.
Original PR description
At each test end, the DB is reverted to the Savepoint, but the registry is not reloaded. This causes cross-test pollution This commit fixes this by reloading the registry after each test runbot-error-940278
This update ensures that the employee is automatically selected when creating a new off-cycle payslip. Previously, users had to manually choose the employee, which was a manual and potentially confusing step. This change streamlines the process and improves user efficiency.
Original PR description
Steps to reporoduce: 1) open any employee who has at least one payslip 2) open the employee view and click on payslip smart button 3) List view will open, now click on 'new Off-cycle' button 4) Employee is not there by default. Issue: The employee should be set by default. Solution: Add default_employee_id to the action context so that the employee is set by default when creating a new off-cycle payslip. task-6309649
This update improves the clarity of payslip reports by only showing bank accounts when there's a positive payment amount. Previously, bank accounts were always displayed, even with zero balances. This change simplifies the report and reduces visual clutter for users.
Original PR description
Now, on payslip's reports, bank accounts are shown at the bottom of the page only if there is a strictly positive amount to pay. task-6311010
This update replaces a problematic function (`cleanTerm`) with a more robust one (`normalize`) in the mail system. Removing the fallback to empty strings prevents hidden errors and ensures data integrity, leading to more reliable email processing.
Original PR description
This commit removes the `cleanTerm` function and replaces its usages with `normalize`. When the value provided to `cleanTerm` is not a string, it falls back to returning an empty string. This is seen as a bad practice, as it could easily hide programming errors. There is no sense to calling `normalize` on something other than a string; if another kind of value ends up in there, it is most likely a mistake. [Task-4818712](https://www.odoo.com/odoo/1519/tasks/4818712) Community: https://github.com/odoo/odoo/pull/262514
This update corrects a display issue where the 'DIMONA Category' column was missing from employee type lists for employee types not associated with a specific country. The fix ensures this column is always visible, regardless of the employee type's country setting, improving data visibility and reporting accuracy.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll 2. Go to the list view of employee types 3. Show the column DIMONA Category 4. The category is missing for some records (Employee, Student, etc) Cause: The field is invisible if the country of the employee type is not Belgium. But it should still be visible for employee types without a country. Fix: change the invisible condition to allow employee types without country. Task: 6303674
Features or functions removed from Odoo
This update removes the ability for AI conversations to suggest channel completion with '#' symbols. This change aligns the AI experience with the recent removal of channel autocompletion in the Discuss app, streamlining the user interface and improving consistency. Now, only '@' mentions are suggested within AI chat and AI composer channels.
Original PR description
This PR removes support for '#' channel autocompletion from AI conversations to align with the removal of channel autocompletion in Discuss. Only '@' suggestions remain available in AI chat and AI composer channels. community: https://github.com/odoo/odoo/pull/269214 task-6113197
This pull request removes outdated code related to generating payroll payslips in the Odoo Enterprise module. This cleanup improves the codebase's efficiency and reduces potential maintenance overhead. The change has no direct impact on business users.
Original PR description
. Remove hr.payroll.generate.warrant.payslips dead code task-6308624
This update removes a deprecated overtime work entry type within the US payroll module. The change ensures the system aligns with current regulations and simplifies payroll processing. This update primarily affects how overtime hours are tracked and reported.
Original PR description
- changed the reference to the overtime work enty type as it's removed. task-id: 6281648
This update removes outdated 'onWillRender' hooks used in the HR payroll module. As part of the ongoing Owl 3 migration, these hooks have been replaced with modern alternatives to ensure the payroll system continues to function correctly and efficiently. This change improves system stability and prepares for future updates.
Original PR description
As part of the Owl 3 migration, replace deprecated onWillRender hooks with the appropriate Owl 3 alternatives.
Code cleanup and technical improvements
This update removes outdated and easily replaceable 'useComponent' elements across several Odoo modules. This refactoring streamlines the codebase and improves maintainability. The changes primarily affect the account reports and knowledge modules, ensuring a cleaner and more efficient system.
Original PR description
Remove some useComponent that can easily be replaced. Task-6268109 PR community: https://github.com/odoo/odoo/pull/267742
This update modernizes the IoT module by transitioning to a new standard for defining component properties (OWL3). Unused prop definitions related to a reporting component have also been removed, streamlining the module's structure and reducing complexity.
Original PR description
This commit changes all the props definitions in the IoT module to the new OWL3 style. It also removes the prop definitions for the `IoTReportLocalStorage` component, as the props are never used.
This update refactors how Odoo determines the current website, moving from a database query to a controller-based approach. This change enhances efficiency and stability by avoiding reliance on the original `website` model method. The update improves the underlying data retrieval process.
Original PR description
The corresponding community PR adds a controller `/website/get_current_website_id` to get the current website. This commit uses it instead of the `website` model's method `get_current_website`.
This update simplifies website routing by replacing older methods with a more reliable approach. It ensures that website-specific data is consistently accessed, leading to improved accuracy and stability. Future work will address more complex fallback scenarios.
Original PR description
[REF] base/website: migrate controllers and models to `self.env.website` Replaced legacy `get_current_website()` calls with `self.env.website` across controllers and models where fallback behavior…
[REF] base/website: migrate controllers and models to `self.env.website` Replaced legacy `get_current_website()` calls with `self.env.website` across controllers and models where fallback behavior was unintended. Mechanics & Context: - For routes defined with `website=True`, the routing layer automatically injects `website_id` into the context. - `self.env.website` natively reads this `website_id` from the context, behaving exactly like `get_current_website(fallback=False)` (without falling back to `host_id` or the first available website). - `host_id` (added during routing) represents the website matched strictly by domain name, independent of `website=True` or website-module specific overrides. Scope of Cleanup: This PR intentionally focuses only on the call sites that can be safely converted to a plain `self.env.website`. Locations that require explicit fallback handling, such as falling back to `host_id` (the strict domain-matched website) or a default website, have been left out of this pass when it's linked to a complex feature or behavior. They require deeper analysis and will be addressed in a subsequent PR.
9 changes
Enhancements to existing features
This update enhances the global filters in Odoo Enterprise by providing an option to return the customer's label instead of just their ID. This change offers greater flexibility for users who need the customer's name or description within their filters, improving data usability.
Original PR description
Before this commit: If you use ODOO.FILTER.VALUE and have a customer set in the global filter, it returns the id of the customer. That can be useful in some cases but in others you might simply want the label. Task: 6167605
Resolved issues and error corrections
This update resolves an issue where opening the chatter in the accounting module was unintentionally unfolding financial lines. This change ensures a smoother and more efficient user experience when accessing chatter, avoiding potential performance impacts. The fix focuses on streamlining the chatter opening process.
Original PR description
Before this commit, open_chatter use the selectStatementLine function that will unfold the line. But we don't want the unfold when opening the chatter. task-6306311
This update ensures that sales and purchase reports exported as XLSX files from the Philippines (SLSP) consistently display partner VAT values and row sequences. Previously, the order of these rows was unpredictable, leading to test failures. This fix guarantees a reliable and accurate export format.
Original PR description
Description of the issue this commit addresses: SLSP XLSX partner rows were emitted in a non-deterministic order, which made the PH sales/purchases export tests sometimes swap partner VAT values. --- Desired behavior after this commit is merged: This commit keeps the SLSP partner rows in a stable order so the XLSX export always matches the expected partner VAT and row sequence. --- runbot-[162182](https://runbot.odoo.com/odoo/error/162182) Forward-Port-Of: odoo/enterprise#120052
This update enhances the visual clarity of the account reconciliation search dialog. The changes remove text truncation and reposition date and balance fields, making it easier for users to quickly review key financial information. This improves the user experience for managing bank reconciliations.
Original PR description
This commit will remove the text-truncate from the reference so that we have it full. Also removing the align item so that the date and balance are on top. no task id
This update corrects a previous issue where fully settled customers with past pay-later payments were incorrectly prevented from seeing their customer statements. The fix now checks for any past pay-later payment lines, ensuring the statement button remains visible regardless of the customer's overall balance. This improves the user experience for customers who have completed their payments.
Original PR description
The override of _compute_has_moves was checking `total_due != 0` to set `has_moves` on for PoS pay_later customers. Once the customer is fully settled however, `total_due` is 0 and the check does not pass anymore, so `has_moves` goes back to `False` and the Customer Statement button hides for them, even though they had past pay_later payment lines. The fix is to check directly for any past pay_later `pos.payment` instead, which covers the cases where partner had used pay_later payment methods before, regardless if they have settled their total due or not. opw-6173760 Forward-Port-Of: odoo/enterprise#120770 Forward-Port-Of: odoo/enterprise#116536
This update resolves an issue where focusing on the end date within a daterange widget was incorrectly modifying the start date. The fix ensures that the correct date field is updated when a user interacts with the end date input, improving data accuracy and preventing unintended changes.
Original PR description
When a daterange widget is used (e.g., `deferred_start_date` coupled with `deferred_end_date`), focusing on the end date input was incorrectly modifying the start date field. This occurred because the `focusin` event was resolving the field name from the parent widget rather than the specific input focused. This commit updates `onFocusFieldWidget` and `getFullFieldName` to accept and evaluate the specific `event.target`. For `o_field_daterange` widgets, it now extracts the correct field name from the target's `data-field` attribute, ensuring the correct date field is updated. opw-6250048
This update resolves an issue where sending NFC-e invoices would halt the POS synchronization process when IAP credits were exhausted. The change prevents a blocking error, ensuring that POS transactions continue to sync smoothly even without available IAP credits for tax calculations. This improves the reliability of the POS system.
Original PR description
When sending an NFC-e, tax calculation is done by calling Avatax through IAP. If the IAP account has no credits left, iap_jsonrpc() raises an InsufficientCreditError. opw-6290857
This update resolves a minor issue in the marketing automation dashboard by correcting calculations for key engagement metrics. Specifically, the KPI engagement rate and its n-1 counterpart are now accurately calculated using error handling to prevent display issues when data is missing. This ensures more reliable reporting on marketing campaign performance.
Original PR description
This commit fixes two issues:
- KPI engagement rate ('Mailing Statistics'!B16) should be =iferror((B7+B9)/B10),0)
- KPI engagement rate n-1 ('Mailing Statistics'!C16) should be =iferror((C7+C9)/C10),0)
Task: 5418449Code cleanup and technical improvements
This update ensures that references to a key function, `fragment_to_query_string`, are correctly managed as it's integrated into the core HTTP handling within Odoo. This refactoring improves the stability and maintainability of the social media controllers, ensuring consistent behavior across the platform.
Original PR description
The aim of this commit is to keep referencing fragment_to_query_string correctly as it is moved into `http.py`. task-id: 6071808
10 changes
Resolved issues and error corrections
This update fixes a visual issue in the ATO submission wizard for Australian payroll. The checkbox to accept terms and conditions was misaligned with the text, particularly on wider screens. This change ensures a consistent and user-friendly experience when submitting payslips or payruns to the ATO.
Original PR description
- Step to reproduce: with l10n_au_hr_payroll_account installed and validated payslips or payruns click "Sign & Submit to ATO" -> wizard opens with checkbox to accept T&C, mght be misaligned depending on window width - Cause: if text fills full width then checkbox is moved above. - Solution: using d-flex and utilities, force checkbox on same line as text and allow text to split if necessary. Task: 6051482
This update fixes a potential issue where Odoo would incorrectly try to install auto-install modules if a required dependency was missing. Now, if an auto-install module has a missing dependency, it won't be marked for installation, preventing installation errors and improving database startup times.
Original PR description
Let's consider an auto-install module `A` having 2 dependencies, one to `base` and the second to custom module `B`. If module `B` is not present in the addons path (i.e is unknown), during a new database initialization module `A` would still be marked as `to install`. This commit ensures that if an auto-install module has a missing dependency, it will not be marked as `to install`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270346
This update eliminates a distracting, empty vertical scrollbar that appeared in Odoo's notebook headers when the tabs fit within the window. The fix ensures a cleaner user experience by correctly managing scrollbar behavior, without impacting the functionality of the horizontal tab bar. This was previously fixed in the master branch and now applied to version 18.0.
Original PR description
### Description `.o_notebook_headers` sets `overflow-x: auto` while leaving `overflow-y` at its default `visible`. Per the [CSS overflow…
### Description `.o_notebook_headers` sets `overflow-x: auto` while leaving `overflow-y` at its default `visible`. Per the [CSS overflow spec](https://www.w3.org/TR/css-overflow-3/#overflow-properties), when one axis is not `visible`, the computed value of the `visible` axis becomes `auto`. So `overflow-y` resolves to `auto`, and a sub-pixel vertical overflow (the active tab border / nav-link height) renders a useless vertical scrollbar next to the tabs — even when the tabs fit horizontally (no horizontal overflow). Pinning `overflow-y: hidden` suppresses it, without affecting the legitimate horizontal scrolling of the tab bar when the tabs don't fit. ### Steps to reproduce 1. Open any form view with a notebook in a maximized window where the tabs fit horizontally. 2. A short vertical scrollbar is drawn at the right of the tab bar, scrolling nothing. ### Note Already fixed on `master` (`addons/web/static/src/core/notebook/notebook.scss` has `overflow-y: hidden`). This backports the one-line fix to 18.0. <img width="2637" height="1924" alt="29476" src="https://github.com/user-attachments/assets/9b51723d-5b98-4047-b51a-65c56c2505ce" /> <img width="1661" height="499" alt="88342" src="https://github.com/user-attachments/assets/0e7299f1-7b2b-4b19-9c2f-ff9bd3985e98" />
This update corrects a bug where the link popover title didn't update when a file's name was changed within the HTML editor. Now, the popover displays the correct, current file name, ensuring users always see accurate information about attached files. This improves the user experience and data consistency.
Original PR description
Problem: After updating a file name, the link popover still shows the original file name. Cause: The link popover always displays the attachment name instead of the current link content. Solution: Use the link content as the popover title so it reflects the updated file title. Steps to reproduce: - Go to To-Do → Create New. - Upload a file. - Change its title. - Observe that the title shown in the link popover still uses the original file name. task-6213840 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the composer field in Odoo was misinterpreting the 'End' key when a mention was added. By adding a special character (FEFF), the browser now correctly positions the cursor at the end of the line, improving the user experience for composing messages.
Original PR description
### Purpose of this PR: - Inserting a mention in the composer results in a paragraph ending with a bare `<a>` element and no trailing text node. This causes the browser to mishandle the End key, moving the caret to the start of the next paragraph instead of the end of the current line. - Fix by appending a \uFEFF (zero-width no-break space) text node. task-6295924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the sale stock module installation would fail due to a warehouse constraint warning. The fix ensures that the installation process continues smoothly even when a company initially lacks a defined warehouse, preventing unnecessary installation interruptions.
Original PR description
Steps to reproduce the bug:
- Have a database with sale_management installed and at least two companies (Company 1 and Company 2)
- Confirm sale orders with storable products under each company
- Install the stock module (which triggers sale_stock as a bridge module)
Problem:
The installation raised a RedirectWarning ("Please create a warehouse for company 2") and aborted. During sale_stock installation, _init_column initialises the new `warehouse_id` column on `sale.order` via SQL. Orders belonging to companies that have no warehouse yet (company 2, since `create_missing_warehouse` only creates one for the first company at that point) remain NULL. The stored-field recompute then calls write(), which fires _check_warehouse. That constraint calls _warehouse_redirect_warning() for each company without a warehouse, raising a RedirectWarning that aborts the install.
opw-6302537This update resolves an issue where markdown commands and shortcuts were unexpectedly active within code blocks, causing errors. The fix prevents commands like `/table` from being executed inside code blocks, ensuring code blocks function as intended and improving the user experience. This ensures consistent and reliable code block functionality.
Original PR description
### Steps to reproduce: - Go to ToDo. - Create a code block using `/code`. - Place the cursor inside the code block. - Type `/table` and select the table command. - A traceback occurs. ### Purpose of this PR: - Commands and markdown shorthands should not be available inside code blocks. However, typing `/` inside a `<pre>` opened the command palette, allowing structural commands such as `/table` to be executed and causing a traceback. Similarly, markdown shorthands such as `* ` and `1.` were still active, unexpectedly transforming code content into lists. ### This PR fixes the issue by: - Disabling the command palette when the cursor is inside a `<pre>` element. - Disabling markdown shorthands inside `<pre>` elements by registering an `is_shorthand_available_predicates` predicate. task-6292231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that binary files uploaded through forms now store their original filenames. Previously, this feature was limited to manual fields, causing issues with mimetype detection and hindering the migration of SaaS modules. This change improves file handling and reliability.
Original PR description
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual…
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual fields, which limits the usage of those fields in standard and is particularly problematic when Saas modules that use this feature are migrated to Python. Not storing the filename can lead to incorrect mimetype guesses. Given that a more appropriate condition has already been added in [2], it should no longer be necessary to restrict this feature to manual fields. This commit removes that restriction to allow standard binary fields to store their filename when uploaded through a form. Current behavior before PR: When uploading a file to a non-manual binary field that has a related '_filename' field, the filename will not be stored, which can later lead to incorrectly guessing the mimetype of the file. Desired behavior after PR is merged: Uploading a file to a non-manual binary field that has a related '_filename' field stores the filename of the file. Task related to this issue: https://www.odoo.com/odoo/project.task/5917543 [1] https://github.com/odoo/odoo/commit/0e2f3b144581c47d25a99cecdd7e058a3d55bcc3 [2] https://github.com/odoo/odoo/commit/1bcab2f42eebf98127416e54f31cd6e351938b7f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268014
This update fixes a translation error in the Odoo POS system for Spanish-speaking users. Previously, the display of available event seats showed the directional term 'izquierda' instead of the correct 'restantes'. This change ensures users see the accurate remaining seat count, improving the user experience.
Original PR description
Description of the issue/feature this PR addresses: The string "left" in `pos_event` (used to show remaining/available seat count, e.g. "5 left") was translated in `es.po` as "izquierda" (directional meaning) instead of "restantes" (remaining count). The `es_419.po` file already had the correct translation "restantes". Current behavior before PR: Users with Spanish (es) language see "5 izquierda" in the event configurator popup and product card instead of "5 restantes". Desired behavior after PR is merged: The available seat count shows "5 restantes", consistent with the es_419.po translation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor issue where the invoiced quantity was slightly off (rounding error) after importing XML bills and linking them to purchase orders. The fix ensures accurate quantity calculations by addressing a decimal precision discrepancy during the import process. This prevents discrepancies in invoice totals.
Original PR description
When importing an XML bill and linkin git to a purcahse order, the invoiced quantity may be computed incorrectly, due to a decimal precision mismatch. Steps to reproduce: - Import an XML bill having a line with quantity 1800.0 - Link to a purchase order with the same line Issue: The invoiced quantity will be computed with 1 cent difference (1800.01) Analysis: Because the system forced a decimal precision of 13 for 'Product Unit of Measure', quantity is imported as 1800.0000000000016. Later, when computing the invoiced quantity, the system round the quantity using 'UP' strategy, rounding the amount to 1800.01 opw-6194824
2 changes
Resolved issues and error corrections
This update fixes an issue where emojis, particularly complex ones like `👨🚒`, were being displayed incorrectly due to how they were encoded. The team backported a more robust regex pattern from a recent version of Odoo to ensure all emojis are correctly rendered. This improves the overall email experience for users.
Original PR description
Bug === Some emoji like `👨🚒` are separated, because they are built using `👨 + Emoji_Modifier + 🚒` (`\uFE0F` can also be used to get the variant of the emoji). Adapt the regex to take into account those Unicode variations. Task-5491124
Documentation and clarification updates
This pull request formally signs David Sonnet's Individual Contributor License Agreement for Odoo. This ensures compliance with Odoo's licensing terms and allows David to contribute to the project. The addition of the `dsonnet.md` document provides the necessary legal documentation.
Original PR description
Signing the Odoo Individual Contributor License Agreement v1.0. Adds `doc/cla/individual/dsonnet.md`. --- I confirm I have read the PR guidelines at www.odoo.com/submit-pr