Friday, May 29, 2026
28 changes · 19.0
Enhancements to existing features
Analytic reports can now be grouped by product category, making it easier to review costs and revenues by product area. This helps business users spot performance trends across product categories without needing custom reporting changes.
Original PR description
Add the related (non-stored) 'product_category' field on the account.analytic.line model to make it available in the Analytic Reporting "Group By" task-6219418 Forward-Port-Of: odoo/odoo#266378
This update clarifies payslip reports by separating full days from half days. Previously, both types were shown together, making it difficult to understand work hours. This change provides a clearer breakdown of employee work time reflected on payslips.
Original PR description
In order to clearly distinguish work days that extended full day or half day, the worked days under the payslips will not display both entries as separate types with the half days flagged Task: 5975762
This update enhances Odoo's compatibility with Swedish Point of Sale blackboxes. It now supports a faster data transfer rate (57600 baud) for these devices, improving the reliability and speed of data collection. This ensures accurate sales data is transmitted from the blackboxes to the Odoo system.
Original PR description
This commit adds support for Swedish blackboxes using a 57600 baud rate, as opposed to 9600 used by older models.
Resolved issues and error corrections
This fix helps the web interface handle name searches more efficiently when display names require costly preparation. By batching the work, users may see smoother performance in screens with many records, without any change to visible behavior.
Original PR description
If a method has a costly setup in `_compute_display_name` but that can be batched, allow the ORM to do the setup only once for all the lines to compute
This update makes an automated web test more stable by preventing the same quick-create action from being triggered twice. It helps reduce false test failures in Odoo's validation pipeline without changing day-to-day user behavior.
Original PR description
This commit fixes a non deterministic one2many field test by ensuring that we don't quick create the record twice.
Before this commit, it might sometimes happen that the validation of the input ("Enter", by default) produced a second name_create. Note that in practice this is highly unlikely to happen as if the user presses Enter, the "Quick create" item in the dropdown only appears during a single frame, thus making impossible for the user to click on it.
It's the exact same issue as the one fixed by odoo/odoo#256582.
runbot error~242443
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-prThis fix prevents the Point of Sale HR screen from crashing when session information from the backend is missing. It uses the active session directly, improving reliability for users managing POS sessions with employees.
Original PR description
`pos.config.current_session_id` is a computed field from the backend. In some cases, it's possible that we don't have this field causing the following error
```
TypeError: undefined is not an object
(evaluating 'this.config.current_session_id.id')
```
task: https://www.odoo.com/odoo/project/1737/tasks/6253422
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects minor visual alignment issues in the portal, including alert text spacing and card positioning for Knowledge and Document content. It helps keep portal pages cleaner and more consistent for users without changing functionality.
Original PR description
The alert content is vertically misaligned due to the mb-1. The Knowledge / Document cards are not inserted inside a `row` which misaligns them due to the missing margin and padding. This is to be reworked on master forwardport since here we're dealing with nested rows withouth intermediary columns. SCSS only fix for stable. task-5262108 <img width="663" height="553" alt="image" src="https://github.com/user-attachments/assets/18dd6c2f-47f0-4ba8-91cb-f9c5a2e0fda4" /> > [!NOTE] > On the master forwardport I'll review the DOM to avoid the nested row and unnecessary margin instead of the scss fix here. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where saving certain sparse field values, such as dates, timestamps, or binary files, could fail with an error. Businesses using these custom field types can now store those values reliably without extra workarounds.
Original PR description
Storing a sparse field of type Date, Datetime or Binary raises a TypeError because json.dumps() cannot natively serialize the Python objects returned by convert_to_read (date/datetime instances and bytes). Fix Serialized.convert_to_cache to pass json_default (from odoo.tools.json) as the default serializer to json.dumps(). This handles Date, Datetime and Binary values without any extra conversion step in _inverse_sparse, and reuses the existing Odoo infrastructure instead of introducing a custom helper. Steps to reproduce: 1. Create a model with a sparse field of type Date, Datetime or Binary 2. Set a value on it 3. → TypeError: Object of type date is not JSON serializable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users create a vendor bill from a specific purchase journal dashboard, Odoo now uses that selected journal instead of the default purchase journal. This prevents bills from being filed under the wrong journal and reduces manual corrections for accounting teams.
Original PR description
This commit fixes the default journal used when pressing "Create a bill manually" on a purchase journal in the journals dashboard. Previously, when creating a bill manually, it would be created on the default purchase journal. Now, the correct purchase journal is chosen depending on which journal I pressed the "creating a bill manually" link from. task-6167135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when sending an Italian electronic invoice that does not have expected attachment or invoice data available. It helps ensure affected invoices can be processed without an unexpected system crash.
Original PR description
If a move has no l10n_it_edi_attachment_file and no l10n_it_edi_values in move_data, the variable attachment_name is never defined, causing an UnboundLocalError. Ticket [link](https://www.odoo.com/odoo/project.task/6064501) opw-6064501
The remaining-days display now gives more precise wording for dates that are very close, such as tomorrow, instead of broad labels like "next month." This helps users better understand upcoming deadlines at a glance and avoid confusion around month boundaries.
Original PR description
Luxon is not very accurate when the field is close to today: If today is Apr 30, so a deadline set to May 1 will be displayed as "Next month". In practice, it is not wrong, but it is not very accurate. task-6175442
The employee organization chart now handles older or imported employee records that are missing update timestamps. This prevents the employee form from crashing and lets users view org charts normally, with no change for standard records.
Original PR description
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python #…
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python # addons/hr_org_chart/controllers/hr_org_chart.py:35 write_date=int(employee.write_date.timestamp()) * 1000, # to have it in milliseconds for js \`\`\` When \`hr_employee.write_date\` is NULL the ORM returns \`False\` for the field, so the unconditional \`.timestamp()\` call raises: \`\`\` AttributeError: 'bool' object has no attribute 'timestamp' \`\`\` This crashes the employee form view on click for any record with NULL \`write_date\`. NULL audit columns can occur in legacy databases — records inserted via direct SQL by data-loaders, rows carried forward from very old Odoo versions that did not always populate \`_log_access\` columns, or data restored from anonymised backups. The ORM's \`vals.setdefault\` defaults in \`_log_access\` do not override an explicit falsy value passed by callers. This is a regression vs 18.0 — the 18.0 \`_prepare_employee_data\` did not include \`write_date\` at all. ### Behaviour before this PR Opening the form view of an employee with NULL \`write_date\` (any affected employee record) raises \`AttributeError\` and the org chart fails to load. ### Behaviour after this PR The controller falls back to \`0\` when \`write_date\` is missing — the same defensive pattern already used in \`odoo/addons/base/models/avatar_mixin.py:67\`: \`\`\`python bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp() if self.create_date else "")) \`\`\` The org chart loads; the JS cache key for that one record is \`0\` until the record is next written (which will set \`write_date\` via the normal ORM path). No user-visible regression on healthy rows.
Spreadsheet date filter labels are now standardized so they display consistently across different Chrome versions. This prevents confusing test results and helps ensure users see stable date and interval text in spreadsheet and dashboard features.
Original PR description
Some dependencies in the chrome build changed between chrome 145 and 148 which changes the output value of luxon.Interval.toLocaleString, more specifically, some space characters were changed and the tests can pass or not depending on the chrome version they run with. This revision forces a standardized output. task-6233171 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#265565
Archived user-defined filters linked to a deleted action are now removed at the same time as active filters. This prevents users from seeing an error when viewing archived filters after an action has been deleted.
Original PR description
How to reproduce: - Delete an action linked to an inactive user-defined filter. - Go to the User-Defined menu, - Show inactive filters (with "Archived filter") - Got a MissingError. Explanation: odoo/odoo#156622 fixes an inconsistency when deleting an action, but the reviewer was "amorti" so he (I) forgot to account for inactive "ir.filters". Add active_test=False to ensure inactive "ir.filters" are also removed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266518 Forward-Port-Of: odoo/odoo#262195
The point of sale customer display link is now generated in one reusable place instead of only inside the open action. This helps related modules use the same correct link format, including required device and access details, reducing the risk of inconsistent displays.
Original PR description
Previously, the logic to build the customer display URL was scoped entirely within the `openCustomerDisplay` method. This prevented other modules from easily reusing the exact same URL formatting logic, leading to duplicated or inconsistent URL construction. By extracting this logic into a dedicated `customerDisplayURL` getter, we allow extending modules (such as `pos_mobile`) to reliably access the correctly formatted URL. This ensures that essential parameters, like the device UUID and access token, are consistently applied whenever the customer display URL is needed across the codebase. opw-6212067 See also: https://github.com/odoo/enterprise/pull/118458 Forward-Port-Of: odoo/odoo#266841 Forward-Port-Of: odoo/odoo#266581
This change updates the required lxml software dependency so Odoo installs correctly on newer operating system versions such as Debian Trixie and Ubuntu Resolute. It helps avoid installation or upgrade issues caused by outdated dependency requirements, with no expected change to day-to-day product behavior.
Original PR description
Note: support for version 6+ of lxml has been merged in odoo/odoo@4b1797fccdf1447a8adb817148cc39bc322428a6 runbot-938365 Forward-Port-Of: odoo/odoo#266627
This fix makes Odoo handle invalid JSON responses consistently, regardless of which optional JSON parsing library is installed on the server. It prevents unexpected failures in existing error-handling flows caused by environment-specific package differences.
Original PR description
The requests library uses different libraries to parse json objects depending on whether or not the simplejson library is installed (https://github.com/psf/requests/blob/dc9dbdfb3434c6e58d48fd102f93e5342308817e/src/requests/compat.py#L74). This in turn causes our try/excepts to fail if the simplejson library is installed in the env we simply re-raise the json error in case the simplejson library is installed so our try/excepts flows are not broken by the existence of a random package opw-6150349 Forward-Port-Of: odoo/odoo#266905 Forward-Port-Of: odoo/odoo#264303
Code blocks in the HTML editor now correctly show multiple spaces instead of displaying the text " ". This prevents confusing formatting artifacts when users add code blocks after typing text with consecutive spaces.
Original PR description
Step to reproduce: - Go to To-Do → Create New - Type text with multiple consecutive spaces in the same line - In the same line → insert a /code block Description of the issue: Multiple spaces are converted into ` ` inside the code block. Cause: When the code block is processed for syntax highlighting, its `innerHTML` is used as the source text. During this process, ` ` is not handled as a result it remains as literal text, so syntax highlighting displays ` ` instead of a normal space. Solution: Convert ` ` into a normal space before the content is used for syntax highlighting. task-6184686
Shop category lists now only show categories that belong to the current website. This prevents shoppers from seeing links that lead to missing pages when a category is assigned to another website.
Original PR description
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. -…
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. - Open the shop page on website > Click on Desks category. Issue: --- - The Components subcategory is still displayed on Website 1. - Clicking on it leads to a Not Found page since the category is not assigned to that website. Root cause: --- - At [1], In the category filmstrip template, subcategories are fetched without filtering based on website access. - As a result, categories restricted to another website are still shown. Solution: --- - Filter categories using the `can_access_from_current_website` method to ensure only categories accessible from the current website are displayed. [1]https://github.com/odoo/odoo/blob/900fc043064216c5943ea07392d8120be7b50b63/addons/website_sale/views/templates.xml#L758-L769 opw-6159549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262410
This fixes an issue where translated website placeholders could show hidden formatting markup instead of normal text. Business users editing translated blog pages will now see clean placeholder labels, improving the website translation experience.
Original PR description
Since placeholder attribute is translated, for non-form elements placeholder attributes that contain a translation <span/> need to be unwrapped to restore the plain text value. Steps to reproduce the issue: - Have website and website_blog installed - Add a second language - Open a blog post in your second lanuage - Start translating - Remove the blog title => Shown placeholder text is <span ...> task-5190459 Forward-Port-Of: odoo/odoo#265575 Forward-Port-Of: odoo/odoo#263320
This update corrects a bug in the employee overtime calculation process. Previously, overlapping overtimes across days could lead to inaccurate interval calculations due to rounding errors. The fix ensures overtimes don't bleed into the previous day, preventing these calculation discrepancies.
Original PR description
**Problem:** When an attendance has overtimes across multiple days, those overtimes can overlap when calculating their intervals. There will always be rounding errors since only the durations are…
**Problem:** When an attendance has overtimes across multiple days, those overtimes can overlap when calculating their intervals. There will always be rounding errors since only the durations are saved to 3 decimals, but this is normally fine since the durations are accumulated when calculating the next interval. However, on a day boundary in the employee timezone, the end of the interval is forced to the end of day, which incidentally removes the rounding error. This causes the overlap when calculating the next interval since its start will be based on the rounded duration, not the actual end of day. **Steps to Reproduce:** - Configure an overtime rule where >8 hours is considered overtime, and a second rule applies to non-working days - Set Overtime Rule on employee "Anita Oliver" - Set employee work entry source to "Attendances" - Create an attendance that exceeds 8 hours in a day and crosses into a non-working day and creates enough of a rounding error (see unit test) -> Traceback error: `ValueError: Expected singleton: hr.attendance.overtime.line(1, 2)` **Solution:** Add an additional check to ensure the overtime cannot start on the previous day. opw-6067969
This update addresses an issue where test Odoo databases, mimicking production environments, were incorrectly identified as having valid subscriptions. By adding a specific check for neutralized SaaS databases, we ensure accurate subscription verification and prevent potential disruptions to users. This improves the reliability of the Odoo Enterprise platform.
Original PR description
Odoo.com does not create a distinction between a production and duplicated SAAS database. This allows test databases to pass the check for subscription. This commit adds an additional check for duplicated SAAS databases with a neutralised status. task-6249752
This update resolves an issue where PDF documents received via email were incorrectly displayed with a duplicate iframe preview. The fix ensures that the document preview accurately shows the PDF content, addressing a visual inconsistency. This improvement enhances the user experience when accessing documents from email attachments.
Original PR description
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the…
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the document preview - Preview is split in two iframes, both with the same content (pdf) **Issue:** Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`. ``` <iframe t-if="state.file.isPdf" ... <iframe t-if="state.file.isText" ... ``` It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file. **Fix:** Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`. Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: `<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">` which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450 opw-6018536 Forward-Port-Of: odoo/enterprise#114759 Forward-Port-Of: odoo/enterprise#112041
This update corrects a bug where paying with the 'customer account' method on a zero-priced POS order resulted in an incorrect payment calculation. The fix hides the 'pay_later' payment option in this scenario, aligning with business requirements and preventing inaccurate financial reporting. This ensures proper order settlement.
Original PR description
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any…
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any amount to pay, ex 100$ - fulfill the order. Observation: - the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer) - As per PO, this flow doesn't make sense Issue: - customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] - [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35 Fix: - we hide payment method of type "pay_later" in case of 0 price order opw-6123699 Forward-Port-Of: odoo/enterprise#118093 Forward-Port-Of: odoo/enterprise#116556
This update fixes an issue where mobile point-of-sale links to customer displays were inaccurate. By standardizing the URL generation process with the main POS system, the mobile app now correctly identifies and displays customer information, ensuring a consistent and reliable user experience. This resolves a technical inconsistency that could have impacted customer data tracking.
Original PR description
The `_showDisplayAndGoToUrl` method in the mobile navbar was manually constructing its own URL for the customer display. This hardcoded string incorrectly omitted the device UUID, which is required for proper display identification and tracking. By leveraging the new `customerDisplayURL` getter introduced in the parent `Navbar` component, the mobile implementation now utilizes the exact same URL logic as the standard point of sale. This resolves the inconsistency and ensures the customer display functions reliably on mobile devices. opw-6212067 Forward-Port-Of: odoo/enterprise#118602 Forward-Port-Of: odoo/enterprise#118458
This update automatically adds the staff user to appointment attendee lists when creating new appointments through the Gantt view. Previously, staff members weren't automatically included, requiring manual addition. This change improves the user experience by streamlining appointment creation and ensuring staff are always part of the meeting.
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 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
This update fixes an issue where global invoices created after a POS order at the end of the month were incorrectly displaying the following month. The system now accurately converts POS order dates to the correct Mexican timezone, ensuring invoices reflect the accurate order date and month.
Original PR description
**PROBLEM** When creating a global invoice, with the last order being at the end of the last day of the month, the month of the global invoice will not be correct. (e.g, order made at the end of May and global invoice created for June). date_order is stored in utc. To compute the day the order was made, we need to convert to a MX timezone. **STEP TO REPRODUCE** 1. Create an pos order at the end of the last day of a month (for example, at 10PM in local MX time). 2. Create a global invoice with this order. 3. Notice the global invoice month will be the month after the one of the order. opw-6221049 Forward-Port-Of: odoo/enterprise#118170
This update fixes a potential issue where users could incorrectly select inactive Intrastat codes when configuring products. The system now displays a warning message if an inactive code is chosen, ensuring data accuracy and preventing incorrect reporting. This improves data integrity for Intrastat compliance.
Original PR description
Problem: When choosing an intrastat code on a product, all the codes are shown, even the ones that are expired or not yet active. Users can select an intrastat code that is not active. Steps to reproduce: 1. Check the intrastat code list and find a code with a start date in the future or an expiry date in the past 2. Note the code description 3. Open a product form view and try to set/change the intrastat code 4. Search for the code description noted in step 2 5. Note that the code is proposed while it should not be proposed Solution: When an intrastat code is selected, if the code is not active, a warning message is shown to the user. opw-6217915 Forward-Port-Of: odoo/enterprise#118569 Forward-Port-Of: odoo/enterprise#117884