Daily updates from Odoo
Tuesday, March 17, 2026
288 changes
50 changes
Resolved issues and error corrections
A recent issue causing tour instability within the project management module has been resolved. Previously, the system was saving tour content without verifying it was within the editor, leading to frequent failures. This fix eliminates this instability, ensuring tours run reliably.
Original PR description
Prior to this fix, `changeDescriptionContentAndSave` in `project_task_history_tour` did not check that the inserted content was actually inside the editor prior to saving. Measured failure rate before the fix: 11/30. After the fix: 0/30. runbot-241987
This update corrects an issue where QR codes weren't consistently generated on PDF invoices sent to customers in Peru. The fix resolves a technical problem related to how attachments were linked during the PDF generation process, ensuring accurate QR code display. This improves the customer experience by guaranteeing correct invoice formatting.
Original PR description
In [^1] we refactored Peru to use the send and print api instead of account_edi. One issue that was missed is in the case of sending the pdf to the customer in the same call as sending to SUNAT. Since the field that is storing the attachment (`l10n_pe_edi_attachment_id`) is linked to `l10n_pe_edi_attachment_file` via the compute, creating the attachment with a link to the res_field doesn't update within the transaction so `l10n_pe_edi_attachment_id` is still false at the time of PDF generation. There are two fixes, we can either invalidate the recordset at time of computation to make sure that it is truthy in the transaction, or use the `l10n_pe_edi_attachment_file` directly as it means we don't need to access the data field on `ir.attachment`. The use of the `l10n_pe_edi_attachment_file` field seemed cleaner. task-none [^1]: #97593
This update resolves a technical issue that was causing a warning message related to how boolean fields were displayed in the HR Overtime ruleset. The change standardizes the rendering of boolean fields, improving the overall stability and appearance of the system. This ensures a consistent and reliable user experience.
Original PR description
Remove legacy widget="checkbox" usages that triggered the "Missing widget: checkbox" console warning; boolean fields now use the default boolean widget rendering. task-5945764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue that was causing a warning message related to how boolean fields were displayed. Additionally, outdated tour actions related to work entries have been removed, streamlining the user experience. This ensures correct display and functionality of overtime rules.
Original PR description
Remove legacy widget="checkbox" usages that triggered the "Missing widget: checkbox" console warning; boolean fields now use the default boolean widget rendering. Also, removed tour actions related to the "Work Entries" removed in last version. task-5945764
This update resolves a technical issue within the Odoo POS refund testing process. The previous test was incorrectly simulating order processing, leading to errors and incomplete refund transactions. This fix ensures refunds are processed correctly by waiting for the backend to fully complete the order, improving the reliability of refund tests.
Original PR description
The test l10n_pe_edi_pos.RefundWithReasonTour was badly written at some steps. It was paying an order but not waiting it to be fully processed by the backend to try to refund it leading to some information missing and thus some future step failing. This commit is adding the necessary waiting steps. runbot-error: 237981
This update resolves an issue that was causing errors during upgrades related to fetching archived warehouse picking types. The fix prevents the system from attempting to use inactive warehouse locations, which was leading to database errors. This ensures smoother upgrades and reliable stock operation creation.
Original PR description
revert the commit as when we fetch archived warehouse's pos type it will raise error for other source or destination loction for newly created stock operation type like even functinally also there is…
revert the commit
as when we fetch archived warehouse's pos type
it will raise error for other source or destination loction for newly created stock operation type like
even functinally also there is no need to fetch
archived warehouse's operation type.
```
quality Control
cross Dock,
Storage type
```
we got this error during upgrade :
```
File "/home/odoo/src/odoo/saas-17.4/odoo/sql_db.py", line 347, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "default_location_src_id" of relation "stock_picking_type" violates not-null constraint
DETAIL: Failing row contains (33, 0, 28, 56, null, null, null, 4, null, null, 1, 1, 1, QC, internal, at_confirm, FBAQC, ask, {"en_US": "Quality Control"}, null, f, f, t, null, f, null, 2024-10-16 05:14:53.18448, 2024-10-16 05:14:53.18448, optional, optional, no, optional, null, null, t, null, null, 2x7xprice, 4x12_lots, pdf, null, null, null, null, null, null, null, null, null, t, null).
```
due to this two fix:
https://github.com/odoo/odoo/pull/151719/commits
https://github.com/odoo/odoo/pull/175838/files
so we need to avoid to fetch archived warehouse's picking type.
ref:
odoo/upgrade#6631
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#191652
Forward-Port-Of: odoo/odoo#185244This update resolves an issue where rental income was incorrectly included in the Total Income batch calculation for Hong Kong payroll. The fix removes any rental amounts from this calculation, ensuring accurate reporting for tax purposes. This improves the reliability of financial data.
Original PR description
. Removing any rental amounts in calculating Total Income batch task-6006636 Forward-Port-Of: odoo/enterprise#109919
This update resolves an issue where serial numbers weren't being generated correctly using date-range sequences. The fix ensures that each new receipt creates unique serial numbers based on the specified date range, improving inventory tracking accuracy. This change was implemented by adjusting how the system updates the sequence, addressing a previous limitation in the generation process.
Original PR description
### Steps to reproduce: - In the settings enable: Lots & Serial Numbers and Multi-Step routes - Settings > Technical > Sequences & Identifiers > Sequences - On the stock.lot.serial sequence enable:…
### Steps to reproduce: - In the settings enable: Lots & Serial Numbers and Multi-Step routes - Settings > Technical > Sequences & Identifiers > Sequences - On the stock.lot.serial sequence enable: `Use subsequences per date_range`, add a range date containing today - Create a product tracked by Serial numbers - Create and confirm a receipt for 3 units of your product - Detailed of the move > Generate Serials/Lots > New > Generate #### > 3 serial numbers were created but the date specific sequence has only been updated once. This can be checked by creating a new receipt and processing the same exact flow. ### Cause of the issue: Generating the serial numbers will call the `action_generate_lot_line_vals`. However, this method is not tailored to deal with the `use_date_range` and increments the main sequence rather than the actual subsequence: https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/addons/stock/models/stock_move.py#L1103-L1106 ### Fix: We rely on the apparently unused `_get_current_sequence` method to recover the appropriate sequence by date range to update: https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/odoo/addons/base/models/ir_sequence.py#L114-L128 This method has been introduced in an accounting naming IMP: 915aa9e4db3169a4767617b5310721f0d9c16812 and is unused since the accounting is no more relying on name sequences: dfd01b8c5c7e1177f37bf199790a0732a61eed78 In addition, we fine tune the current version of the code updating the serial sequence on lot generation since it is currently updating the sequence only if the first generated lot has been set via the`New` button and hence has incremented the sequence via a `next_by_id` call: https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/lots_dialog.xml#L33 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/generate_serial.js#L48-L56 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L261-L275 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L335-L337 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L53-L55 While if the value of first lot is given manually to the wizzard is given manually to the wizzard, the sequence does not get incremented by the nextval. opw-5931056 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253618
This update fixes a bug that prevented users from adding spaces to 'Add to Cart' button labels within the website editor. The change wraps editable button content in a separate span element, correctly handling space key presses and improving the user experience. This ensures accurate label formatting for product pages.
Original PR description
Problem: After https://github.com/odoo/odoo/commit/e809b492c1b138c1af7bb1d4aa61b39d87686df9 typing spaces inside an "Add to cart" button label in the website editor triggers the button click instead…
Problem: After https://github.com/odoo/odoo/commit/e809b492c1b138c1af7bb1d4aa61b39d87686df9 typing spaces inside an "Add to cart" button label in the website editor triggers the button click instead of inserting a space character. Cause: Browsers natively intercept the space key on `button[contenteditable="true"]` elements and fire a click event instead of inserting the character, making it impossible to type spaces in the button label. Solution: Introduce an `EditableButtonPlugin` that moves the `contenteditable` attribute from the button up to a wrapping `<span>`. This preserves full text editing capability (including spaces) without triggering the button's click handler. Steps to reproduce: * Go to a product page on the website. * Open the editor. * Try to add a space in the "Add to cart" button label. * Observe that the button is triggered instead of inserting a space. opw-5994828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252675
This update resolves an issue where manufacturing orders created through the barcode app incorrectly used product UoMs instead of the specified BoM UoMs. The fix ensures that stock moves accurately reflect the BoM's requirements, preventing errors and improving the reliability of the manufacturing process. This improves data accuracy for inventory management.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#110540 Forward-Port-Of: odoo/enterprise#90408
This update fixes an issue where refund calculations for orders with multiple line items in the Mexican VAT (l10n_mx_edi_pos) module were inaccurate due to incorrect summing of line amounts. The change ensures accurate comparisons against the original order total, preventing refund errors and improving the reliability of the refund process.
Original PR description
Before this commit, the some of individual line amounts were being summed to compare against the original order total when processing a refund. This could lead to incorrect comparisons due to rounding issues, resulting in errors when attempting to refund orders with multiple lines. <img width="626" height="288" alt="image" src="https://github.com/user-attachments/assets/e1bdc126-64d9-4b9a-bd16-2b97ac75e40c" /> opw-5433201 Forward-Port-Of: odoo/enterprise#109124 Forward-Port-Of: odoo/enterprise#105301
This update resolves an issue where 'View more' and 'View less' labels within the eCommerce product filters were not being translated correctly when browsing in languages other than English. The fix ensures that all filter labels are properly localized, providing a consistent user experience across all supported languages. This improves the usability of the eCommerce platform for international customers.
Original PR description
When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated Steps to…
When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated Steps to reproduce: 1. Install eCommerce 2. Create a product with one attribute that has 9 to 20 values and publish the product to the eCommerce (the attribute should have radio display type and should be visible in the eCommerce) 3. Add a language (e.g. French) and translate the eCommerce's website 4. Open the website and set the language to French 5. In the left column, open the filter for the attribute previously created 6. Click on "Voir plus" 7. "View less" is not translated, if you click on it, "View more" is not translated anymore Issue: The translation for "View more" is generated because it is present in the template `filter_radio_and_multi_attributes` but when we update the text in website_sale.js, the terms are not translated anymore Solution: Use `_t` to translate the "View more" and "View less" terms opw-5985712 Forward-Port-Of: odoo/odoo#253684 Forward-Port-Of: odoo/odoo#252828
This update resolves recent performance issues experienced when using the Point of Sale (POS) and self-ordering systems on iOS devices. The team optimized the user interface by adding styling to improve responsiveness and reduce delays when interacting with elements, resulting in a smoother user experience.
Original PR description
There was some issues when touching elements in the POS and self. We added the parameter role="button" to the elements that were not already and a pe-none to the images. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253686 Forward-Port-Of: odoo/odoo#253583
This update ensures that quality checks are only performed on tracked products with assigned lot or serial numbers. Previously, users could initiate quality checks without this information, now a user error is displayed, preventing incorrect data entry. Additionally, the quality check display now intelligently filters based on whether move lines have been picked, improving the user experience.
Original PR description
This commit fixes the behavior when the user tries to do quality checks for tracked products without setting their lot/sn on the picking. Before this commit: Nothing happens if the user tries to do quality checks if lots are not set on the tracked products. After this commit: A User Error is raised telling the user to assign lots/sn to the tracked products. Additional improvement: Before this commit, when having quality checks and user click on `Quality Checks` button, all quality checks appear regardless of whether all moves are picked or only some of them are picked. After this commit, clicking on `Quality Checks` button will only show quality checks related to picked move lines if at least one move line is picked, otherwise it will show all quality checks. Task-5730239 Forward-Port-Of: odoo/enterprise#104945
This update incorporates translations from Odoo 19.0 into the Enterprise version, specifically for Uzbek (uz). The process focused on directly matching translations between modules, ensuring consistency. A key consideration was verifying the accuracy of these translations within their respective contexts to avoid errors.
Original PR description
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness) Forward-Port-Of: odoo/enterprise#110497
A technical issue prevented the installation of the 'planning_holidays' module due to a mismatch in XML view definitions. This update reverts a recent change to ensure compatibility and allows the module to install correctly, preventing installation errors.
Original PR description
**Steps to Reproduce:** - Revert the commit 2ff35d598346798bd00fd40687e0e214c0190c1f. - Install the Planning module. - Restore the original commit - Install 'planning_holidays' module. **Error:** ```…
**Steps to Reproduce:**
- Revert the commit 2ff35d598346798bd00fd40687e0e214c0190c1f.
- Install the Planning module.
- Restore the original commit
- Install 'planning_holidays' module.
**Error:**
```
ParseError: while parsing /home/odoo/src/enterprise/saas-19.2/planning_holidays/views/planning_slot_views.xml:26, somewhere inside <record id="planning_view_kanban_inherit_planning_holidays" model="ir.ui.view">
<field name="name">planning.slot.kanban</field>
<field name="model">planning.slot</field>
<field name="inherit_id" ref="planning.planning_view_kanban_inherit"/>
<field name="arch" type="xml">
<xpath expr="//span[@t-if='record.overlap_slot_count.raw_value']" position="after">
<field name="leave_warning" class="text-danger mb-2"/>
</xpath>
</field>
</record>
```
**Cause:**
The `planning_holidays` module targets a `<span>` element in its XPath, while the `overlap_slot_count` element is located in a `<p>` in the planning module. Since view changes in stable do not update already-installed databases, the old XPath cannot be found, and a ParseError is raised during module installation.
**Fix:**
Revert the changes in stable to restore the original view.
sentry-7338367664This update resolves an issue where deleting timesheets from the system tray was unreliable. The fix ensures timesheets are properly and asynchronously removed, and that deletion confirmations are correctly handled. This improves the overall stability and usability of the timesheet management feature.
Original PR description
The onDelete method was not properly made async in the systray, plus the `delete` method promise from `record.js` actually doesn't return anything when the deletion is successful
This update fixes errors in the Dutch SBR reports by ensuring VAT numbers are correctly formatted and standardizing date formats within the exported XML files. A cleanup process has been added to improve the readability of the generated reports, making them easier for users to understand and work with.
Original PR description
Descriptions of the issues this commit addresses: The xbrli:identifier tags in the exported sbr and sbr icp files are wrong. They should always contain the company's vat without country code . The DateTimeCreation tag currently shows a date in a wrong format. It it YYYYMMDDhhmm but should be YYYY-MM-DDThh:mm:ss. Also the outputted xml is weirdly indented with many whitespaces and it makes it hard to read for no reason. --- Desired behavior after the commit is merged: This commit changes the values in the exported file to address those issues and adds the use of a cleanup helper to make the file human readable. --- task-5998939 Forward-Port-Of: odoo/enterprise#109359
This update simplifies the scatter plot chart by removing the unnecessary zoom feature. This change aligns with upcoming plans to allow users to manually adjust axis minimum and maximum values, ensuring a more consistent and controllable charting experience. This improves the chart's usability and prepares it for future enhancements.
Original PR description
## Task Description This PR aims to remove the zoomable feature for the scatter plot, as it's kind of non-sense to be able to zoom on an axis and not on the other for this type of chart. Moreover, we will soon be able to manually set the min/max of each axis manually (in master). ## Related Task/PR - Task: 5388389 - [https://github.com/odoo/enterprise/pull/106189](https://github.com/odoo/enterprise/pull/106189) 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#246954
This update removes a confusing zoom feature from the scatter plot chart in the Enterprise edition. This change simplifies the chart's functionality and aligns with upcoming plans to allow users to manually adjust axis ranges. This improves the user experience and prepares for future customization options.
Original PR description
## Task Description This PR aims to remove the zoomable feature for the scatter plot, as it's kind of non-sense to be able to zoom on an axis and not on the other for this type of chart. Moreover, we will soon be able to manually set the min/max of each axis manually (in master). ## Related Task - Task: 5388389 Forward-Port-Of: odoo/enterprise#106189
This update ensures that stock availability emails sent during testing and nightly runs use the correct partner email address associated with the website. Previously, a test error occurred because the website's partner lacked an email. The fix now provides a default email and prevents sending emails with the current user's email, resulting in more reliable email notifications.
Original PR description
This commit (https://github.com/odoo/odoo/pull/249299/changes) backported some changes concerning stock availability mails. The mail is now sent from the partner associated to the website. However, in nightly runbots, the partner associated to the website does not have any email, so an error is thrown This fix does two things : - Make sure the website's partner has an email when running the tests - Prevent the mails being sent with the current user's email as a last ressort, and let an error be thrown instead runbot-102934954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253172 Forward-Port-Of: odoo/odoo#251951
This update fixes an issue where the lower portion of the barcode editing page was hidden by buttons. The change ensures all fields are always visible, regardless of button display, improving the user experience when adding or modifying barcode items. This prevents frustration and ensures accurate data entry.
Original PR description
# How to reproduce - Set the barcode of a product - Go to Barcode > Operations > (Select any operation) > New - Click on the cog in the top right and type in the barcode you set for the product - Apply and then edit the item you added - Add options to the page (like Expiration Date) or increase the browser's zoom until the list of fields take the whole page # The problem The fields at the bottom of the page are hidden behind the buttons at the bottom # Why The controls at the bottom are positioned absolutely and with a high z-index, so they hide anything behind them. The form css class fixes this issue by adding a margin-bottom roughly the size of the controls. But this fix does not take into account the fact that the controls can grow in size when the DELETE button is displayed opw-5907564 Forward-Port-Of: odoo/enterprise#107496
This update fixes a visual inconsistency in the calendar view of timesheets. Previously, negative time entries were displayed as '-1h 15m', which was confusing. Now, the calendar view accurately reflects negative durations like '-45 minutes', aligning with how they're shown in the list view for clarity.
Original PR description
The calendar view used Python's `divmod` for time calculations, which renders -45 minutes as -1h 15m. This representation is misleading for timesheet entries, while the list view already displays the values correctly. Adjust the calendar view logic to ensure consistent and accurate handling of negative durations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247925
This update resolves a failing test within the Odoo Enterprise POS platform. The issue stemmed from a recent change requiring a kitchen printer, which wasn't configured in the test environment. This fix ensures the test now runs correctly, maintaining the stability of the order processing flow.
Original PR description
This commit fixes the failing `test_platform_order_flow` test, specifically within the `test_platform_order_reject_flow` tour at the `.ticket-screen` step. Explanation: The root cause of this issue is that the system is now expecting a kitchen printer to be present to process the order flow. However, the unit test environment does not have a kitchen printer configured, which causes the flow to halt or behave unexpectedly when the system tries to interact with it. Reference: Breaking PR: odoo/odoo#226447 build_error-241246 Forward-Port-Of: odoo/enterprise#110249
This update resolves a technical error that prevented users from placing lunch orders with vendors when a 'Until Date' was set. The fix ensures the system correctly handles date comparisons, allowing users to consistently add items to their lunch orders. This improves the reliability of the Lunch module.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Lunch module 2. Lunch > configurations > Vendors 3. Open any vendor and set Until date to any near future date 4. Go to My Lunch > New Order 5. Click on Any product with above vendor > Add to Cart 6. Click on Order Now Observation: ------------------------------ Traceback Occurs: ``` return not (self.recurrency_end_date and date.date() >= self.recurrency_end_date) and self[fieldname] ^^^^^^^^^ AttributeError: 'datetime.date' object has no attribute 'date' ``` Issue: ------------------------------ `_available_on_date` calls `date.date()` unconditionally, which fails when passed a `datetime.date` object (from `lunch.order`) since date objects lack the `date()` method. Solution: ------------------------------ Check instance type before calling `date()` to handle both `datetime.datetime` and `datetime.date` objects correctly. opw-5948688 Forward-Port-Of: odoo/odoo#249449
This update fixes a bug where employee skills weren't automatically added to appraisals created by the system's automated scheduling process. The fix ensures that skills are correctly copied to all appraisals, regardless of how they're initially created, improving appraisal accuracy and data consistency. This impacts users relying on the automated appraisal system.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date…
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date to today 4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually 5. Open the newly created appraisal for the employee Observation: ------------------------------------- In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage Issue: ------------------------------------- When the cron `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via `create()`. The skill-copying logic only lived in the `write()` override, which triggers on state transitions from 'new' to 'pending'. Since `create()` bypasses `write()`, Employee skills were never copied to cron-created appraisals https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15 Solution: ------------------------------------- Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied. opw-5491433 Forward-Port-Of: odoo/enterprise#110601 Forward-Port-Of: odoo/enterprise#107760
This update fixes a bug where journal entries could be posted even when referencing inactive analytic accounts. The fix adds a validation step during posting to ensure all referenced accounts are active, preventing incorrect financial postings. This improves data accuracy and reliability within the accounting system.
Original PR description
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic…
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic account in the analytic distribution. - Post the entry and export it(Make sure `journal items/account` and `journal items/analytic distribution` are also included). - `Archive` the analytic account. - Import the exported entry `OR` Duplicate the previous created entry. - Try to post the imported entry. **Issue:** - The entry is posted even if the analytic account used in the analytic distribution is inactive. **Root cause:** - The `analytic_distribution` field is stored as JSON. - At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error. **Solution:** - Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active. [1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202 opw-5350980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253752 Forward-Port-Of: odoo/odoo#239988
This update removes birthday events from automatic synchronization with Google Calendar. These events presented a confusing and unnecessary feature due to their unique handling and separate calendar display. This simplifies the calendar sync process and improves user experience.
Original PR description
Birthday events are a special kind of yearly-recurrent event that notably cannot be simply deleted like other events. They also appear as a separate calendar in the google UI to an extent, similar to tasks. As they require special handling, have little functional value and can be confusing due to that "fake calendar" behavior. We will now always filter them out of broad calendar sync. task-5966907 Forward-Port-Of: odoo/odoo#250916
This update fixes an issue where the MPS wasn't accurately reflecting demand for dependent components. Previously, the system defaulted to the oldest BoM, regardless of the user's selection. Now, the MPS correctly uses the chosen BoM to calculate and update component demand, ensuring accurate forecasting and production planning.
Original PR description
## Issue: When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which…
## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.
---
## How to reproduce:
https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8
- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10
- => Indirect Demand Qty for CMP is not shown (because it's 0)
---
## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ...
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ======================================================================
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
```
---
OPW-5979738
Forward-Port-Of: odoo/enterprise#110526
Forward-Port-Of: odoo/enterprise#109693This update fixes a performance issue in our testing process. Previously, asset bundles were repeatedly regenerated during test runs, slowing things down. Now, bundles are pregenerated once and reused, significantly improving test execution speed and stability.
Original PR description
The commit [^1] introducing binary asset bundle support overlooked the pregeneration of said bundles for the tests runs. This leads to hot-regeneration of those bundles during tests runs on the runbot (multiple hundreds of times) instead of only once and reusing them. This commit adds support for those binary bundles during pregeneration. [^1]: odoo/odoo@a5c02da5c24bfc85b3bbb7d1410d489d3c7185b8 Forward-Port-Of: odoo/odoo#248014
This update fixes a performance issue in the Web Studio module by ensuring binary asset bundles are pregenerated during testing. Previously, tests repeatedly regenerated these bundles, slowing down the testing process. Now, bundles are created once and reused, significantly improving test run times.
Original PR description
The commit odoo/odoo@a5c02da5c24bfc85b3bbb7d1410d489d3c7185b8 introducing binary asset bundle support overlooked the pregeneration of said bundles for the tests runs. This leads to hot-regeneration of those bundles during tests runs on the runbot (multiple hundreds of times) instead of only once and reusing them. This commit adds support for those binary bundles during pregeneration. Forward-Port-Of: odoo/enterprise#110555
This update fixes an issue where the auto-focus feature for the VoIP country selector dropdown was broken in saas-19.2. The fix ensures the country selector automatically receives focus when opened, improving user experience and streamlining VoIP setup.
Original PR description
Commit [1] introduced the country selector on the VoIP keypad, for saas-19.1. However, for saas-19.2, the auto-focus of the country search input once the country selector dropdown is opened was…
Commit [1] introduced the country selector on the VoIP keypad, for saas-19.1. However, for saas-19.2, the auto-focus of the country search input once the country selector dropdown is opened was broken. This is because of [2] which trapped the focus inside the softphone to improve various keyboard behaviors... but the country selector is considered to be outside of the country selector as it is a dropdown, which broke the auto-focus. We now trap the focus inside the country selector once it opens, the same way [2] traps the focus inside the softphone once it opens. Doing that, using `useAutofocus` becomes actually useless as the input is the first focusable element of the dropdown and will thus automatically be focused when the menu becomes the active element. Also, the auto-focus introduced by [1] was not working on mobile. This commit changes that but does not consider that to be a bug so this still target 19.2+. Note: a tour already existed and wanted to check that feature works but it was not properly written. This commit adds a unit test about this only too, and for the mobile usecase. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 [2]: https://github.com/odoo/enterprise/commit/df1772e877a508150fd3f549526dec9d867354be task-5999452
This update corrects a previous error in the Indian payroll configuration, ensuring the default basic salary percentage is set to 50% instead of 60%. Now, benefit adjustments only affect gross salary and employer costs, without altering employee wages or the underlying payroll structure. This provides a more accurate and stable payroll calculation for Indian businesses.
Original PR description
- Fix the default Indian basic salary percentage to 50% instead of 60%. - Ensure benefit amounts are treated as additional employer payments and do not rebalance the employee’s wage or basic salary in the salary configurator. After this change, benefit updates only impact gross salary and employer cost, while the wage remain unchanged. task-[5501683](https://www.odoo.com/odoo/project/1251/tasks/5501683)
This update resolves an issue where a tour feature wasn't working correctly for all shift planning scenarios. The fix removed an unnecessary check, allowing the 'Edit' button to function as intended and redirect users to the correct form view. This ensures all tour functionalities are consistently available.
Original PR description
The tour was working with `planning_field_service_sale_timesheet` but not `planning_field_service` only. The reason is that 'newButtons' did not contains any element, so the 'Edit' button logic was not altered to redirect to the form view on click as wanted. We do not need to do the check on 'newButtons' to allow that. runbot-error: https://runbot.odoo.com/odoo/runbot.build.error/241950
This update corrects a warning related to outdated cryptography libraries used in our Redsys payment processing system. The change ensures compatibility with newer versions of the cryptography library, preventing potential issues and maintaining system stability. This resolves a technical detail that could have impacted payment processing.
Original PR description
In cryptography 43.0.0 (present in Debian Trixie), ARC4 and TripleDES were migrated to decrepit [^1], leaving a deprecation warning in the old path. This commit handles both previous pre/post 43.0.0 import path. runbot-233267 [^1]: pyca/cryptography@722a6393e61b3acb569f404218f213fe08478a96 Forward-Port-Of: odoo/odoo#253957
This update corrects a naming error in the ZUGFeRD eInvoice XML file, resolving validation issues with several key e-invoice validators. Previously, the incorrect filename prevented proper processing. Now, the ZUGFeRD file passes validation across multiple platforms, ensuring accurate e-invoice handling.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253704 Forward-Port-Of: odoo/odoo#252681
This update fixes an issue where selecting an office on the Jobs page would remove the previously selected country filter. The fix ensures that country filters remain active when selecting offices, improving the user experience for filtering job postings by location. This change was made to enhance usability and accuracy in job searches.
Original PR description
Steps to reproduce: =================== 1. Navigate to the Jobs page. 2. Filter a specific country 3. Select all offices -> The country filter will be removed Cause: ====== the "All Offices" link inside job_filter_by_offices, the href uses 'all_countries=1' if is_remote else current_country_path but current_country_path is not defined anywhere Solution: ========= Switch to current_country_param Note: ===== The fix will be adapted in later versions opw-5947819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252909 Forward-Port-Of: odoo/odoo#252477
This update resolves an issue where clicking on 'reply' links within Odoo's email inboxes didn't function correctly. Now, clicking on a reply link will seamlessly jump to the original email thread, improving the user experience and ensuring efficient email management. This change enhances the usability of Odoo's communication features.
Original PR description
Before this change, clicking on a `message in reply` in mailboxes had no effect. The expected behavior is for it to jump to the message in its origin thread. To fix it, this commit ensures that `useMessageHighlight` hook receives the correct thread which in this case is the origin thread of the message in reply. task-5343804 Forward-Port-Of: odoo/odoo#253990 Forward-Port-Of: odoo/odoo#253334
This update automatically groups vendor bills during UBL/CII import based on the vendor's previous bill history. By checking the last posted bill, the system ensures consistent tax grouping for improved accuracy and efficiency in invoice processing. This simplifies reconciliation and reduces manual effort.
Original PR description
[FIX] account_edi_ubl_cii: automate bill line grouping
This commit automates vendor bill line grouping during import based on the vendor's most recent posted bill.
- Logic: Added `_has_lines_grouped()` to `account.move` to detect if lines follow the grouping pattern.
- Heuristic: During UBL/CII import, the system now checks the last posted bill from the same vendor; if it was grouped, the new bill is automatically grouped by tax.
task-5979667
Forward-Port-Of: odoo/odoo#253322
Forward-Port-Of: odoo/odoo#251419This update fixes an issue where refund payments in Point of Sale were incorrectly created as inbound payments. When a refund is processed using the Card payment method with Identify Customer enabled, the system now correctly identifies these payments as outbound, ensuring accurate financial reporting. This change improves the reliability of our accounting processes.
Original PR description
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS…
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS session - Go to Invoicing → Customers → Payments Observation: - Two payment records are created - Both payments have payment_type = inbound - The refund payment should be outbound Cause: - When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records - The method does not adjust payment_type for refund transactions Fix: - Add helpers to swap destination and outstanding accounts - Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority - Ensure refund payments are created as `outbound` few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228 https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8 opw-5437456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254079 Forward-Port-Of: odoo/odoo#247760
This update corrects a previous issue where event ticket prices were incorrectly locked to the event's price in the Point of Sale system. Now, event tickets will recalculate their price based on either the event's price or a relevant pricelist, ensuring accurate pricing at the POS. This improves the overall POS experience and pricing accuracy for event tickets.
Original PR description
Event tickets in POS would have their price locked to the price defined in the event itself. They would be filtered out of any price recalculation inside the POS to keep the POS from recalculating the price based on the `product_template` and to keep the price defined in the event itself. This PR will add event tickets back into price recalculation. It will set the price to the price defined inside the event if no pricelist is applicable, or use the pricelist to calculate the price if there is one applicable. Task-[5092613](https://www.odoo.com/odoo/project/1737/tasks/5092613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248454
This update fixes a potential error in how Odoo handles session records. Previously, if a session lacked device information due to a log being removed, it could cause a system error. Now, the system automatically populates session records with device details like IP address and user agent, ensuring consistent data and preventing these errors.
Original PR description
This commit ensures that there is always information linked to a `res.session` record. This causes an error, for example, if `user_agent` is `False`: ```py ... =…
This commit ensures that there is always information linked to a `res.session` record. This causes an error, for example, if `user_agent` is `False`: ```py ... = self.__user_agent_parser(device.user_agent) ``` We ensure that if we have a `is_current` `res.session` record which does not have a `is_current` `res.device`, we have information (`ip_address`, `user_agent`, `country`, `city`). Scenario: - device A detected at time T0: info A in session + new log A - device B detected at time T1: info B in session + new log B - log B is unlink (or marked as revoked) - device B detected at time T2: nothing ==> `web_read` on `res_users` ==> error T2 < T1 + `DEVICE_ACTIVITY_UPDATE_FREQUENCY` - device B detected at time T3: info B updated in session + new log B T3 > T1 + `DEVICE_ACTIVITY_UPDATE_FREQUENCY` Explanation: At this moment, T2, because log A exists, a `res.session` record exists. When we compute information for the `res.session` record, as this record is the current session, we must get the current device. To retrieve the current device, we use the `res.device` model. Unfortunately, no current device is present (because log B has been deleted) and `DEVICE_ACTIVITY_UPDATE_FREQUENCY` has not been exceeded. In this case, we have a current session without current device. Note: However, we are certain that there is at least one device for this session record because session records are built with device records. Task-6023651 Forward-Port-Of: odoo/odoo#253058
This update optimizes the Point of Sale system to use less memory, particularly when handling large product catalogs. The changes result in a significant reduction in memory consumption across browsers (Chrome, Safari, Firefox) when loading more than 20,000 products, leading to a smoother user experience.
Original PR description
This commit reduces memory consumption in the POS, especially when loading a large number of products. Reactivity usage has been optimized, particularly for product data. Additional optimizations were implemented to handle large product sets more efficiently. Metrics 5,000 products • Chrome: 440 MB → 75 MB • Safari / Firefox: 1 GB → 250 MB 20,000 products • Chrome: 1.5 GB → 135 MB • Safari / Firefox: 4 GB → 300 MB Enterprise PR: https://github.com/odoo/enterprise/pull/107978 Forward-Port-Of: odoo/odoo#250480 Forward-Port-Of: odoo/odoo#249542
This update optimizes the Point of Sale (POS) system to use less memory, particularly when handling large product catalogs. The changes result in significantly reduced memory consumption across Chrome, Safari, and Firefox, leading to a smoother and more responsive user experience for sales teams.
Original PR description
This commit reduces memory consumption in the POS, especially when loading a large number of products. Reactivity usage has been optimized, particularly for product data. Additional optimizations were implemented to handle large product sets more efficiently. Metrics 5,000 products • Chrome: 440 MB → 75 MB • Safari / Firefox: 1 GB → 250 MB 20,000 products • Chrome: 1.5 GB → 135 MB • Safari / Firefox: 4 GB → 300 MB Community PR: https://github.com/odoo/odoo/pull/249542 Forward-Port-Of: odoo/enterprise#108586 Forward-Port-Of: odoo/enterprise#107978
This update fixes a bug in product imports that was causing redundant records to be created. By using a 'set' instead of a 'list' to store attribute values, the system now ensures unique values are used, preventing errors and maintaining data consistency. This improves import reliability and avoids wasted resources.
Original PR description
Product imports were creating redundant `product.attribute.value` records because batch values were stored in a list without uniqueness checks. This fix ensures that: - Unique values are identified before creation. - Product variants remain usable and consistent. Issue: 5918366 Fixes the issue where importing 200 products with the same attribute value created 200 identical records. Forward-Port-Of: odoo/odoo#249086
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with companies outside of India, ensuring accurate data presentation.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update resolves an issue where certain Non-Resident (NRI) GSTINs were not recognized during the partner autocomplete process. The fix updates the validation logic to accept a wider range of valid NRI GSTIN formats, ensuring accurate data entry for NRI customers. This improves the user experience and data integrity.
Original PR description
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete`…
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete` modules. - Navigate to Settings > Users & Companies > Companies. - Click `New` and set `Tax ID` to `9922JPN29001OSU`. - Wait for 5–10 seconds. **Observation:** The partner autocomplete does not trigger, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root Cause:** The issue was already fixed in core validation by PR [1], but the GSTIN validation logic used in partner autocomplete was not updated. At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a revised structure and therefore are not matched by the existing regex. **Fix**: This commit ensures that valid NRI GSTIN formats are accepted during validation by applying a fix similar to [1] to the partner autocomplete GSTIN validation at [2]. Related IAP PR: https://github.com/odoo/iap-apps/pull/1491 [1]: https://github.com/odoo/odoo/pull/251760 [2]: https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52 Forward-Port-Of: odoo/odoo#253799
This update resolves a technical error preventing the burndown chart in the Project app from loading correctly when no project is selected. The change ensures the necessary context is set, preventing errors that occur in sample mode. This improves the stability and usability of the burndown chart feature.
Original PR description
The burndown chart embedded actions use action_id which bypasses the Python method that sets required context (stage_name_and_sequence_per_id). Without this context, the JS model makes RPC calls that fail in sample mode when no project record is selected. This change replaces action_id with python_method, following the same pattern used by hr_timesheet for similar embedded actions. Steps to reproduce: 1. Open Project app 2. Access burndown chart via embedded action without records 3. Sample mode triggers the crash Current behavior: TypeError reading undefined field type Expected behavior: Burndown chart loads with proper context task-5347524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239000
Features or functions removed from Odoo
This update removes outdated and unused code within the l10n_pe_edi_pos module, streamlining the system. The removal was necessary due to an error related to dependencies and ensures the module's efficiency and stability. This is a routine maintenance task to keep our software running smoothly.
Original PR description
In this commit: - error due to dead code : http://pastebin.com/q65h1fME - Form 19.2v 'account_edi' is not in the dependencies, so we have to remove that dead code. - Here is the task which remove that dependencies : https://www.odoo.com/odoo/project/967/tasks/5164609
Miscellaneous changes
This pull request updates translations for several Odoo modules into Uzbek (uz). It copies existing translations from the 19.0 release, focusing on direct module matches. Importantly, the translations were not fully verified across modules, meaning some potential inconsistencies may remain. This update ensures Uzbek language support for key Odoo features.
Original PR description
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253632
7 changes
Resolved issues and error corrections
This update corrects a bug that was preventing accurate calculations for salary percentages within the HR contract module. The fix ensures that benefit amounts are correctly calculated based on percentage values, improving the reliability of payroll data. This resolves a minor issue impacting HR reporting.
This update resolves an issue where default values for selection-type salary inputs weren't correctly displayed in payslips. The fix ensures that the form view updates properly when new inputs are added, guaranteeing accurate and consistent salary calculations. This improves the reliability of payroll processing.
Original PR description
Steps to reproduce: - Create a Salary Input of type 'selection'. - Assign a default value to this input. - Add the input to a payslip. Bug Cause: The form view is not re-comupting the values when it's assigned for the first time since the container is not changed Solution: Forcefully update the payroll_properties when we add new inputs in the payslip form task-5357904
This update reverts a recent change related to the Eco Voucher benefit within the Belgian HR payroll module. This change was causing issues with payroll calculations and has been rolled back to ensure accurate and compliant payroll processing. The change ensures continued compliance with Belgian tax regulations.
This update fixes an issue where the website's filter options disappeared when using the 'off-screen menu' style. The change ensures the filter button remains visible when no sort or pricelist options are selected, providing a consistent and user-friendly experience. This improves the usability of product searches on the website.
Original PR description
Versions -------- - 19.1+ Steps ----- 1. Disable all pricelists to hide pricelist filter 2. Go to shop page 3. Change Filters style to "Off-screen Menu" - Note that a "Filters" button appears next to the sort by dropdown 4. Remove the sort by from the toolbar by untoggling it Issue ----- When the filters are set to off-screen and there is no sort by dropdown or pricelist dropdown, the filters button disappears. Cause ----- The div containing the filters button, sort by dropdown, and pricelist dropdown, is set to `d-lg-none` when there is no pricelist dropdown and no sort by dropdown, causing it do disappear. Solution -------- Only allow the div to disappear when the filter button shouldn't appear (`wsale_has_filters_btn` set to False) opw-5933858
This update resolves a crash in the mobile view of the project kanban when adding a 'Blocked By' task. The fix ensures that the system checks for the existence of the parent task before attempting to access its details, preventing a 'Cannot read properties of undefined' error. This improves the mobile user experience and prevents data entry issues.
Original PR description
Currently, opening a task in mobile view and clicking on the 'Add Blocked By' crashes. ### **Steps to reproduce:** 1) Install project app with demo data 2) Open any task from the project, switch to…
Currently, opening a task in mobile view and clicking on the 'Add Blocked By' crashes. ### **Steps to reproduce:** 1) Install project app with demo data 2) Open any task from the project, switch to mobile view 3) Click on the **Blocked By** page and click **Add Blocked By**. ### **Error:** TypeError: Cannot read properties of undefined (reading 'raw_value') ### **Root cause:** The `project_sub_task_view_kanban_mobile` view inherits the base task kanban and removes the `parent_id` field via xpath `position='replace'` at [1]. However, the wrapping `<a>` element with `t-if='record.parent_id.raw_value'` at [2] remains in the template. Since the field is no longer declared, `record.parent_id` is undefined, and accessing `.raw_value` on it causes the crash. [1]- https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/project/views/project_task_views.xml#L759 [2]- https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/project/views/project_task_views.xml#L704 ### **Fix:** This commit ensures that in the base kanban template, it checks that `record.parent_id` exists before accessing `.raw_value`. **opw-5920660**
This update resolves an issue where mass email sorting failed due to inconsistent date information in emails. The fix adds a default date of midnight to emails without a defined date, ensuring consistent sorting and preventing errors during email processing. This improves the reliability of email sending operations.
Original PR description
Background: In odoo.com, due to some migration scripts, there are messages without neither a date nor create_date Issue: When sending mass emails to applicants, when determining the parent email, emails are sorted using their date, but since some emails have a date and some don't, comparing them results in an exception (comparing datetime with bool). Fix: Add datetime.min as a fallback for the email's date if neither date nor create_date are set. Task-6041584
A previous change caused an error when starting a new pay run if the date field was left blank. This fix ensures the system validates the date field before processing, preventing the 'value.toFormat is not a function' error. This ensures users can consistently initiate pay runs.
Original PR description
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` >…
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Payslips` > `Pay Runs`. - Click `New`, remove the `period value`, and click `Continue`. `TypeError: value.toFormat is not a function` After this recent [commit] that changed the required field validation behavior, when the date field is empty and it attempts to serialize the date [1], which raises the error here [2]. Although the start and end date field is required, the ORM call is executed without the value for the date field. This commit ensures that, similar to the base PayslipBatchFormController [3], the fields are validated before making the ORM call. [commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8 [1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14 [2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536 [3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20 sentry-7207509338
7 changes
Resolved issues and error corrections
This update resolves an issue where payrun creation failed for employees with contracts starting mid-period. The fix ensures accurate calculation of integration factors by handling contract start dates correctly, preventing an error related to accessing the year of the start date. This ensures all employees are paid accurately.
Original PR description
An error is thrown when an employee's contract starts mid-period. ```py Invalid Operation Wrong python code defined for: - Employee: Cesar Osbaldo Cruz Solorzano - Version: False - Payslip: Payslip -…
An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```
Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown
Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.
Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.
target: saas-18.4
task-6034836A recent update caused the copy button in the spreadsheet feature to become disabled. This fix resolves that issue, ensuring users can reliably copy spreadsheets as intended. This improvement maintains a key functionality for managing data.
Original PR description
Fix error which disabled the copy button. Forward-Port-Of: odoo/enterprise#110086
This update ensures that follow-up emails for invoices always send the correct PDF attachment, regardless of whether the user uploaded a standard invoice PDF or another type of document. Previously, emails were using the wrong attachment, leading to potential confusion. This change ensures accurate and consistent invoice follow-up communications.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420 Forward-Port-Of: odoo/enterprise#110753 Forward-Port-Of: odoo/enterprise#98820
This update fixes an issue where multiple attachments sent through WhatsApp Discuss were only delivering the first one. The change ensures that Odoo correctly handles multiple file uploads by validating the total number of attachments before sending, preventing data loss and improving the reliability of WhatsApp communication within Odoo.
Original PR description
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a…
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a WhatsApp Discuss channel. 2. Send the message. -> Odoo shows all files, but only the first reaches the destination. ### Cause WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest. ### Fix Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss. opw-5889035 Forward-Port-Of: odoo/enterprise#107424
This update fixes a usability issue on mobile devices where a key button was hidden within a dropdown, requiring extra scrolling. The change ensures the loan creation process is smoother and more intuitive on smaller screens, allowing users to easily access necessary features.
Original PR description
Forward-Port-Of: odoo/enterprise#110552 Forward-Port-Of: odoo/enterprise#110120
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with non-Indian companies, ensuring data accuracy and a consistent user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update ensures that NACHA payment files use the correct bank account holder's name instead of the customer's name in Odoo. Prioritizing the accurate account holder name improves payment processing accuracy and reduces potential errors with financial institutions. This change ensures compliance and avoids issues with bank reconciliation.
Original PR description
The NACHA entry detail was using the partner's name (res.partner.name) for the Individual Name field. This should instead prioritize the Account Holder Name (acc_holder_name) from the bank account, as this reflects the actual name on the bank account which may differ from the partner's name in Odoo. The code now uses bank.acc_holder_name if set, and falls back to payment.partner_id.name if not set. Forward-Port-Of: odoo/enterprise#108414 Forward-Port-Of: odoo/enterprise#105582
10 changes
Resolved issues and error corrections
This update fixes an issue where creating users for employees with identical email addresses would cause an error. The change now displays a warning instead, improving the user experience and preventing data entry disruptions. This ensures smoother employee onboarding processes.
Original PR description
Creating users for multiple employees sharing the same email address raises a traceback.
Stpes to reproduce the error:
- Install the ``hr`` module
- Create two employees with the same email
- Go to List view of employees > Select both employees > Actions > Create user
Traceback:
```py
ValueError: UniqueViolation('duplicate key value violates unique constraint "res_users_login_key"
```
https://github.com/odoo/odoo/blob/0bfd2a253781e43b0e0d16b3fd9d1df485f4fa6b/addons/hr/models/hr_employee.py#L389
The error occurs because the same email is used as the login for multiple users.
This commit ensures that when multiple employees share the same email address,
a warning notification is displayed instead of raising an error.
sentry-7324335174
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects an issue where cancelled vendor bills were incorrectly included in the Sweden (l10n_se) SIE export file. The fix ensures that cancelled transactions are properly excluded, aligning the export data with the general ledger. This prevents discrepancies in reporting.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#108767
This update resolves an issue where employees were incorrectly appearing in payslip generation reports due to a misinterpretation of contract status. The fix ensures that employees are only included if they have an active contract matching the selected salary structure type, improving the accuracy of payslip calculations. This ensures correct payroll processing.
Original PR description
**Steps to reproduce** - Create an employee - Have a first contract in "New" state covering some period of the month with "Salary Structure Type" A. - Have a second contract in "Running" state…
**Steps to reproduce** - Create an employee - Have a first contract in "New" state covering some period of the month with "Salary Structure Type" A. - Have a second contract in "Running" state covering some other period of the month with "Salary Structure Type" B. - Go to the payslip batch for the current month and click on "Generate payslips". - In the wizard, select "Salary Structure Type" B: employee appears in the list as expected. - In the wizard, select "Salary Structure Type" A. - Unexpected: employee appears in the list, although the contract using that structure type is not in an open or closed state. **Cause** Employees were displayed if they had a contract in open/close state AND a contract with the matching structure type, but we need to check if there's some contract matching both conditions (correct state AND matching structure type). A new function is added to be able to inject an extra domain. opw-5443624 Forward-Port-Of: odoo/enterprise#110027 Forward-Port-Of: odoo/enterprise#104016
This update resolves an issue where the batch view in the stock picking module incorrectly displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the batch creation process and preventing user confusion. This improves the user experience for creating and managing batches.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/odoo#249581
This update resolves an issue where the batch view in the Odoo Enterprise system incorrectly displayed multiple "Validate" buttons. The fix ensures that only one "Validate" button is visible, streamlining the quality check process for users. This improves usability and prevents confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/enterprise#107993
This update corrects a test failure within the Odoo Enterprise system. The issue occurred when the 'accountant' module was not present, leading to an incorrect expected account value. This fix ensures the test runs successfully, improving the stability and reliability of the payment processing functionality.
Original PR description
Currently test_bank_rec_widget_batch_foreign_currency_journal_without_entries fails when `accountant` module is not installed because the expected account differs opw-5887218
This update corrects a display issue where the 'Relationship' field was incorrectly shown for employees outside of Indian companies. The fix ensures this field is only visible for employees associated with Indian businesses, aligning with localization requirements. This improves data accuracy and user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country . ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254162
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with non-Indian companies, ensuring data accuracy and a better user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update corrects a bug preventing the partner autocomplete feature from recognizing valid Non-Resident (NRI) GSTINs. The fix updates the validation logic to accommodate newer GSTIN formats, ensuring accurate tax ID input for NRI customers. This improves data accuracy and streamlines the company setup process.
Original PR description
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete`…
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete` modules. - Navigate to Settings > Users & Companies > Companies. - Click `New` and set `Tax ID` to `9922JPN29001OSU`. - Wait for 5–10 seconds. **Observation:** The partner autocomplete does not trigger, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root Cause:** The issue was already fixed in core validation by PR [1], but the GSTIN validation logic used in partner autocomplete was not updated. At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a revised structure and therefore are not matched by the existing regex. **Fix**: This commit ensures that valid NRI GSTIN formats are accepted during validation by applying a fix similar to [1] to the partner autocomplete GSTIN validation at [2]. Related IAP PR: https://github.com/odoo/iap-apps/pull/1491 [1]: https://github.com/odoo/odoo/pull/251760 [2]: https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52 Forward-Port-Of: odoo/odoo#253799
This update resolves an issue where popups wouldn't close when the Escape key was pressed. The fix ensures the Escape key event is correctly routed to Bootstrap's modal handler, regardless of whether the popup contains interactive elements. This improves the user experience by allowing users to easily close popups.
Original PR description
Steps to reproduce: =================== - Add a Popup snippet to a page - Remove all links/buttons inside the popup - Save and wait for the popup to appear - Press ESC -> Nothing happens. Cause:…
Steps to reproduce:
===================
- Add a Popup snippet to a page
- Remove all links/buttons inside the popup
- Save and wait for the popup to appear
- Press ESC
-> Nothing happens.
Cause:
======
https://github.com/odoo/odoo/blob/a922c31fa7ccd1107b31287ab1f75697fae874f8/addons/website/static/src/snippets/s_popup/000.js#L219-L226 when the popup contains no tabbable elements, `this.el.focus()` was called. `this.el` refers to the `.s_popup` div, not the `.modal` element that Bootstrap monitors for keyboard events. As a result, the ESC keydown event never reached Bootstrap's handler and the modal stayed open.
When focusable elements (links, buttons) were present, `tabableEls[0].focus()` correctly focused an element inside `.modal`, so ESC worked fine in that case.
Solution:
=========
Replace `this.el.focus()` with `this.el.querySelector(".modal").focus()` so focus lands on the `.modal` element allowing Bootstrap's built-in ESC handler to fire correctly in all cases
opw-5891054
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253694
Forward-Port-Of: odoo/odoo#2500502 changes
Resolved issues and error corrections
This update fixes a problem where users were receiving duplicate push notifications from Social Marketing. The fix ensures notifications are displayed only once by adjusting how Firebase and the service worker interact. It also resolves a subscription error, improving push notification functionality across browsers.
Original PR description
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the…
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field. 2. Our service worker displays a notification popup when receiving a background message from Firebase. To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us. Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications. To fix that issue, we will: 1. Ensure that the service worker reaches the `ready` state before communicating with it. 2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page. Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers. Task-5124645 Forward-Port-Of: odoo/enterprise#96029
This update resolves an issue where long tax amounts on invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the number of digits, improving the clarity and accuracy of revenue reports for Kenyan businesses using the Odoo Enterprise system. This enhancement focuses on a user experience improvement.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#110649 Forward-Port-Of: odoo/enterprise#100319
1 change
Resolved issues and error corrections
This update ensures that follow-up emails for invoices now send the actual invoice PDF attachment, rather than relying on the main attachment. This prevents issues where users might have uploaded alternative PDF files, ensuring accurate and complete invoice information is sent to customers. This resolves a previous bug related to attachment selection.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420 Forward-Port-Of: odoo/enterprise#110753 Forward-Port-Of: odoo/enterprise#98820
16 changes
Resolved issues and error corrections
This update fixes an issue where sales order margins were incorrectly calculated due to a misunderstanding of the company context. The fix ensures margins are accurately determined based on the company associated with the specific sales order line, regardless of the user's default company setting. This improves the reliability of margin reporting.
Original PR description
Steps to reproduce: - Have 2 companies: - Company A with a property_cost_method 'average' - Company B with a property_cost_method 'standard' - Create a sales order in B - Set the default company of the user to A. - Under certain scenarios, when we confirm the sales order, there will be a `flush_all`. - When that's the case, margins are recomputed with `line.product_id.categ_id.property_cost_method` as `average` instead of `standard`. In other words, it will take the property_cost_method from the `user.company_id` (A), instead of the property_cost_method from the `line.company_id` (B). This fix ensures the `property_cost_method` considered is the one related to the company of the sale order line. A similar issue was fixed on https://github.com/odoo/odoo/pull/192890 OPW-5939464 Forward-Port-Of: odoo/odoo#252161
This update fixes an issue with how numbers are displayed in Odoo. Previously, the formatting was inconsistent, leading to potential inaccuracies. This change ensures numbers are displayed with the correct level of precision, resolving a previous bug.
Original PR description
this is to revert the bug from commit 8c199f7 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 corrects a technical error in the l10n_cl module for Odoo versions 18.0 and later. The fix prevents a broken view from causing issues during upgrades, ensuring smoother rolling releases and reducing manual database checks for developers. This improves the stability and reliability of invoice generation for Chilean businesses.
Original PR description
There is a broken xpath in l10n_cl.report_invoice_document When the l10n_cl module is installed, it results in the faulty view being applied to v18 and later versions. This is particularly annoying because some rolling releases fail because a view with invalid locator is found. The view won't be disabled after a rolling release upgrade and many developers will be spared from checking the databases manually.
This update resolves a technical issue where the delivery process would fail if Sendcloud didn't respond to shipping price requests. The fix prevents an error from occurring, ensuring more reliable delivery calculations and reducing potential disruptions to order processing. This improves the overall stability of the delivery module.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with non-Indian companies, ensuring accurate data presentation.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country . ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254162
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with non-Indian companies, ensuring data accuracy and a consistent user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update fixes an issue where imported invoices incorrectly matched purchase orders when only part of the ordered quantity had been received. The change adds a crucial check to ensure invoice quantities align with the actual delivered quantities, preventing mismatched records and improving data accuracy. This ensures consistent reporting and avoids discrepancies between invoices and purchase orders.
Original PR description
## Issue: When a Purchase Order is created for a quantity of 2 and only 1 unit is received, importing a vendor bill with quantity 2 and the same unit price incorrectly results in a full match The PO…
## Issue: When a Purchase Order is created for a quantity of 2 and only 1 unit is received, importing a vendor bill with quantity 2 and the same unit price incorrectly results in a full match The PO is linked, but the bill line quantity is overwritten to 1 (the received quantity), leading to an inconsistency between the imported bill and the original document ## Cause: In `_match_purchase_orders()`, a match is performed based on `partner_id` and `amount_total`: https://github.com/odoo/odoo/blob/92a3fe87c711f18d955ddf454ce1f4194dfcda20/addons/purchase/models/account_invoice.py#L429-L439 However, the previous safeguard logic related to `total_match` is missing: https://github.com/odoo/odoo/blob/92a3fe87c711f18d955ddf454ce1f4194dfcda20/addons/purchase/models/account_invoice.py#L388-L400 This check is not only meant to compare total amounts; it should also ensure that the `amount_to_invoice` is consistent When the purchase method is based on received quantities, the full ordered quantity should not be considered a full match if part of it has not yet been delivered ## Steps to reproduce: We'll use the default company as vendor, choose depending on your setup - Install `purchase` - Create a Product (invoicing policy: ordered qty, and control policy: delivered qty) - Create and confirm a PO (Vendor: Default Company, Product: Created Product, Quantity: 2, Unit Price: 100) - Set the received quantity to 1 - Create and post an Invoice (Customer: Default Company, Product: Created Product, Quantity: 2, Unit Price: 100) - Download the PDF - Go in Bills and import the PDF Before the fix, the match should be done and there is a quantity mismatch opw-5043054
This update resolves an issue where the Public Administration (PA) invoice status wasn't correctly updated after SDI validation, leading to potential rejection errors. The fix ensures that the PA status accurately reflects the invoice's real-time state, improving data consistency and reducing processing delays. This change impacts Italian VAT compliance.
Original PR description
### Issue: After the SDI validation, the state was never updated to match the PA state, resulting in a mismatch with the actual status ### Cause: When `l10n_it_edi_state` is set to `forwarded`, the cron `cron_l10n_it_edi_download_and_update` doesn't consider that a new state could occur However, invoices sent to Public Administration can still be rejected after being forwarded It is not possible to reproduce the issue with the demo system, as it only sets the state to `forwarded` Ticket [link](https://www.odoo.com/odoo/project.task/5391891) opw-5391891
This update corrects a recent change that removed the ability to click on component lots within the traceability report. The initial removal was a poor workaround to limit breadcrumb size, and this fix restores the intended functionality. This ensures users can fully trace components within the traceability report.
Original PR description
commit d7f81c25555c800bf296da2507d010257292aa55 It was removed in order to limit the breadcrump size. However it was a stupid solution and it's better to let the feature rather than limiting the breadcrump size.
This update simplifies invoice processing by automatically enabling self-billing functionality within the core Odoo account module. Previously, this required a separate module. Additionally, the xRechung integration has been removed, ensuring invoices are only sent to government entities as intended.
Original PR description
Everybody is now able to receive self billing invoices even without the additional module. So the service should be added to the base module. Also remove xRechung because users are not supposed to receive it, only government. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where certain valid Non-Resident (NRI) GSTINs were not recognized during the partner auto-complete process. The fix updates the validation logic to accommodate newer GSTIN formats, ensuring accurate identification of NRI tax IDs. This improves the usability of the company creation feature for users with NRI tax registrations.
Original PR description
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete`…
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete` modules. - Navigate to Settings > Users & Companies > Companies. - Click `New` and set `Tax ID` to `9922JPN29001OSU`. - Wait for 5–10 seconds. **Observation:** The partner autocomplete does not trigger, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root Cause:** The issue was already fixed in core validation by PR [1], but the GSTIN validation logic used in partner autocomplete was not updated. At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a revised structure and therefore are not matched by the existing regex. **Fix**: This commit ensures that valid NRI GSTIN formats are accepted during validation by applying a fix similar to [1] to the partner autocomplete GSTIN validation at [2]. Related IAP PR: https://github.com/odoo/iap-apps/pull/1491 [1]: https://github.com/odoo/odoo/pull/251760 [2]: https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52 Forward-Port-Of: odoo/odoo#253799
This update resolves a problem where tours on the website weren't loading translations correctly, particularly in newer Chrome versions. The change introduces a temporary step to ensure translations load before the tour begins, preventing delays and ensuring a smoother user experience.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/odoo#253896
This update resolves a problem where the website's tour process was experiencing delays loading translations, particularly with recent Chrome versions. The fix adds a temporary step to ensure translations load before the tour begins, improving the overall user experience and preventing tour interruptions.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#110648
This update corrects a bug that caused incorrect hour calculations in the Gantt view for flexible work schedules. The issue stemmed from timezone discrepancies between employee calendars and the system, leading to inflated hour displays. The fix ensures accurate hour calculations regardless of timezone differences.
Original PR description
Description: ------------------ When viewing attendance in Gantt view with flexible working schedules, expected hours displayed incorrectly when device, company, and employee calendar timezones differ (e.g., 1 day shows 16h instead of 8h). Root cause: ------------------ Two related timezone handling issues: 1. Gantt passes UTC boundaries that span multiple calendar days when converted to calendar timezone 2. Resource calendar creates flexible intervals using wrong timezone (employee timezone instead of calendar timezone) Solution: -------------- - hr_attendance_gantt: Normalize date boundaries to full calendar days in calendar timezone before passing to interval calculation - resource: Force flexible hours block to consistently use calendar timezone for date extraction and interval creation opw-5241330
This update fixes an issue where attendance hours were incorrectly calculated when employees and companies had different time zones. The change ensures accurate hour calculations for flexible work schedules by consistently using the company calendar timezone. This improves the reliability of attendance tracking.
Original PR description
Description: ------------------ When viewing attendance in Gantt view with flexible working schedules, expected hours displayed incorrectly when device, company, and employee calendar timezones…
Description: ------------------ When viewing attendance in Gantt view with flexible working schedules, expected hours displayed incorrectly when device, company, and employee calendar timezones differ (e.g., 1 day shows 16h instead of 8h). Root cause: ------------------ Two related timezone handling issues: 1. Gantt passes UTC boundaries that span multiple calendar days when converted to calendar timezone 2. Resource calendar creates flexible intervals using wrong timezone (employee timezone instead of calendar timezone) Test update: ------------------- Updated test_no_carried_over_leaves_for_flexible_resource to reflect correct flexible calendar behavior. For flexible calendars, the duration between dates counts inclusive calendar days. Changed the calculation from `days * 24 / hours_per_day` to `(end_date - start_date).days + 1` to properly account for inclusive date counting (e.g., Dec 30 to Dec 31 includes both days = 2 days). Solution: -------------- - hr_attendance_gantt: Normalize date boundaries to full calendar days in calendar timezone before passing to interval calculation - resource: Force flexible hours block to consistently use calendar timezone for date extraction and interval creation opw-5241330
This update corrects a technical issue where the Avatax settings within the accounting module were not correctly identifying the company type. This ensures accurate tax calculations and reporting by properly associating Avatax data with the correct company information. It's a minor fix that improves the reliability of financial data.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. task-none Forward-Port-Of: odoo/odoo#254242
7 changes
New functionality added to Odoo
This update incorporates the Slovakian PEPPOL code (0245) into the Odoo accounting system. This is necessary to comply with European regulations regarding electronic invoicing and data exchange through the PEPPOL network, specifically for businesses operating in Slovakia. The change supports secure and standardized financial transactions.
Original PR description
- Added new code Information: https://docs.peppol.eu/poacc/self-billing/3.0/v3.0.1/ https://docs.peppol.eu/edelivery/codelists/v9.5/Peppol%20Code%20Lists%20-%20Participant%20identifier%20schemes%20v9.5.html OPW-6017742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update ensures Odoo's SEPA XML transactions comply with the latest ISO 20022 standard by using a structured address format. Previously, addresses were unstructured, but now they utilize hybrid tags for country, city, and postal code, improving data accuracy and compatibility with SEPA regulations. Validation has also been added to guarantee country and city information is present.
Original PR description
According to the ISO 20022 XML standard, any address included in SEPA interbank messages must be in a structured or hybrid format. Before this commit: --- - `<PstlAdr>` generation in SEPA XML used unstructured `<AdrLine>` tags. In this commit: --- - Generate <PstlAdr> with hybrid tags `<PstCd>`, `<TwnNm>`, `<Ctry>` and `<AdrLine>` in compliance with ISO 20022 requirements. - Added validation to ensure both country and city are present for partners and employees. --- task-5003410
Resolved issues and error corrections
This update resolves an error message that appeared when exporting payroll data to SDWorx for freelance employees. The change ensures that the system doesn't flag missing SDWorx codes for freelancers, streamlining the export process and preventing user confusion. This improves the user experience for our Belgian clients.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342
This update resolves an issue preventing new employee creation when generating BVG-LLP reports with duplicate monthly data. The fix addresses a technical problem related to how Odoo processes recordsets, ensuring accurate employee creation in Swiss companies using the LPP reporting feature.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742This update corrects a display issue where the 'Relationship' field was incorrectly shown to employees outside of India. The fix ensures that this field is only visible for employees associated with Indian companies, aligning with local tax regulations and improving data accuracy.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country . ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees linked to non-Indian companies, ensuring accurate data presentation.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888
This update corrects a bug where public time off end dates were incorrectly calculated when start dates were set to midnight. The fix ensures the end date accurately reflects the intended duration, resolving a validation error and preventing incorrect scheduling. This improves the reliability of time off management.
Original PR description
## Short functional explanation of the error When creating a public Time off for a Working Schedule, the end date will automatically set to a moment earlier than the set start date if the start date…
## Short functional explanation of the error When creating a public Time off for a Working Schedule, the end date will automatically set to a moment earlier than the set start date if the start date hour is set to midnight sharp. ## Reproduction Steps 1. Go to Employees. 2. Click on Configuration tab > Working Schedules. 3. Select a Working Schedule. 4. A smart button Public Time Off should appear. Click on it. 5. Click New and select a Start Date with a random date but 00:00:00 as hours:minutes:seconds. ### Expected behavior The End date should automatically set 23 hours 59 minutes and 59 seconds later. ### Unexpected behavior A Validation error occurs and the end date is set 1 second before the start date. ## Origin of the issue When setting automatically the end date of a leave, it is set to 23:59:59. With our timezone, if we select midnight, this time will be converted to 23:00:00, the day before: https://github.com/odoo/odoo/blob/e85f1a182ee60a25905369c84ced05480c5a3360/addons/resource/models/resource_calendar_leaves.py#L69-L70 Thus, the resulting end date will be set to the day before, at 23:59:59. Additionally, we have to take into account the timezone of the user to set a consistent end date, and not the generic utc one. __ opw-5187977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr