Thursday, April 23, 2026
30 changes · saas-19.3
Enhancements to existing features
Users can now split a manufacturing order directly from the serial number generation wizard. This makes it possible to assign one serial number per sub-order in a single step, instead of having to choose between splitting the order and generating serials separately.
Original PR description
Since 4bb4e08066449, producing multiple serial that have been generated is only doable on one mo. We can split mo. we can generate serial number but we cannot do both at the same time. This commit adds a new button into the generate serial wizard to split the main mo into the number of serial wanted and attribute one for each sub mo. 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#259156 Forward-Port-Of: odoo/odoo#255577
This update streamlines how notifications are sent within Odoo. Previously, notifications were delayed, but now they are sent immediately when a 'store' is created, improving efficiency. This change ensures notifications are delivered promptly and reliably, enhancing the user experience.
Original PR description
Since [1], store result is computed at the very end of the TX. As a result, no matter when `bus_send()` is called, the actual value of the notification will be the same: the one computed during bus's precommit hook, which creates the notifications. As a result, calling `bus_send()` manually is useless: we can just call as soon as a store is created, provided it has a bus target. part of task-5242369 [1]: https://github.com/odoo/odoo/pull/256079 enterprise: https://github.com/odoo/enterprise/pull/114187
This update improves the setup process for printers in our Point of Sale system. A new checklist document has been added to the POS form, guiding users through the necessary steps to enable LNA access for their printers via the browser. This will reduce user frustration and improve the overall POS experience.
Original PR description
The LNA configuration for printers is complicated for users. To help them this PR will add a check list document inside the point of sale form view which will explain all the steps the clients should do to enable LNA access for their printers in the browser. Task-[5933321](https://www.odoo.com/odoo/project/1737/tasks/5933321) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254551 Forward-Port-Of: odoo/odoo#249226
This update enhances the reporting of audits by allowing users to search for return types by name. Crucially, it now uses fiscal year periods instead of annual periods for generic, French, and Belgian audits, aligning with updated reporting requirements.
Original PR description
This change enables the user to search for the return types using the name of the return. In addition, it switches the generic audit, french audit and belgian audit to use the fiscal year periodicity instead of the annual periodicity. task: 5948404 Forward-Port-Of: odoo/enterprise#112280
This update streamlines offer contract management by automatically treating contract start dates within existing periods as amendments, creating new versions and archiving outdated data. A new warning system alerts users to potential replacements, and technical changes ensure data consistency and prevent cache issues, improving overall system stability.
Original PR description
**Contract Amendment & Versioning Logic** * When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new…
**Contract Amendment & Versioning Logic** * When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract. * For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract. * When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data. * Added a warning to notify users when a new offer will replace existing future versions. **Technical Refactoring** * Simplified the `employee_version_id` computation by delegating to the existing `_get_version` method on the employee model. This ensures the selected employee version correctly matches the contractual state effective at the new offer's * Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation. **Simulation & Chatter** * Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors. * To avoid this issue, we move to a new approach. We archive all versions after `employee.version_id` and set `employee.version_id.contract_date_end = False`. * Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution. task: 5408192 Forward-Port-Of: odoo/enterprise#108552 Forward-Port-Of: odoo/enterprise#103846
Resolved issues and error corrections
This update corrects a reporting setting that was left in an outdated format in several local tax reports. As a result, migrated reports for Spain, Italy, Luxembourg, and Uganda can open normally again without validation errors.
Original PR description
- This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the…
- This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula. see https://github.com/odoo/odoo/pull/193106 ```python3 Opération invalide Dans le rapport "Section I (LU)", à la ligne "472 - Autres Ventes / Recettes", avec le libellé "balance", Le format de l'expression de rapport croisé est invalide. Format attendu : cross_report(<report_id>|<xml_id>) Exemple : cross_report(my_module.my_report) ou cross_report(123) ``` opw-6103170 upg-4166654(lu) upg-4163103(it) upg-4175631(ug) upg-4177165(es) 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#258826
A bug that could cause an error while editing salary adjustments has been fixed. The system now handles missing start dates safely, preventing a traceback during form updates and making the payroll workflow more reliable.
Original PR description
This task guard against falsy date_start in _compute_estimated_end to avoid adding a relativedelta to False, fixing a traceback appearing during onchange. task-6139538 Forward-Port-Of: odoo/enterprise#114332
This fix prevents an error when users click certain cells in the Trial Balance report, specifically for Undistributed Profits/Losses. It restores the expected report details so users can open the related information without interruption.
Original PR description
This error occurs when clicking on any cell for `Undistributed Profits/Losses` in the `Trial Balance` report. Steps to reproduce: - Install `Accounting` module - Create `Journal Entry` with past-year…
This error occurs when clicking on any cell for `Undistributed Profits/Losses` in the `Trial Balance` report. Steps to reproduce: - Install `Accounting` module - Create `Journal Entry` with past-year `Accounting Date` (eg: 31-12-2025) and include one `Journal Items` for `Undistributed Profits/Losses` - Open `Trail Balance` report and click on any cell for `Undistributed Profits/Losses` Traceback: `KeyError: 'report_line_id'` Before this [commit], we were returning fields with `null/None` values. After the commit, fields containing `null/None` [value] are removed, and only fields with valid values are returned. As a result, when the `dispatch_report_action` function is called, the `report_line_id` is missing in `params`. [commit]: https://github.com/odoo/enterprise/pull/102808/changes/b92dc397bef029472a40223f51b611cdf5b631dc [value]: https://github.com/odoo/enterprise/blob/626b8157bcea2e3843cd9d5d0c0036e302b8e5ce/account_reports/utils/report_data_objects.py#L42-L43 sentry-7372351871 opw-6119913 Forward-Port-Of: odoo/enterprise#113421
This change stops combo products from being selected directly in the mobile sales order line form. It prevents orders from ending up with an empty, zero-priced line and missing the required child items, improving order accuracy and reducing follow-up corrections.
Original PR description
Combo products bypasses the configurator in mobile view, resulting in a 0-price line with no child lines. Exclude them via domain on the field. opw-5999935 Forward-Port-Of: odoo/odoo#260056 Forward-Port-Of: odoo/odoo#256790
Downloading a receipt for kiosk self-orders now works correctly. This fixes an error that could stop users from viewing or saving the receipt for these orders.
Original PR description
Currently an error occurs when the user tries to `Download Receipt` of self-orders as the following steps: - Install the pos_self_order module - Create a new POS shop with `Self Ordering` as `Kiosk` - Add Online `Payment Methods` on the above POS shop - Make an order from kiosk mode - Go to Point of Sale > Orders > Orders - Open the recent order which was created from the kiosk. - Click `Download Receipt` > Error Error: `QWebError:Error while rendering the template: AttributeError: 'bool' obje...` This issue occurs because, while rendering pos_order_receipt_header`, the `preset` value is `False`. Attempting to call `.get()` on a falsy value leads to an error. This commit fixes the issue by accessing `preset` only when it is available, preventing errors during rendering. sentry-7402711985 Forward-Port-Of: odoo/odoo#259336
A rendering issue could turn a normal percent sign in website and template text into a doubled percent sign, such as displaying "400%%" instead of "400%". This fix ensures text is shown exactly as intended when no placeholder values are present.
Original PR description
`_compile_format` unconditionally escaped `%` to `%%` to protect against Python's `%`-formatting, but only appended the `% (values,)` formatting operation when `#{...}` placeholders were present. With no placeholders, the escape was never undone and `%%` leaked into the rendered output.
This went unnoticed until the introduction of paramteric t-call: https://github.com/odoo/odoo/commit/eb6e88a25050
And since we use `.translate` and `.f` directly in existing views this became apparent
Example:
```xml
<t t-call="website.s_wd_testimonial"
_testimonial_quote.translate="...by 400%."/>
```
will be rendered as `...by 400%%.` on the page.
To prevent this, we can simply check for the absence of values and simply return the repr as is if there isn't any.
Forward-Port-Of: odoo/odoo#260434This update prevents an error that could occur when opening account report information. It ensures the report uses the correct update method for its internal data, so reports load reliably again.
Original PR description
Currently, an error occurs when retrieving account report information. ``` File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy…
Currently, an error occurs when retrieving account report information.
```
File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy
render_lines(root_account_groups, current_level, root_line_id, skip_no_group=False)
File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1373, in render_lines
child_line.update
^^^^^^^^^^^^^^^^^
AttributeError: 'AccountReportLineData' object has no attribute 'update'
```
After the [recent commit], all lines, columns, format_params, and annotations are converted into custom objects (AccountReportLineData). However, the code still attempts to use the update() method on these objects, which raises an error [1] since AccountReportLineData does not have an update method.
This commit ensures that the update_value() method is used to update AccountReportLineData objects, as intended, like here [2].
[recent commit]: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420
[1]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L1373-L1377
[2]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L6565
sentry-7403925422
Forward-Port-Of: odoo/enterprise#113668Configurable benefits will now appear even when there is no salary summary for the same structure type. This prevents an error when adding these benefits and keeps the employee benefit setup working smoothly.
Original PR description
Cause: After this task https://www.odoo.com/odoo/project/1251/tasks/5419466, the showing of benefits was restricted by mistake to only when there was a salary summary for the same structure type. This meant that adding a configurable benefit would result in a traceback, since the template was then used to get more info later on. Fix: Always show configurable benefits, even if there is no salary summary for the same structure type. task-6126621
This update improves how the editor handles text that is written inside inline code. It prevents formatting tools from appearing when they are not useful, and makes sure pasted content is turned into plain text so code stays clean and consistent.
Original PR description
### Purpose of this commit: - Prevent the powerbox and toolbar from opening when the selection is fully inside inline code. When the selection spans inline code and regular text, keep the toolbar visible but ensure formatting commands are applied only to the non-inline-code content. - Ensure that pasted external and editor HTML is converted to plain text when inserted inside inline code. task-5502939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258781 Forward-Port-Of: odoo/odoo#250911
Subscriptions that were closed manually by a salesperson will no longer reopen automatically when a payment is approved or an invoice is paid. This prevents unexpected reactivation and avoids follow-up issues for teams managing subscription cancellations.
Original PR description
Before this commit, when a subscription was closed manually by the salesperson, it could be reopened when a transaction was approved or an invoice paid. It could cause issue. In this case, we should not reopen automatically. task-5900481 Forward-Port-Of: odoo/enterprise#113026 Forward-Port-Of: odoo/enterprise#106487
This update fixes an issue where prices in multi-currency Point of Sale (PoS) transactions were incorrectly calculated. Now, prices are accurately converted from the product's native currency to the PoS configuration currency, ensuring accurate pricing across different currencies. This improves the reliability of PoS transactions in international settings.
Original PR description
Before this commit, in a multi-currency environment, the company currency was used to convert the prices, while it was a wrong assumption that the product prices were in the company currency. The products have a currency_id field, and the price should be converted from that currency to the PoS config currency. opw-6065969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259407 Forward-Port-Of: odoo/odoo#257324
This update resolves an issue where the Point of Sale app on iOS/Safari would unexpectedly crash due to a lost connection to its database. The fix prevents crashes when the app goes to the background or when the operating system temporarily closes the database connection. This ensures a more reliable and stable Point of Sale experience for our iOS users.
Original PR description
On iOS/Safari, the WebKit IDB server process can be killed by the OS (e.g. due to memory pressure when the app is backgrounded), resulting in an UnknownError: "Connection to Indexed Database server lost". Additionally, returning from background can leave the connection in an InvalidStateError "closing" state while this.db remains non-null. opw-5121896 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259697 Forward-Port-Of: odoo/odoo#253943
This update fixes an issue where the system wasn't correctly applying pension fund tax (TC08) during XML import when the tax rate was 0.00. The fix ensures accurate tax assignment, preventing missing tax associations and maintaining compliance with accounting rules. This improves the reliability of imported vendor bills.
Original PR description
### Issue before this commit: When importing vendor bills from XML files containing a pension fund (e.g., type TC08), the pension fund tax was not correctly applied to the invoice lines. As a result,…
### Issue before this commit: When importing vendor bills from XML files containing a pension fund (e.g., type TC08), the pension fund tax was not correctly applied to the invoice lines. As a result, the imported bills were missing the expected tax association. ### Steps to reproduce the issue: 1. Download Accounting and l10n_it 2. Set the pension fund type as TC08 (or another one is also fine) in the Advanced Tab of 4% F.Pens. tax 3. Try to upload an XML for vendor bills with a TC08 tax 4. The tax is not associated ### Cause of the issue: The issue was caused by the handling of the VAT rate (AliquotaIVA) when its value was 0.00. The code incorrectly treated this value as falsy, preventing the correct identification and assignment of the pension fund tax during the import process. ### Reason to introduce the fix: The fix ensures that a VAT rate of 0.00 is correctly interpreted as a valid value rather than being ignored. This allows the system to properly detect and apply the pension fund tax during XML import, ensuring accurate tax assignment and compliance with expected accounting behavior. opw-6093352 Forward-Port-Of: odoo/odoo#258341
This update resolves an issue where the 'Scan the QR code to pay' message on the kiosk online payment page was consistently displayed in English, regardless of the selected language. Now, the payment page will correctly translate the QR code instructions based on the user's chosen language setting, improving the user experience for international customers.
Original PR description
Currently if you use an online payment with the kiosk, the payment page with the QR code is not translated. Steps to reproduce: ------------------- * Create an online payment method with demo * Install any language, you don't need to switch * Open kiosk configurations * Set the online pm in the available payment methods * Set the language istalled as the default language * Make an order, go to payment page > "Scan the QR code to pay" is written in english no matter the language opw-6074194 Forward-Port-Of: odoo/odoo#259895
This update resolves performance issues and crashes when generating the VAT Books Excel report for large invoices. By optimizing memory usage and query execution, the report now runs efficiently even with extensive data, significantly reducing server load and improving export times.
Original PR description
Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414 ### Description of the issue/feature this PR addresses: Generating the "VAT Books" Excel report causes severe performance…
Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414 ### Description of the issue/feature this PR addresses: Generating the "VAT Books" Excel report causes severe performance bottlenecks and MemoryError crashes on databases with a massive volume of invoice lines. This PR introduces strict memory management and query optimizations to prevent server crashes and drastically speed up the XLSX export process. ### Current behavior before PR: When exporting the VAT Books report for a large dataset, the system attempts to hold the entire workbook structure in RAM. Additionally, the ORM unnecessarily prefetches fields when iterating over the account.move.line recordset and performs excess sub-queries to look up move_type for journal entries. This combination results in massive memory consumption, slow load times, and eventual server crashes. ### Desired behavior after PR is merged: The VAT Books report generates successfully and efficiently, even on massive databases, with a significantly reduced memory footprint. Specifically: - The ORM bypasses cache bloat by disabling field prefetching (prefetch_fields=False) during the recordset iteration. - The query execution is optimized by changing the search domain from move_type to move_id.move_type, leveraging the existing join table rather than triggering expensive sub-queries. ### Benchmark: The model is iterating through ~1.1M journal items when generating the full report. For Memory: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~7,800 journal items | 1.4GB| 202 MB | | ~32,000 journal items | MemoryError | 278 MB | | ~141,500 journal items | MemoryError | 760 MB | | ~1.1M journal items | MemoryError | 1.4 GB | For Speed: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~7,800 journal items | 2 min | 1.5s | | ~32,000 journal items | MemoryError | 4s | | ~141,500 journal items | MemoryError | 12s | | ~1.1M journal items | MemoryError | 56s | ### Reference opw-6037414 ----------------------------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#112230
This update resolves an issue where product category breadcrumbs displayed incorrectly on different Odoo websites. Specifically, when a product is linked to categories on multiple websites, the breadcrumb would sometimes lead to a 404 error on the incorrect website. The fix ensures the category selection is tied to the current website being viewed, improving the user experience and preventing broken links.
Original PR description
An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories. Steps to Reproduce: ==================== 1. Create two…
An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories. Steps to Reproduce: ==================== 1. Create two Ecommerce categories with the same name, one assigned to Website 1 and the other to Website 2. 2. Create a product and assign both categories to it. 3. On Website 1, navigate to the product page and click the category breadcrumb → works correctly 4. On Website 2, navigate to the same product page and click the category breadcrumb → **404 error** Cause: ====== In `_prepare_product_values`, when no category is passed in the URL, the fallback was: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/website_sale/controllers/main.py#L802 This blindly picks the **first** category from the product's public categories without checking which website it belongs to. If the first category (by ID order) belongs to Website 1, it gets used even when the user is browsing Website 2. The breadcrumb then generates a slug pointing to Website 1's category. When clicked on Website 2, `can_access_from_current_website()` fails for that category, resulting in a 404. Solution: ========= Filter `public_categ_ids` through `can_access_from_current_website()` before selecting the first one. opw-6070191 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260391 Forward-Port-Of: odoo/odoo#258336
This update simplifies the setup of the Mollie payment method in POS. Previously, a frustrating error prevented users from saving their configuration; now, they can complete the initial setup once. The system will still flag missing API keys, ensuring payments continue to function correctly.
Original PR description
Before this commit, when configuring the Mollie payment method in POS, a validation error would be raised if the associated payment provider did not have the API key set. While this makes sense given that it needs to be set in order for payments to work, it resulted in this unintuitive UX: 1. User fills in all the fields in the Mollie POS payment method form. 2. The user tries to save, but hits the validation error. 3. The user uses the internal link to go to the payment provider and fill in the API key. 4. The user returns to the POS payment method form, but because the form couldn't save they have to fill in everything *again*. This commit removes the validation error, allowing everything to be filled in just once. There will still be an error if trying to make a payment without an API key set. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260293
This update resolves an issue where the Odoo subscription process could miss or unnecessarily replay notifications due to outdated starting points. By establishing a clear, server-provided starting point for each subscription, the system now efficiently delivers notifications and avoids performance problems related to outdated data. This enhances the overall reliability and responsiveness of the live chat feature.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes the process of searching for channel invitations, which was previously slow due to an expanded dataset. The fix removes unnecessary steps like case-insensitive sorting and duplicate counting, resulting in a faster and more efficient search experience. This improves the responsiveness of the system when inviting users to channels.
Original PR description
Since [1], the check in `search_for_channel_invite` that restricted the search to internal users was removed. As a result, the dataset to process has exploded and the query is very slow. Moreover,…
Since [1], the check in `search_for_channel_invite` that restricted the search to internal users was removed. As a result, the dataset to process has exploded and the query is very slow. Moreover, the method is ordering on `LOWER(name)` which is not indexed, and another query is done to count the total results, which slows down the process even more. This PR fixes those issues by: - Removing the `LOWER` ordering. Ordering in a case sensitive fashion is not that big of a deal anyway. - Removing the count query, fetching one more partner in the search is enough to know if there are more results, executing the same query twice is overkill. - Reducing the number of partner returned: currently 30, but there isn't enough space to display them anyway. task-4526176 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#259869
This update fixes a visual inconsistency on the subscription portal. Previously, the portal showed all products from a subscription order, regardless of whether they were invoiced, leading to incorrect tax totals. Now, the portal only displays invoiced product lines, ensuring accurate tax calculations and a consistent user experience.
Original PR description
Previously, the portal view for subscriptions displayed all un-collapsed products from the sales order, ignoring whether they were actually invoiceable lines. This caused a visual mismatch where the displayed lines did not correspond to the calculated tax totals at the bottom of the view. This commit updates the visibility logic to ensure that product lines are only included if they are invoiceable. task-6128619 Forward-Port-Of: odoo/enterprise#114088
This update ensures vehicle license plate information is consistently included in XML export files for invoices, regardless of whether the 'account_accountant_fleet' module is installed. This improves data accuracy and consistency across all Odoo environments, particularly those using community databases. It addresses a previous issue where community databases were missing this critical vehicle data.
Original PR description
[FIX] account_fleet: vehicle sent in XML when an invoice line has a vehicle linked, the vehicle license plate will be in the export XML file only if the enterprise module `account_accountant_fleet` is installed. Any community db will then not have the ref included This commit moves the vehicle data in `account_fleet` to expose it to community dbs runbot-242562
This update resolves an issue where opening salary adjustments on mobile devices caused a crash. The fix involved adding a basic kanban view and removing unnecessary overrides related to delete actions, ensuring the feature functions correctly across all device types.
Original PR description
Steps to reproduce ================== - Install hr_payroll - Use a mobile viewport - Go to Employees - Open a record - Switch to the Salary Adjustments notebook tab => TypeError: undefined is not an…
Steps to reproduce ================== - Install hr_payroll - Use a mobile viewport - Go to Employees - Open a record - Switch to the Salary Adjustments notebook tab => TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)' Cause of the issue ================== The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used) See https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212 Solution ======== Since there is no delete action on the kanban view, there is no need for an override. While we are at it, there was no kanban view defined. Thus a default view was used https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846 It only contained the field description. Since that one is optional, records without a description were almost invisible.. Thus we also add a basic kanban view opw-6047295 Forward-Port-Of: odoo/enterprise#114464 Forward-Port-Of: odoo/enterprise#113317
This update fixes an issue where invoices generated from KSeF bills weren't correctly processing gross unit prices. The system now properly handles both net and gross unit price options provided by vendors, ensuring accurate invoice generation and compliance with Polish tax regulations. This prevents incorrect invoices and potential tax discrepancies.
Original PR description
**PROBLEM** When receiving bills from KSeF, we don't handle gross unit price and default to a price_unit of 0.0. Leading to an incorrect invoice. When generating the bill, the vendor can choose to report the net unit price (P_9A) or gross unit price (P_9B). We need to handle both cases. opw-6066027 Forward-Port-Of: odoo/odoo#260314
This update resolves a bug in the overtime calculation process for employees with specific attendance settings. Previously, an empty intervals object caused errors when updating overtime records. This fix ensures intervals are properly populated, preventing crashes and ensuring accurate overtime calculations are performed.
Original PR description
**Context** - "Absence Management" is enabled in the database settings - Employee has an overtime ruleset selected in their employee settings - That overtime ruleset has a rule with a non-zero `expected_hours` - That employee has 1 or more attendance records that start or end at midnight in their timezone. **Before this commit** When updating overtime records, either via the "Regenerate overtimes" button on the overtime rule, or by simply creating a new attendance record, we'll end up passing around an intervals object that contains no intervals. Then, when we later assume this object will have at least one element, we crash. **After this commit** Guarantee that intervals objects are populated before assuming they are. Further, we remove the opportunity to create an empty intervals object that was exposing this bug. opw-6035270 Forward-Port-Of: odoo/odoo#260772 Forward-Port-Of: odoo/odoo#257986
This update ensures delivery carrier availability accurately reflects employee leave, including public holidays. Previously, the system only considered calendar availability. Now, it incorporates leave types for more precise scheduling, improving delivery planning.
Original PR description
before we used attendance_intervals_batch to consider available days but it only considered available days in the calendar, to also consider types of leaves like public holidays we need to use the _work_intervals_batch instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr