Tuesday, June 30, 2026
23 changes · saas-19.4
Enhancements to existing features
This update makes e-Dispatch handling easier by moving upload options into the Actions menu, adding a one-step fetch for XML and PDFs, and improving how matching documents are labeled and refreshed. It also fixes commercial invoice status updates so the correct response banner appears while the invoice is awaiting the recipient's reply.
Original PR description
## Description of the issue/feature this PR addresses: Fetch-button and matching UX improvements for e-Dispatch (receipts & deliveries), plus a fix to commercial (TICARIFATURA) invoice status…
## Description of the issue/feature this PR addresses: Fetch-button and matching UX improvements for e-Dispatch (receipts & deliveries), plus a fix to commercial (TICARIFATURA) invoice status handling and its response banner on account.move. ## Current behavior before PR: - "Upload e-Dispatch (XML)" is only available as a list-view toolbar button. - There is no single action to fetch e-Dispatch XMLs and then their PDFs. - "Update From GİB e-Dispatch (XML)" shows even when no XML is linked to the receipt. - Updating a receipt from its XML does not (re)fetch the matching Nilvera PDF. - Outgoing deliveries do not fetch the Nilvera PDF on status synchronization. - Fetched XML attachments are hard to match (no customer name in the name). - Commercial (TICARIFATURA) invoices that succeed without a recipient answer never reach the "succeed" status, and the commercial response banner (awaiting / approved / rejected) does not display correctly. ## Desired behavior after PR is merged: - "Upload e-Dispatch (XML)" is moved to the Actions menu on the list view. - A new "Fetch e-Dispatches" action fetches the XMLs and then the PDFs, in order (receipts and deliveries). - "Update From GİB e-Dispatch (XML)" is hidden until an e-Dispatch XML is linked. - Updating a receipt from its XML (re)fetches the matching Nilvera PDF. - Outgoing deliveries fetch the Nilvera PDF (via the Sale channel) on a successful status sync. - Fetched XML attachments carry the customer name for easier matching. - Commercial invoices persist "succeed" while awaiting the recipient's answer, and the awaiting / approved / auto-approved / rejected banners display correctly. Upgrade PR: https://github.com/odoo/upgrade/pull/10625 task-6044179 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Australian payroll rules have been updated for the 2026-27 financial year, including revised tax rates and formulas. The change also corrects how the Medicare exemption is applied from 2024 onward, helping ensure payroll calculations and historical corrections stay accurate.
Original PR description
Update tax rates and formulas for the 2026-27 financial year in the Australian payroll module. This commit also amends the tax rates and formulas from 2024 onwards. The Medicare exemption is now properly factored into the tax rates from the 2024-25 fiscal year forward, with the revised formula applied accordingly. Data for pre-2024 remains supported to facilitate importing historical payslips for corrections, aligning with the ATO rule allowing amendments for up to 5 years after the original payslip date. 6252689 Forward-Port-Of: odoo/enterprise#121561
Users can now choose a date directly from the stock report search panel instead of opening a separate inventory-at-date screen. This makes it faster to review stock levels at a past moment while keeping all current filters, and users can switch back to live stock with one click.
Original PR description
Backport of odoo/odoo#264699 Instead of navigating to a separate view via the 'Inventory at Date' wizard, users can now pick a date directly in the search panel. This sets 'to_date' in the context, causing quantities to be computed at the chosen date while preserving all active filters (category, warehouse, search terms). The date picker uses 1-minute rounding for precise timestamp selection, and defaults to the current time when opened. A 'Current stock' link appears to clear the date and return to live quantities. task-6152466 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 change adds an initial aging report for stock values and quantities, letting users analyze remaining inventory by period in pivot-style reports. It makes these figures available on demand for reporting, which improves visibility into inventory aging and stock valuation trends.
Original PR description
First implementation of the aging report. It's not optimized yet. The values are simply coming from the existing compute method. Task: 5967087 ##stats for 100 products We can see the quantity on hand has | | naive impl (30 % without qty) | naive impl (0 % without qty)| |--------|--------|--------| | 450 m/M | 1.9sec | 3.1sec | | 2000m/M | 8.6sec | 26sec | 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
Charts in spreadsheets can now display an info icon that opens additional information. Users can add a short description and a “see more” link from the design panel, making charts easier to understand and giving viewers a quick path to more context.
Original PR description
It's now possible to add a information text and/or a see more link to a chart. Accessible with the info icon on the chart. Editable in the design side panel. Task: 5365254
Resolved issues and error corrections
This change keeps the Base Unit Count value at very high precision, so products sold in large packs can be priced correctly at the unit-reference level. It fixes cases where values like 0.0001 were being rounded too aggressively, which could distort the displayed reference price for bulk items.
Original PR description
**Description of the issue/feature this PR addresses:** The `Product Reference Price` feature in `website_sale` cannot correctly handle products sold in large packs when the reference quantity…
**Description of the issue/feature this PR addresses:** The `Product Reference Price` feature in `website_sale` cannot correctly handle products sold in large packs when the reference quantity requires a very small `base_unit_count`. For example, a product sold as a `box of 10000` screws should be able to use `0.0001` as its `Base Unit Count`, so the reference price can be computed against the box quantity correctly. **Current behavior before PR:** `base_unit_count` uses the default float precision, so values with more than two decimal places are rounded in the product form. When trying to set `Base Unit Count` to `0.0001`, the value is rounded to `0.00` / `0.01`, which makes the Product Reference Price computation incorrect. Steps to reproduce: 1. Go to Settings > Website and enable Product Reference Price. 2. Create or open a product named `Screws`. 3. Set Sales Price to `$ 1.00`. 4. On the product form, set Base Unit Count to `0.0001`. 5. In Custom Unit of Measure, type `box of 10000` and press Create. <img width="1374" height="740" alt="1" src="https://github.com/user-attachments/assets/2d4f7863-b2cd-4c7c-87e1-11526dc50551" /> **Desired behavior after PR is merged:** `base_unit_count` keeps high-precision values such as `0.0001`. This allows `Product Reference Price` to correctly support large-pack scenarios, such as selling screws in a `box of 10000`, by storing `base_unit_count` with unlimited numeric precision. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270261 Forward-Port-Of: odoo/odoo#262579
This fix ensures orders paid through the Viva app-to-app flow complete the same follow-up steps as normal payments, including automatic receipt and preparation printing. It also makes sure Viva’s payment prompts still appear for fast payment methods and clears outdated saved choices so users can correct mistakes more easily.
Original PR description
[FIX] point_of_sale, pos_viva_com: automatic receipt printing 3 Fixes for the app-to-app integration of Viva 1. Under the normal flow the `OrderPaymentValidation` does the payment validation and post…
[FIX] point_of_sale, pos_viva_com: automatic receipt printing 3 Fixes for the app-to-app integration of Viva 1. Under the normal flow the `OrderPaymentValidation` does the payment validation and post validation operations (such as receipt printing or preparation prints). Then it launches the `FeedbackScreen` with the validation promise on the `waitFor` prop. The `pos_viva_com` app-2-app integration does the payment validation on the backend on the callback endpoint. Then it redirects the user directly on the `FeedbackScreen` skipping the normal validation and post validation operations. This means that receipts and preparation prints do not get processed. This PR adds a check on the `FeedbackScreen` to see whether there is anything set on the `waitFor` prop. If the prop is undefined, we can expect that the screen was mounted outside the normal flow, so we run the post validation operations manually. --- 2. Using the fast payment method with Viva would use `order.addPaymentLine` instead of the overloaded `payment_screen.addNewPaymentLine`. So the integration pop up which is defined in the `payment_screen` would never fire. Now I've added a check on `validateOrder` to detect whether we're about to use a `fastPaymentMethod`, in which case it will apply the same behaviour as the override of the `payment_screen.addNewPaymentLine` --- 3. Added a patch for `reloadData` which will remove the answer for the Viva wallet pop up from local storage in case users change their minds or made a mistake Task-[6251297](https://www.odoo.com/odoo/project/1737/tasks/6251297) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267714
This update fixes an issue where font formatting could be applied outside the part of the page that can actually be saved. As a result, style changes made in website builder and translation views are now preserved correctly after saving.
Original PR description
Commit e0cf601ab6fc1d7cb007fcb16ee4bb6097ba6fdd added a condition to apply format on the parent of fully selected unsplittable nodes. But this could lead to format applied outside of `contenteditable=true` nodes in some cases of website builder. This commit adds a condition to only apply format outside the unsplittable if it is not the node with `contenteditable`. Steps to reproduce: - In event page, open website builder - Double click on "Starts" in the sidebar inside the event page - Change font size - Save - Bug: the changed font size is not save (a span with the font class was created outside the savable element) ### - In translate mode - Select a whole translation span - Change font size - Save - Bug: the changed font size is not save (the font class was added on the translation span) task-6308352 Forward-Port-Of: odoo/odoo#271888 Forward-Port-Of: odoo/odoo#270401
Tracked links generated without an active website context now fall back to the system base URL instead of using a company website by mistake. This ensures emails and queued marketing jobs keep the correct public link domain in multi-company setups.
Original PR description
The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24) override builds link.tracker short URLs…
The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24) override builds link.tracker short URLs from `website.get_current_website()` and the current company's website domain. It was introduced by https://github.com/odoo/odoo/commit/f13ecb15af7f0bdc67e37dfb41e8bac77f5a541a for a multi-company backend flow (users switching companies to post social marketing links), but it runs for every compute, including CRON contexts with no HTTP request such as the mass-mailing queue. Without a request, `get_current_website()` picks an arbitrary website (the first in the database) and `self.env.company` resolves to the user's main company, so the short URL uses that company's website domain instead of `web.base.url`. Fall back to `super()._compute_short_url_host()` (which uses `web.base.url`) when no website is resolvable from the request, session, or context. Backend flows with a real request still hit the company-aware branch. Steps to reproduce: 1. Install Email Marketing and Website. 2. Settings > Companies: create a second company B. Settings > Websites: ensure website A points to company A with domain A, and create website B for company B with domain B. 3. Settings > Technical > Parameters > System Parameters: set `web.base.url` to a third domain C, and add `web.base.url.freeze` = `True`. 4. On company A, Email Marketing: create a mailing with body `<a href="http://example.com">test</a>` and a recipient list, then click Send. 5. Settings > Technical > Automation > Scheduled Actions > "Mass Mailing: Process queue" > Run Manually. 6. Email Marketing > Configuration > Link Tracker: open the tracker generated for the mailing. => The Tracked URL uses domain A. => The Tracked URL uses domain C. Ticket [link](https://www.odoo.com/odoo/project.task/6038590) opw-6038590 Forward-Port-Of: odoo/odoo#259200
This change fixes an issue where product costs could be calculated incorrectly when a business uses multiple companies or branches. The system now considers stock movements from all relevant companies, so inventory valuation stays accurate and lot-based product costs are shown correctly.
Original PR description
The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities. `_run_fifo_get_stack()` doesn't include the child companies in…
The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities. `_run_fifo_get_stack()` doesn't include the child companies in the `moves_domain`, so it is unable to create a FIFO stack for moves from a child. This leaves extra quantity unaccounted for, which defaults to the standard_price. **Video of the bug:** https://drive.google.com/file/d/11PIfNAIb_Yyo4A-3R0CRF0NV6_HE6EwF/view **Issue:** When multiple companies are selected, the displayed quantity on hand for a product is calculated as the sum of all selected companies. However, the moves domain only looks at the main selected company instead of all selected companies, leading to an incorrectly calculated standard price when using FIFO. This is more apparent on lot-valuated products because the lot standard price is recalculated every time the field is accessed. **Reproduction steps:** - Have a main company - Create a branch company - Create a product, configure it as FIFO on both the main company and branch company - Let the product be tracked by lots and set to `Valuation by Lot` (for demonstrative purposes) - On the main company, set the product cost to $15 (for demonstrative purposes) - Go to only the branch company, make a purchase for one unit of the FIFO product at $100 (make a warehouse for delivery) , validate the receipt - Go to the lot -> When logged in to only the branch company, quantity is 1 and cost is $100 (correct). When logged in to both the main and branch company and viewing from the main company, quantity is 1 and cost is $15 (incorrect) **Fix:** Allow `_run_fifo_get_stack()` to see the moves from all companies in the environment instead of just the main company Related ticket: opw-6064126 Forward-Port-Of: odoo/odoo#270695 Forward-Port-Of: odoo/odoo#258199
This fixes an issue where the timesheet button could disappear from the top bar when attendance options were turned off. Users can now still start or record timesheets from the toolbar, which keeps the feature easy to access in all attendance setups.
Original PR description
Steps to reproduce: - Install Attendance + Timesheets - Disable "Attendances from Backend" - Timesheet icon disappears from toolbar Current behavior: Bridge module permanently removes the `timesheet…
Steps to reproduce: - Install Attendance + Timesheets - Disable "Attendances from Backend" - Timesheet icon disappears from toolbar Current behavior: Bridge module permanently removes the `timesheet systray` from the `registry` and merges it inside the attendance dropdown. When `attendance_from_systray` is off, the dropdown hides itself and takes the timesheet icon with it, leaving no way to log hours from the toolbar. Expected behavior: Timesheet icon should remain accessible when attendance from systray is disabled. Issue: `registry.remove()` at module load made the timesheet icon impossible to restore. Fix: Keep the timesheet systray registered. Patch TimesheetSystray to read `display_systray from lazy_session` on startup and show itself standalone when attendance from systray is off. The template no longer replaces nodes. Header and total_hours are toggled via `position="attributes"` (`t-if="!props.signInOut"`, a prop only passed by the attendance dropdown), and a self-contained dropdown-only footer with the Check out button is added after total_hours. Ref: odoo/enterprise#104347 task-6285068 Forward-Port-Of: odoo/enterprise#121551 Forward-Port-Of: odoo/enterprise#119840
This change fixes memory leaks in the web test suite, making tests more reliable and reducing the chance that one test affects another. It also prevents unwanted server calls during cleanup, which helps avoid test failures at the end of runs.
Original PR description
Fix memory leaks introduced by https://github.com/odoo/odoo/pull/271765 See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents website forms from crashing when a user quickly edits a field or deletes it, especially on slower networks. It also makes an existing form test more reliable, reducing occasional failures during automated checks.
Original PR description
Before this commit, on slow networks users could trigger a traceback by quickly selecting a form field and deleting it. This happened because code executed from `FormFieldOption` `onWillStart` assumed the form field element still existed after awaiting asyncronous functions. This also caused the tour `test_website_form_conditional_required_checkboxes` to occasionally fail on runbot. This commit hardens the method `FormOptionPlugin.loadFieldOptionData` against DOM mutations that may happen while awaiting asyncronous code. In particular, `fieldEl` is now validated after every await. The code is also optimized such that syncronous code relying on the existance of the form field element is executed before the asyncronous one. Note that this change would not be necessary inside builder actions, but it is required because the code is also executed from `FormFieldOption` `onWillStart` and `onWillChangeProps`. runbot-940447
This update prevents the AI assistant from asking for confirmation twice when creating project tasks. It checks that all required information is available before showing the preview or creating the item, which avoids confusion and makes the task creation flow more reliable.
Original PR description
This commit removes an issue where the LLM would retry on error when performing a creation which would give the impression that it created items twice. To do so, this commit now validates that the fields exists before calling the `create()` method, and before showing the preview to the user. Ensuring it avoids throwing an error after the message has been confirmed (resulting in the double preview). task-6229596 X-original-commit: c21dcfe8e4a2c399ee25ebeadd408ce303ce2ff9
Fixed an issue where some conversation threads could fail to show their messages after reloading. This helps ensure users reliably see the latest messages instead of an empty placeholder.
Original PR description
The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates whether the real messages (as opposed to the empty phantom placeholder) are rendered. The mirroring…
The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates whether the real messages (as opposed to the empty phantom placeholder) are rendered. The mirroring effect both read `mountedAndLoaded` as a dependency and wrote it. `useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write pair `[isLoaded=true, mountedAndLoaded=false]`; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window, it drives `mountedAndLoaded` back to false while `isLoaded` stays true. The settling patch then computes the very `[true, false]` pair that was already recorded, so the effect never re-runs: `mountedAndLoaded` is stranded at false and no message is ever rendered. Depend on a monotonic `resetCount` bumped by `reset()` instead of on `mountedAndLoaded` itself. It is never written by the effect, so the recorded dependencies can no longer match the current ones after a reset and the effect always re-runs to re-sync `mountedAndLoaded` with `isLoaded`. `reset()` keeps clearing `mountedAndLoaded` as before (the false dip is needed for the reload scroll handshake), so the behaviour is otherwise unchanged. https://runbot.odoo.com/odoo/error/940032 Forward-Port-Of: odoo/odoo#272589 Forward-Port-Of: odoo/odoo#272281
This update corrects how sales margins are calculated when different tax display modes are used on documents. It ensures the reported margin stays accurate and consistent for users regardless of how taxes and prices are shown.
Original PR description
A newly introduced feature in commit 001d3255cd134656970c98b6e367d6ae3ec77124 caused the tax and price computation to differ, making the margin computation to be inaccurate depending on the document tax mode chosen. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the ticket screen numpad could appear when it should stay hidden in certain point-of-sale setups. It improves the consistency of the interface for users working with specific POS configurations, such as Urban Piper and HR-related flows.
Original PR description
Steps to reproduce: =================== - Ensure `pos_hr` and `pos_urban_piper` is installed. - Install `l10n_in_pos_urban_piper`. - Open a draft Urban Piper order and notice that the numpad is visible. Cause: ====== - The numpad visibility depends on a `t-if` condition in XML. - Due to the asset loading order, this condition gets overridden by another module. Fix: ==== - Move the visibility logic to a getter method. - Override the getter in other modules instead of using XML to control the visibility. Task-6299415 Related Enterprise PR: https://github.com/odoo/enterprise/pull/120571 --- 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 Point of Sale ticket screen where some buttons and the numpad could appear when they should be hidden. It also improves consistency across installed extensions and fixes a dark-mode styling issue for the prep order time field.
Original PR description
Issue 1: ====== Numpad Visibility in TicketScreen of draft urban piper orders Steps to reproduce: =================== - Ensure `pos_hr` and `pos_urban_piper` is installed. - Install…
Issue 1: ====== Numpad Visibility in TicketScreen of draft urban piper orders Steps to reproduce: =================== - Ensure `pos_hr` and `pos_urban_piper` is installed. - Install `l10n_in_pos_urban_piper`. - Open a draft Urban Piper order and notice that the numpad is visible. Cause: ====== - The numpad visibility depends on a `t-if` condition in XML. - Due to the asset loading order, this condition gets overridden by another module. Fix: ==== - Move the visibility logic to a getter method. - Override the getter in other modules instead of using XML to control the visibility. - Also fixed the css issue for prep order time input when using it in dark mode --- Issue 2: ====== Invoice button visible on Chile Company's TicketScreen Steps to reproduce: =============== - Ensure `pos_urban_piper` is installed, open the Chile company's PoS Config - In the ticket screen, we have an invoice button on paid orders. Cause: ===== - Button visibility handled through XML conditions; this condition gets overridden by another module. Fix: === - Move the visibility logic to the getter method and override it in submodules to control visibility. Task-6299415 Related Community PR: https://github.com/odoo/odoo/pull/270088
This change prevents a crash that could happen when a user canceled a new webhook record and then tried to create another one right away. It improves stability in Studio’s Webhook screen and avoids an interruption caused by a timing issue after a frontend update.
Original PR description
Go in studio => Webhook tab Click on new Click cancel and back to list view again click on new Before this commit, there was a crash due to a race condition that appeared after owl3 migration. This commit solves this by protecting the first update in favor of the second opw-6332360 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
The spreadsheet app was updated to the latest version, bringing several usability fixes and small interface improvements. Users should see smoother chart interactions, better font handling on Linux, and fewer pop-up issues when editing spreadsheets and charts.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b0b4c4027f [REL] version 19.4.0 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b0b4c4027f [REL] version 19.4.0 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4ce11c6918 [IMP] package: update to owl alpha 40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/209e5072a9 [IMP] header_size: make getters consistent [Task: 6332479](https://www.odoo.com/odoo/2328/tasks/6332479) https://github.com/odoo/o-spreadsheet/commit/4520b613fe [IMP] statistic bottom bar : close the menu [Task: 6316288](https://www.odoo.com/odoo/2328/tasks/6316288) https://github.com/odoo/o-spreadsheet/commit/2ab649b389 [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171) https://github.com/odoo/o-spreadsheet/commit/2ab8f9a641 [IMP] charts: annotation tool [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/0ff30dd158 [REV] typing: exclude non-exported symbols in type resolution [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f982c69ff5 [IMP] package: update owl to 3.0.0-alpha.39 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e40bf0cc08 [IMP] tools: run esm version is node [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/61f99a225c [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646) https://github.com/odoo/o-spreadsheet/commit/2687933537 [FIX] typing: exclude non-exported symbols in type resolution [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1263a6e8de [FIX] components: use owl3 syntax [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update prevents a rare conflict when uploading vendor bills with automatic OCR enabled. It makes sure the bill’s access token is saved earlier, so OCR processing no longer clashes with the bill creation flow and cause processing failures.
Original PR description
When a new bill is created from an attachment, the import flow may commit inside `_extend_with_attachments`. If automatic OCR is enabled, this commit can run the OCR postcommit callback, which writes on the same account.move. The access token was flushed after that import flow, so it races with the OCR callback and triggers a serialization failure. Create and flush the access token before entering the import flow, so the write happens before OCR postcommit callbacks can run. task-[6340793](https://www.odoo.com/odoo/project/967/tasks/6340793) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The chatter now refreshes properly when a record is reloaded without changing to a different record. This means new attachments and similar updates appear immediately, instead of requiring a full browser refresh or showing outdated indicators.
Original PR description
Since 71336f7f7d25 ("[REF] mail: introduce useOnChange hook"), the chatter only refetched its data (attachments, followers, ...) when the thread identity changed. A same-record form reload keeps the same thread, so nothing was refetched: an attachment created on the record without a message_post (e.g. the pdf generated by "Send & Print", or an account return validation) only showed up after a full browser refresh, the paperclip icon staying stale.
The messages were still refreshed because Thread listens to MAIL:RELOAD-THREAD and calls fetchNewMessages(); the chatter had no such listener. Add the symmetric listener so the chatter reloads its data on a same-record reload too.This fix ensures an employee’s basic salary is classified correctly on Form 2316. Salaries below the tax-exempt cap are now reported as non-taxable, while salaries above the cap remain taxable, which helps prevent incorrect payroll tax reporting.
Original PR description
Previously, a regular (non-MWE) employee's basic salary was always reported as taxable (item 39), regardless of amount. This commit fixes that by checking the yearly basic salary against the tax-exempt cap. If it is below the cap, it is now reported as non-taxable (item 29) and when the amount is above the cap it will be taxable (item 39) Backport of odoo/enterprise@a7362ad273ba8c38aa0908f0765526f8ed8b8193 task-6328424