Tuesday, May 12, 2026
61 changes · saas-19.3
Resolved issues and error corrections
This update fixes an issue where the overtime indication on timesheets was incorrect for employees on flexible work schedules. The change adjusts how the system calculates working hours to accurately reflect actual time worked, particularly when using schedules with varying daily hours. This ensures accurate overtime reporting.
Original PR description
**problem:** On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative…
**problem:** On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week. **steps to reproduce:** 1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average) 2. Assign this schedule to an employee 3. Go to Timesheets, search for the employee 4. Navigate to a past week 5. Enter 4h on each working day 6. Observe the overtime indication shows incorrect value (-01:00) **cause:** In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20. **fix:** - Use the UTC date before conversion to the employee's timezone when determining the flexible date range. - prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones. **note** Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior. link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879 link to the community PR: https://github.com/odoo/odoo/pull/257269 opw-5970511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#116320 Forward-Port-Of: odoo/enterprise#112879
This update corrects a UI issue where the `l10n_co_edi_ubl` field on the Units of Measure form was missing its label, causing user confusion. The fix ensures the field is clearly identified, improving the overall usability of the CO Company settings.
Original PR description
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. -…
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. - Navigate to Invoicing > Settings. - Enable `Units of Measure & Packagings`. - Open `Units & Packagings` and click `New`. **Observation:** The `l10n_co_edi_ubl` field appears between the `Quantity` label and its corresponding field, but its own label is not visible. <img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" /> **Root Cause:** The inherited view [1] inserts the field `l10n_co_edi_ubl` before `relative_factor` in the base view [2]. In the base view, `relative_factor` is wrapped inside a `<div>` with a shared label (`Quantity`). Since the new field is inserted inside this structure, it inherits the same layout without having its own label, resulting in the label being hidden. **Fix:** This commit updates the view to ensure that the field `l10n_co_edi_ubl` is properly displayed with its own label, avoiding UI confusion and improving form clarity. **After:** <img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" /> [1]: https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13 [2]: https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34 opw-6180769 Forward-Port-Of: odoo/enterprise#115933
This update fixes an issue where users could still edit protected folders within the company's main document area. The change ensures that editable forms are automatically set to read-only when a protected folder is accessed, maintaining data integrity and preventing unauthorized modifications. This resolves a potential risk of incorrect data being saved.
Original PR description
In odoo/enterprise#106192, we have modified the function userPermissionViewOnly that was preventing the user from editing document he cannot: we have removed the condition preventing user to edit…
In odoo/enterprise#106192, we have modified the function userPermissionViewOnly that was preventing the user from editing document he cannot: we have removed the condition preventing user to edit protected document (mainly folder at the company root). That was an error as even if the user has "edit" access (which is ensured in that method), the document can still be protected and the form to edit it should be in readonly then. We ensure here that the form in the details panel is in readonly in that case. How to reproduce: - log as demo and go to Document - Click on Inbox folder - Open details panel - Change for example the contact of the document You get an error while you shouldn't be able to edit it (as the folder is protected). Technical note: we re-add the condition in the method userPermissionViewOnly: (!this.documentService.userIsDocumentManager && this.record.data?.user_folder_id === "COMPANY") that we slightly modify to limit the protected document to folder only: (!this.documentService.userIsDocumentManager && this.record.data?.user_folder_id === "COMPANY" && this.record.data?.type === "folder") Task-5881531 Forward-Port-Of: odoo/enterprise#116709
This update fixes an issue where the 'Import Records' option was missing from the Journals list view. The change was caused by a technical setting that incorrectly prevented the import framework from recognizing the view's import capabilities. Now users can import journals directly from the list view.
Original PR description
**Steps to reproduce:** * Go to Accounting App. * Open the Journals list view (Configuration > Accounting > Journals). * Click on the "Action" (cog) menu. **Observed behavior:** * The "Import…
**Steps to reproduce:**
* Go to Accounting App.
* Open the Journals list view (Configuration > Accounting > Journals).
* Click on the "Action" (cog) menu.
**Observed behavior:**
* The "Import records" option is completely missing.
**Cause:**
* In [commit](https://github.com/odoo/odoo/commit/082c70e6d411afd28efffbaf437d8b56d8351e38), `create="False"` was added to the `account.journal` list view to hide the "New" button, intentionally redirecting users to use the journal creation wizard instead.
* However, Odoo's standard `base_import` framework evaluates the XML architecture of the view (`config.viewArch.getAttribute("create")`). Because `create="False"` was set on the view, the framework automatically hid the `Import records` action menu item, assuming importing was entirely restricted.
**Fix:**
* Remove `create="False"` from the XML view architecture so the `base_import` framework evaluates it correctly and displays the "Import records" action.
* Introduce a custom `js_class` (`account_journal_list`) for the journal list view. By explicitly setting `this.activeActions.create = false` inside the controller's `setup()` lifecycle method, we can safely hide the inline "New" button on the UI layer without interfering with the backend XML architecture evaluation.
Ticket [link](https://www.odoo.com/odoo/project.task/6132990)
opw-6132990
Forward-Port-Of: odoo/odoo#260561This update resolves an issue preventing sales team members from opening milestones linked to sales orders. The fix uses a temporary workaround to grant necessary access, allowing users to properly manage project milestones. This ensures sales teams can effectively utilize milestone-based project creation.
Original PR description
Steps to reproduce: - Install the sale_project module - Create a sale order based on milestones - Create the project from the order - Open the project, click the three dots, and open a milestone Issue: Users are unable to open milestones and get an access error. Cause: Users in `sales_team.group_sale_salesman` lack read access to the related `sale.order.line`, causing an AccessError when `sale_line_id` is accessed during the computation of `product_uom_qty`. Fix: Compute `product_uom_qty` using `sudo()` to bypass record rule restrictions. task-5477304 Forward-Port-Of: odoo/odoo#263331 Forward-Port-Of: odoo/odoo#245392
This update resolves a bug in the HTML editor where inserting `/code` into a list would prevent the cursor from correctly positioning within the newly created code block. The fix eliminates the creation of an unnecessary empty text node during the shortcut process, ensuring accurate cursor placement and functionality.
Original PR description
#### Description of the issue this PR addresses: - In shortcut plugin, extractContent leaves an empty text node at block start - When converting to a code block, that invisible node is removed, so the editor cannot restore the cursor correctly #### Desired behavior after PR is merged: - Delete the selection directly instead of extracting text - This prevents creating the invisible empty node #### Steps to reproduce: - Type `1. ` to create a list - Immediately insert `/code` - Cursor does not move inside the code block task-6169180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263517 Forward-Port-Of: odoo/odoo#261799
This update resolves an issue where sponsor logos on event pages were broken due to incorrect image URLs being generated. The fix limits the image options used to ensure only available sizes are included, guaranteeing sponsor logos display properly for all users. This improves the visual presentation of event sponsorships.
Original PR description
Problem: Sponsor logos were broken on the event sponsor footer cards after https://github.com/odoo/odoo/commit/36e680feca4884940e020119de6a13cd7f927516, even when `image_128` / `image_512` were set. The QWeb image widget generated a `srcset` including larger sizes (`image_1024`, `image_1920`) that do not exist on `event.sponsor`, allowing browsers to pick invalid URLs. Cause: The template renders `sponsor.image_128` with the generic image widget, which auto-generates a `srcset` from the image family. Without restricting it, larger nonexistent variants are included. Solution: Set `t-options` with `"preview_image": "image_128"` in the sponsor footer template to limit `srcset` to existing variant and ensure valid image URL is selected. Task-6079695 Forward-Port-Of: odoo/odoo#257461
This update optimizes how the system removes old device log entries, preventing performance slowdowns. By filtering records based on the last cron run, the database only needs to process relevant data, reducing the load on the system. This results in faster cleanup and improved overall system performance.
Original PR description
The current query to delete unnecessary records from `res.device.log` must be run on all records in the table. This means that the entire table will be placed in the psql buffer. This can degrade…
The current query to delete unnecessary records from `res.device.log` must be run on all records in the table.
This means that the entire table will be placed in the psql buffer. This can degrade performance if autovacuum is very frequent.
This commit introduces a fix so that a seq scan does not have to be performed on the table to carry out the cleanup.
We can use an `USING` if the condition on the joined table (L2) significantly reduces the volume before the join.
This will avoid having the corresponding rows from the first table (L1).
Pseudo query:
```sql
DELETE FROM L1
USING L2
WHERE
<L2_selective_filter>
AND L1.<device> = L2.<device>
AND L1.last_activity < L2.last_activity
```
If `<L2_selective_filter>` is very selective, PostgreSQL will use L2 as the "base" table for the join.
PostgreSQL will therefore not place the entire table in the buffer.
With:
```
d: device
c: cron
t: time
```
```
d t1 - insert
d t2 - insert
d t3 - insert
c t4 - cleanup (delete d t1 and d t2)
d t3
d t5 - insert
d t6 - insert
c t7 - cleanup (delete d t3 and d t5)
d t6
d t8 - insert
c t9 - cleanup (delete d t6)
d t8
c t10 - cleanup
d t8
...
```
In the example, cron t9 cannot look at the time window between the moment it runs and the last cron t7. The proof is that the device inserted in t6 must be deleted because a device t8 has been inserted.
It is not possible to cleanup between two crons because older lines can still be deleted by a later cron if a more recent line has been inserted after the previous cron.
So if a device is inserted between the time of the current cron (t0) and the previous cron (t-x), it is necessary to scan the entire table to cleanup the previous devices.
Therefore, it is possible to create a filter so that devices for which there has been no new insertion in the table between the two crons (t0 and t-x) do not need to be checked.
Pseudo query becomes:
```sql
DELETE FROM L1
USING L2
WHERE
L2.last_activity >= <last_cron_time>
AND L1.<device> = L2.<device>
AND L1.last_activity < L2.last_activity
```
Task-5951999
Forward-Port-Of: odoo/odoo#263625
Forward-Port-Of: odoo/odoo#249738This update fixes an issue where interactive tours were incorrectly triggered when the POS was loaded, causing errors. We've added a flag to the tour to prevent triggering if the necessary tour steps aren't available, ensuring a smoother POS experience for users. This improves stability and reduces potential errors.
Original PR description
When loading the POS, interactive tours were triggered but their steps were not included in the POS bundle. This caused a traceback each time the POS was opened or refreshed. To prevent this, we added a flag `onHold` onto the tour if no steps were found from the database and the registry wasn't loaded. --- Task: https://www.odoo.com/odoo/project/1737/tasks/605029 Forward-Port-Of: odoo/odoo#262812 Forward-Port-Of: odoo/odoo#255094
This update fixes an issue where quiz answers weren't updating correctly after saving. Previously, a full page reload was required to see the changes. The fix restores a necessary field to ensure the web client accurately reflects updated answer data, improving the quiz experience.
Original PR description
After adding new answers or editing existing ones in a quiz question and clicking 'Save & Close', the question overview displays incorrect data. New answers appear as empty tags, and modified answers continue to show their old values. The correct data only appears after a full page reload. This regression was introduced in commit 8ceea093, where invisible fields were removed during code cleanup. The `display_name` field is required in the `answer_ids` list view for the web client to correctly update its local cache. Without this field, the client cannot refresh the display names of the tags immediately after modification. This commit restores the `display_name` field as `column_invisible` in the `slide.question` form view. Task-5449335 Forward-Port-Of: odoo/odoo#244460
This update resolves an issue where newly created analytic distribution records would disappear after a page reload. The fix ensures the widget's data is properly synchronized with the database, preventing data loss when updating distribution settings. This improves data reliability and reduces the risk of lost configurations.
Original PR description
Steps to reproduce 1. Go to Accounting → Configuration → Analytic Distribution Models 2. Create a new model, name it, and in the distribution column pick an analytic account 3. Click outside the row…
Steps to reproduce 1. Go to Accounting → Configuration → Analytic Distribution Models 2. Create a new model, name it, and in the distribution column pick an analytic account 3. Click outside the row and reload the page Issue The newly created record vanishes because `web_save` received `analytic_distribution: false`. The single click that closes the popover also triggers the editable list's `leaveEditMode`, which calls `record.save()`. That save runs before the widget has flushed the user's pick into `record.data`, so the write goes out with stale/empty data. This became reliably reproducible after [37d78a47bb20], which moved the list renderer's outside-click listener from `document` (bubble) to `window` (capture). Because the list is mounted before the widget, its capture-phase listener now fires first: `leaveEditMode` → `record.save()` is already in flight by the time the widget's own window click handler runs, so the widget's commit loses the race. Solution `record.save()` awaits `_askChanges()` before writing: https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/addons/web/static/src/model/relational_model/record.js#L268-L271 `_askChanges()` triggers `NEED_LOCAL_CHANGES` on the model bus and awaits any proms handlers push onto it: https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/addons/web/static/src/model/relational_model/relational_model.js#L249-L253 This is the framework's standard hook for widgets that hold uncommitted local state; `ace_field` and `domain_field` already use it. Subscribe the analytic distribution widget to the same event and, when the dropdown is open, push a `commitChanges()` prom that awaits the existing `save()`. Because `record.save()` awaits these proms before running `_save`, the widget's pending distribution is guaranteed to be on `record.data` by the time the write payload is built, regardless of click-listener ordering. opw-6106309 Forward-Port-Of: odoo/odoo#260421
This update corrects a technical issue where partners with VAT information were incorrectly flagged in the annual VAT listing warning. The change ensures that only partners with genuine VAT obligations appear in this report, improving data accuracy and reducing potential user confusion. This resolves a minor reporting concern.
Original PR description
Partners with / in VAT shouldn't be displayed in the warning for the annual VAT listing. task-6081162 Forward-Port-Of: odoo/enterprise#113839
A recent update caused the onboarding plan wizard to open without displaying the expected plan badges. This issue stemmed from a change that removed crucial context information. This fix restores the correct display of badges, ensuring users see all available onboarding plans as intended.
Original PR description
Steps to reproduce: 1- Install Employees app 2- Open the app and select any employee 3- In the chatter, click the onboarding plan link Issue: Starting from version 18.4 and onwards, clicking the link opens the 'Launch Plan' wizard without the Offboarding/Onboarding plans Expected behavior: The wizard should contain the plan Badges just like in previous versions or when clicking the 'Activity' button in the chatter Why this happens: One of the changes in the commit ef34950 was removing the following line: `context.params = state` The `state` included the `active_model` value which was passed in the url. As a result, `res_model` attribute in the model 'mail_activity_schedule' is `false`. The `_compute_plan_available_ids` will then return an empty list. So the consequent call which gets the available plans to display as a Badge will not be made. opw-6074918 Forward-Port-Of: odoo/odoo#258349
This update resolves an issue where users were sometimes redirected to archived contract versions after signing an offer multiple times. The fix prioritizes active contract versions during the 'Signed Contract' button search, ensuring users always access the correct, current contract information. This improves the user experience and prevents incorrect contract access.
Original PR description
Steps to reproduce: 1- Create an offer for an applicant 2- Sign the offer as an applicant multiple times 3- Counter sign only one of them 4- Click on the "Signed Contract" smart button Issue: In some cases, the smart button will redirect to an archived version. Cause: The search for the version allows for archived versions and has a limit of 1, so sometimes that 1 version turns out to be one of the signed contracts that weren't counter signed. Fix: Add a sort to the search to prioritize active versions. Task-6144381 Forward-Port-Of: odoo/enterprise#116885 Forward-Port-Of: odoo/enterprise#115505
This update resolves a visual glitch in the knowledge article editor where the table of contents would incorrectly display the TOC of the previously viewed article. The fix ensures the TOC accurately reflects the current article's structure, improving the user experience when creating and editing knowledge content. This prevents confusion and ensures consistent article navigation.
Original PR description
### Steps to reproduce 1. Open knowledge 2. Create a new empty article 3. Click on Templates 4. Close the modal ------> Current article's side panel TOC shows the TOC of the previewed article. ### Technical The side panel's TOC is managed by the TOC service. When opening/updating any article, the side panel's TOC is updated according to the current article. When the article picker is previewing the article using the `HtmlViewer`, it also updates the side panel's TOC using the previewed article. Then if we close the dialog without loading the article, the side panel's TOC doesn't get updated. Therefore, opening the side panel's TOC shows the last previewed article's TOC. After this commit, we add a cleanup inside the `HtmlViewer` and the `KnowledgeTableOfContent` to restore the previous TOC manager when it is destroyed. Task-6186675 Forward-Port-Of: odoo/enterprise#116615
This update fixes an issue where changing the delivery date for Hungarian invoices incorrectly recalculated journal entries, leading to financial discrepancies. The fix ensures that the correct exchange rate is applied when the delivery date is modified, maintaining accurate accounting records. This improves the reliability of financial reporting for Hungarian transactions.
Original PR description
### Issue: When changing the delivery date (used as the Hungarian exchange rate date), some journal lines could be recomputed incorrectly, leading to unbalanced entries ### Cause:…
### Issue: When changing the delivery date (used as the Hungarian exchange rate date), some journal lines could be recomputed incorrectly, leading to unbalanced entries ### Cause: `expected_currency_rate` was recomputed when `delivery_date` changed, but the new value was never automatically applied In addition, after https://github.com/odoo/odoo/pull/225407, `_sync_tax_lines` partially updated the lines: https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L3029-L3031 https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L1633-L1637 These methods reapply the previous tax rate, causing base and tax lines to be updated inconsistently As a result, when the base amount increases, the tax amount decreases, and vice versa ### Steps to reproduce: - Install `l10n_hu_edi` and `accountant` with demo data, then switch to the `HU company` - Go to Currencies → USD and add two rates: April 5: HUF per Unit = 100 April 6: HUF per Unit = 150 - Create an Invoice: (Any customer, Currency: USD, Line: Price = 1000, Tax = 27%) - Open the Journal Items and duplicate the browser tab for comparison - In the duplicated tab, change the Delivery Date to April 5 and save - Change the Delivery Date back to today and compare both tabs ### Before the fix: The values differ between both tabs because the tax lines keeps the old exchange rate opw-5801126 Forward-Port-Of: odoo/odoo#263694 Forward-Port-Of: odoo/odoo#258310
This update fixes several issues within the spreadsheet component, ensuring a smoother and more reliable experience for users. The changes include improvements to the installation process and addressing permissions related to OpenID Connect. This ensures the spreadsheet functionality continues to operate correctly within Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/14395f75f1 [REL] 19.3.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/14395f75f1 [REL] 19.3.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/62a64fd1b4 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/38b1f8ca83 [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e5d20dd4ff [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/33f3342c49 [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/a22b83d2ed [FIX] composer: remove forced reflow in content editable [Task: 6199661](https://www.odoo.com/odoo/2328/tasks/6199661) 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 resolves an issue that occurred when users attempted to merge a single mailing list. The fix addresses a technical error related to empty recordsets, preventing a syntax error and ensuring the merge function operates correctly.
Original PR description
Currently, error occurs when user tries to merge a mailing list. Steps to replicate: - Install `mass_mailing`. - Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view. - Select…
Currently, error occurs when user tries to merge a mailing list.
Steps to replicate:
- Install `mass_mailing`.
- Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view.
- Select a single record and Click merge.
Error:
```
psycopg2.errors.SyntaxError: syntax error at or near ")"
LINE 8: AND src_sub.list_id IN ()
^
ValueError: SyntaxError('syntax error at or near ")"\nLINE 8: 'AND src_sub.list_id IN ()\n'
^\n') while evaluating 'action = records.action_mailing_lists_merge()'
```
Cause:
- Error occurs due to a recent [PR].
- When the user selects only a single record, `self - dest` [1] evaluates to an empty recordset. As a result, `action_merge()` receives an empty `src_lists`.
- Later, this is used [here] and converted into an empty tuple, producing an invalid SQL clause like `src_sub.list_id IN ()`, which leads to this error.
Solution:
- When `src_lists` is an empty recordset, we early return from `action_merge()`.
[PR]: https://github.com/odoo/odoo/pull/72156
[1]: https://github.com/odoo/odoo/blob/4193b3735d64518290613f5c8132f1fd07afa229/addons/mass_mailing/models/mailing_list.py#L218
[here]: https://github.com/odoo/odoo/blob/4193b3735d64518290613f5c8132f1fd07afa229/addons/mass_mailing/models/mailing_list.py#L266
sentry-7447326420
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262404This update fixes a bug in the bank reconciliation process that prevented users from correctly selecting multiple lines for actions. The change ensures accurate filtering and comparison of related records, improving the reliability of this key financial function. This resolves an issue where the system wasn't properly handling multiple selections.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/fa8fedc4e2501a273e7f8f3f7f4462b2b58907b9 We introduce a way for user to select multiple lines and perform an action out of it. In the dropdown, there should be an intersection of all reco model of the selected lines but it wasn't working properly in two cases: - When only one selected lines, remainingRecoModels was empty and the filter was filtering everything, added a early return for that - When multiple lines, we compare the first list of reco model with all the others but we compare object which is not working in js. Now we will compare the id. no task id Forward-Port-Of: odoo/enterprise#115770
This update adjusts the default date range for the Lead and Pipeline dashboards to 'Last 30 days'. This change ensures users consistently see the most recent data, providing a clearer and more relevant view of sales performance. It resolves a previous issue where the default date range was not clearly defined.
Original PR description
This commmit fixes the date filter default value to `Last 30 days`. Task: 5902231 Forward-Port-Of: odoo/enterprise#114560
This update resolves a visual glitch where the status bar appeared twice for sub-tasks. The fix ensures that the status bar accurately reflects the task's project association, preventing a confusing and inconsistent user experience. This change improves the overall usability of the project management tool.
Original PR description
Steps: - Create a task inside any project. - Create a sub-task under that parent task. - Open the sub-task and remove the project (clear the project field). - Look at the status bar at the top of the form view. Issue: - The status bar is displayed twice (both the Project stages and Personal stages - are visible simultaneously). Cause: - When the project field is cleared from a sub-task in the UI, conflicting visibility rules or residual stage data can cause the status bar widget to render twice. Fix: - To resolve this, an `onchange` event is added to the `project_id` field. If the user removes the project from a sub-task, the system now instantly falls back to the parent task's project and sets `display_in_project = False`. This syncs the frontend UI with the intended backend behavior, preventing the interface from entering the broken state and removing the duplicate status bars. task-6033970 Forward-Port-Of: odoo/odoo#255319
A recent update caused shifts created from the Gantt day view to be incorrectly delayed by an hour. This was due to a change in how timezone information was handled. This fix ensures that shift times are accurately reflected, resolving this scheduling issue.
Original PR description
Steps to reproduce:
-
- Open Planning
- Switch to Gantt day view
- Select a time slot from 1 PM to 3 PM for a resource
Issue:
-
- When creating a planning shift from the Gantt day view, the created shift has a 1 hour time lag compared to the selected slot.
Cause:
-
- In saas-19.2, the timezone field was removed from the resource calendar.
- _work_intervals_batch was called without resources_per_tz, causing it to default to {UTC: resource} instead of the correct resource timezone.
Solution:
-
- Pass the resource timezone when calling _work_intervals_batch so attendance times are stamped with the correct resource timezone instead of defaulting to UTC.
task-5966733
Forward-Port-Of: odoo/enterprise#111122This update resolves an error in the FAIA report XML export for Luxembourg customers. The issue stemmed from a missing 'TVA' TaxType element, as required by Luxembourg tax regulations. This fix ensures accurate report generation and compliance.
Original PR description
This is one of several commits fixing the FAIA xml export. The customer in ticket [opw-5427296](https://www.odoo.com/odoo/unassigned-tasks/5427296) received several errors which mention that the `TaxType` element should be 'TVA'. This is corroborated by one of these elements in the XSD files for the FAIA report. The XSD files can be found at the link below. https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-6118272 [link](https://www.odoo.com/odoo/project.task/6118272) *For future techs or functional support agents: updating `l10n_lu_reports` may not automatically apply the fix. You may need to go to the relevant Views model and select ⚙️ > Compare/Reset, then Hard Reset.* Forward-Port-Of: odoo/enterprise#116344 Forward-Port-Of: odoo/enterprise#113720
This update fixes an issue where users were incorrectly directed to a standard form view when opening documents linked through Studio. Now, when accessing documents from Many2One fields, the system opens the appropriate Kanban or List view, allowing users to directly preview and navigate the document content.
Original PR description
Problem: When opening a linked `documents.document` record from a Many2One field added via Studio, the user is redirected to the standard form view. This is problematic because the form view does not allow the user to preview the actual document or navigate into it if the record is a folder. Solution: override `get_formview_action` to open the Kanban/List/Activity views. task-6068437 Forward-Port-Of: odoo/enterprise#116675 Forward-Port-Of: odoo/enterprise#113149
This update resolves a test failure in the MRP module related to how manufacturing routes are configured. The fix ensures that the test setup correctly identifies and utilizes available routes, preventing errors when running tests in environments without demo data. This improves the reliability of our manufacturing test suite.
Original PR description
The setup in `TestMultistepManufacturingWarehouse` was failing with: ``` AssertionError: field 'route_ids' is not visible ``` This happens because the `route_ids` field on the product form view is only visible when `has_available_route_ids` is True, which depends on having at least one `product_selectable` route. This commit enables `product_selectable` on those routes in the test setup, so that `route_ids` becomes visible and the Form helper can access it safely. [RB-232576](https://runbot.odoo.com/odoo/error/232576) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259036 Forward-Port-Of: odoo/odoo#237293
This update resolves an issue where the correct fiscal position (Domestic) wasn't being applied for sales within the EU. The change ensures that VAT prefixes are properly considered, leading to accurate sales reporting and compliance with VAT regulations, particularly for intra-EU B2B transactions. This fix impacts how VAT is calculated and processed for sales orders.
Original PR description
With l10n_nl: - Set the fiscal positions in this order: 1. Domestic 2. EU Intra B2B - Create a contact with: - German address - Dutch delivery address - Dutch VAT - Create a second contact with: - German address - Dutch delivery address - No VAT - Create a Sales Order for each contact: - For the first contact, the applied fiscal position is EU Intra B2B - For the second contact, the applied fiscal position is Domestic The detected fiscal position should be Domestic in both cases In _get_fiscal_position vat_exclusion is computed using the VAT prefix of the partner and our company. But if the prefix of the VAT does not match the country of the partner, it's delivery address will still be overriden. opw-5892138 Forward-Port-Of: odoo/odoo#258899
This update fixes an issue where purchase order lines didn't correctly display the associated analytic distribution when a project was assigned. The fix ensures that the product's original analytic distribution, along with the project's, is consistently shown on new order lines. This improves accuracy in tracking costs by project.
Original PR description
__ ## Short functional explanation of the error When creating a Purchase Order. We add a line containing a product that has an analytic distribution. After setting a project on this PO, when we add…
__ ## Short functional explanation of the error When creating a Purchase Order. We add a line containing a product that has an analytic distribution. After setting a project on this PO, when we add another line containing the same product, the analytic distribution of the product isn't added anymore, only leaving it with the analytic distribution of the project. ## Reproduction Steps 1. Go to settings and enable Analytic Accounting. 2. Go to Accounting > Configuration > Analytic Distribution model. Create a model with a product (prd) you remember, and add an analytic distribution (ad). 3. Go to Project. On a given project (p), select the Hamburger menu and click Settings. Then, in the Settings tab, under Analytic, make sure the Project field is filled. 4. Create a new Purchase Order. Select a vendor and add a line with the product (prd). On the top right of the Form, click on the view button and select Analytic Distribution to show it on the form. There, we should see the product (prd) with its corresponding Analytic Distribution (ad) on the form. 5. Click on the Other Information tab and select the project (p). Click on the Product tab. There, under Analytic Distribution field, you should see (ad) and the Analytic Distribution of the project (p). 6. Click on save and add another line with the exact same product. ### Expected behavior Under Analytic Distribution, we should see (ad) and the Analytic Distribution of the project (p), as for the first order line ### Unexpected behavior Under Analytic Distribution, we only see the Analytic Distribution of the project (p). ## Origin of the issue When we add another line, we trigger the compute method of the Analytic Distribution. However, due to this piece of code: https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/project_purchase/models/purchase_order_line.py#L14 when we create a new order line, we never compute its analytic distribution: `self` will contain only `project_lines`, and `empty_project_lines` is empty as well. Therefore, we call the super method with nothing, so when we get in the super method: https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/purchase/models/purchase_order_line.py#L249-L259 we never compute the analytic distribution of the newly created line. This piece of code was added in this commit: https://github.com/odoo/odoo/commit/c1ea8446259bd3338c004e88d48ad77ded7ef2ae to fix the issue that when a user enters manually an analytic distribution, this entry will be lost when triggering the compute of the analytic distribution. However, due to the agency of the code, we cannot prevent losing *both* manually added analytic distributions and product analytic distribution. After consulting the product owner, we concluded that there was no perfect solution in this case, but we'd rather keep the product analytic distribution, as it is much harder to add it again after its removal. Therefore, this commit reverts the previously mentioned commit, while keeping the refactor it introduced. __ opw-6063418 Forward-Port-Of: odoo/odoo#257558
This update resolves a technical issue preventing on-the-fly product creation in the SOL editable form test. Specifically, the system was failing a test due to an incorrect initial value for 'reinvoice_policy'. The fix ensures this field is correctly initialized with its default value ('no') during product creation, preventing errors and ensuring data integrity.
Original PR description
When creating an on-the-fly product in the SOL editable form test,
reinvoice_policy was not initialized to its default value ('no') on the
transient record created with `new()`.
This happens because `new()` only initializes defaults for fields needed
by the current form view (required fields, modifiers, onchanges, etc.),
and reinvoice_policy is not part of them in this flow.
Also Since `product_id.reinvoice_policy` is also not a dependency of
`qty_delivered_method`, the compute keeps using the incorrect initial
value, causing the readonly assertion on `qty_delivered` to fail.
Fix by explicitly passing the reinvoice_policy's default value in the product
creation values.
runbot error-239939
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#263042This update significantly reduces memory usage during the installation of the stock account module, particularly in large databases. By disabling prefetching, the module now uses 55% less memory, preventing potential performance issues. The change resulted in a slight (10%) increase in installation time, which is considered an acceptable tradeoff.
Original PR description
## The Problem During the initialization of `stock_account`, the logic creating `product.value` instances triggered cache misses on `product.product`, accessing fields (`company_id` and…
## The Problem During the initialization of `stock_account`, the logic creating `product.value` instances triggered cache misses on `product.product`, accessing fields (`company_id` and `standard_price`) inside `_create_product_value`, and field `uom_id` inside `_run_fifo_get_stack`. Due to prefetching, this loaded all product data into memory, causing significant memory usage on large databases. ## The Solution Disabled prefetching in the full flow. Didn't go with fetching only the needed fields instead of disabling for two main reasons: - Field `standard_price` accessed in the loop is company dependent, so it needs to be fetched inside, which would be a bit verbose. - Fetching `company_id` outside the loop, `standard_price` inside the loop, and `uom_id` which is accessed down the stack in the `.create` call on `product.value` won't be an explicit/robust solution for the long term. --- ## Benchmarks *Tested on a SaaS database with 500k products:* | | Before | After | Note | | :--- | :--- | :--- | :--- | | **Memory** | 3.6GB | 1.6GB | **-55%** (fits in memory limit) | | **Time** | 10m | 11m | **+10%** (acceptable tradeoff) | **OPW-6173153** Forward-Port-Of: odoo/odoo#262702
This update corrects a misleading validation error that appeared when using the translation button on Sale Order Templates, particularly in multi-language setups. The fix ensures the system correctly handles nested records, preventing unnecessary error messages and improving the user experience. This resolves a previous issue impacting template creation.
Original PR description
Steps to reproduce: * Enable multiple languages * Go to Sale Order Templates and create a new template * Add a product line, then click the translate button on the description field * A confusing…
Steps to reproduce: * Enable multiple languages * Go to Sale Order Templates and create a new template * Add a product line, then click the translate button on the description field * A confusing validation error appears for missing `sale_order_template_id` Issue: * Instead of highlighting the missing required fields on the sale order template form view, it raises a misleading validation error on `sale_order_template_id` Cause: * `useTranslationDialog` always attempts to save the passed record directly. In O2M list views, the field can belong to a nested relational record, so the correct behavior is to save the root record instead. Affected Version: 17.0 Before: <img width="1919" height="1014" alt="image" src="https://github.com/user-attachments/assets/cd61381d-289a-4df4-bdf2-7881fa851939" /> After: <img width="1920" height="887" alt="image" src="https://github.com/user-attachments/assets/5218c74b-c024-4994-b816-cb7ae69b420f" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262988 Forward-Port-Of: odoo/odoo#262755
This change corrects a bug where the gross salary line was missing from the salary configurator when the user interface was set to a non-English language (like French). The fix ensures that the gross salary is always displayed, regardless of the selected language, by updating how the system generates salary categories.
Original PR description
**Problem:** On a Belgian company with the UI set to French (or any non English language), the gross line never appears in the salary configurator sidebar when opening an offer. **Steps to…
**Problem:**
On a Belgian company with the UI set to French (or any non English language), the gross line never appears in the salary configurator sidebar when opening an offer.
**Steps to reproduce:**
1. Create a Belgian company.
2. Install French and set the admin user to French.
3. Go to an applicant (e.g Laurie Poiret), create a salary offer, save.
4. Open the offer link (salary configurator).
**Cause:**
The base `_get_compute_results` uses the translated `category_id.name` ("Salaire mensuel" in french) as the dictionary key when writing entries into `resume_lines_mapped`. The payroll override function `_get_period_name`, which for monthly schedules returned the hard coded english string `"Monthly Salary"` instead of the translated category name. This caused a key mismatch: the gross line was stored under the translated key, while the override rebuilt `resume_categories` with the english key so when the template iterates over categories and looks up `lines[category]`, the whole "Monthly Salary" bucket was invisible in every non english language.
**Solution:**
We should now return the `category_id.name` directly (the translated name coming from the record itself). This keeps all keys consistent between `resume_categories` and `resume_lines_mapped` regardless of the language used.
also because in https://github.com/odoo/enterprise/blob/1845042ff388593c4cdf547d47c018f42bd02c7c/l10n_be_hr_contract_salary/controllers/main.py#L450
We use `resume = result['resume_lines_mapped']['Monthly Salary']`
We need to re-design this by using the actual translated names, and building `result` keys based on the language selected (the same should be applied for "Yearly benefits").
opw-6009711
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/enterprise#116657
Forward-Port-Of: odoo/enterprise#110676This update resolves a technical error that was preventing the MRP Kanban module from functioning correctly. The change ensures that JavaScript code related to the Kanban interface is properly defined, improving overall system stability and performance. This fix addresses a reported runbot error and ensures consistent operation.
Original PR description
js_class defined in mrp_workorder should have been defined in mrp. This solves runbot error 242288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical issue within the MRP Work Order Kanban module, resolving a run-time error. The fix ensures that JavaScript classes are correctly defined, improving the overall stability and performance of the Kanban interface. This change addresses a reported bug and enhances the user experience.
Original PR description
js_class defined in mrp_workorder should have been defined in mrp. This solves runbot error 242288
This update corrects a bug where the 'Ledger' group was incorrectly displayed in multi-company reports. Previously, when multiple companies were selected, the report only considered the active one. Now, the report correctly uses the selected companies based on the 'companies' option, ensuring accurate reporting across different business entities.
Original PR description
The "Ledger" horizontal group is (among other possible criteria) supposed to be displayed when there is more than one company considered by the report. Before this commit, when opening a report with filter_multi_company set to 'tax_units' with more than one non-branch company in self.env.companies and no tax unit set, "Ledger" was shown. This was wrong, since, in this case, the report will only consider the active company, disregarding the other selected ones. All in all, _init_options functions should only rely on options['companies'] to check the active companies, for consistency.
This update resolves an issue where users experienced an error when accessing the sitemap after installing the website. The fix corrects a code error that resulted in the system incorrectly handling the sitemap attachment, ensuring smoother website functionality.
Original PR description
Currently an exception is generated when the user tries to open the `/sitemap.xml` page twice after installing the website. Error: ``` Error on request: Traceback (most recent call last): ``` This is because the code line [1] tries to access the site map twice; code line [1] gets the `raw` from the existing sitemap attachment, and the contains the `LocalBinaryFile` object due to recent changes with [2]. This commit will fix the above issue by using `sitemap.raw.content` instead of `sitemap.raw` which returns the actual content from the sitemap attachment, instead of `LocalBinaryFile` object instead. [1]: https://github.com/odoo/odoo/blob/93b39025009c80ead3337738443fed7df5b6f51e/addons/website/controllers/main.py#L323 [2]: https://github.com/odoo/odoo/commit/41fe2ebdb9cc37341362d7af829c087a5f72f9f1 Sentry-5691330773
This update fixes an issue where product variants added through the product matrix on purchase orders weren't showing the correct product descriptions. The change restores a previous helper function to ensure product descriptions, including attribute values, are displayed accurately. This improves the clarity and usability of purchase orders.
Original PR description
From 7e553d25890d1, the `product_label_section_and_note_field` has been split into a mixin in `product` and an override in `account`. In this split. the `get label()` helper has been slightly modified in a way the product template is not extracted from the label to keep only the additional description (usually filled with product attribute values). This lead to having only the product template name displayed on the purchase order line if the product variant was added via the matrix widget. This commit brings back the old `label` helper only for the product matrix widget. Task: 6042382 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#262735
A recent issue caused the first line of product descriptions in quotation templates to be cut off when creating sales orders. This update adds a test to prevent this regression, ensuring that all product descriptions are fully displayed in sales orders. This improves the clarity and accuracy of sales order information.
Original PR description
Issue: --- When using quotation template, the first line of description is always removed. Steps to reproduce: 1- Create a quotation template and add a description to the line. 2- Create a SO from quotation template. As you see the first line of description is removed in SO. Cause: --- This regression is introduced after aba778538c2032a2924f99258c5c75e463296d21 which was done under the assumption that the description always starts with product name. This breaking commit is reverted by: a702a4989fc53ccc43f57213e0db3e62e7b69e8f However it's better to have a test in order to prevent this issue being introduced in the future. opw-6178360 Forward-Port-Of: odoo/odoo#262563
The Point of Sale's category grouping feature has been updated to accurately filter out products designated as 'special' that should not be included in the grouped listings. This change ensures that sales staff see only the relevant product categories, improving the accuracy of sales reports and reducing potential errors.
Original PR description
The group products by category feature in the POS was not filtering out the products marked as special and that should not be displayed. It is now the case by extracting the filtering logic and applying it to the grouped products as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257845
This update fixes an issue where partners sharing the same VAT number but with individual turnovers below €250 were incorrectly excluded from VAT reports. The change groups partners by VAT number and includes them in the report if their combined turnover exceeds the threshold, ensuring accurate reporting for Belgian businesses.
Original PR description
When having different partners with the same vat number and their individual turnover values are less than the threshold they were not included in the partner vat listing report even though if the total turnover for their vat number is above the threshold. This commit handles this case by grouping by vat number and if the total turnover for a vat number is above the threshold then it will be shown in the report with another level beneath it to show the partners having this vat number even if their individual turnovers are below the threshold. task-6133010 Forward-Port-Of: odoo/enterprise#116495 Forward-Port-Of: odoo/enterprise#115251
This update resolves a bug where pressing backspace in the HTML editor, specifically at the button's edge, would cause an error. The fix ensures backspace correctly deletes characters and prevents the crash, improving the editor's stability and user experience.
Original PR description
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the…
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left. **How to reproduce** In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown. **Why the problem happens** 1. Traceback when backspace is pressed `LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash. 2. No deletion of the character to the left of the cursor `DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp. **Fix** 1. Prevent the crash in `LinkPlugin` `LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns. 2. Fix backspace behavior in `DeletePlugin` `deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left. task-6102282 Forward-Port-Of: odoo/odoo#258858
This update resolves an error that occurred when users attempted to mark payslips as paid, specifically when the 'Include Unpaid' option was enabled. The change ensures that the system correctly handles unpaid payslips during this process, preventing a technical error and improving the reliability of the payroll reporting feature.
Original PR description
Currently, an error occurs when a user attempts to mark a payslip as paid. **Steps to Reproduce:** - Install the `hr_payroll` module without demo data. - Go to `Payslips` and click on `New…
Currently, an error occurs when a user attempts to mark a payslip as paid. **Steps to Reproduce:** - Install the `hr_payroll` module without demo data. - Go to `Payslips` and click on `New Off-cycle`. - Create a record > `Compute` > `Validate`, and Pay. - In the wizard, enable `Include Unpaid` and select `CSV` mode. - Click `Mark as Paid`. **Error:** `UnboundLocalError: cannot access local variable 'rows' where it is not associated with a value` The error occurs when a user tries to mark a payslip as paid with Include Unpaid enabled. When the wizard is created from here [1], the default unpaid payslips are empty. In this case, the system assigns an empty set of payslips to process [2].and the rows variable is not defined because there are no payslips to work on, which raises the error [3]. This commit ensures that when the wizard is created, the matched unpaid payslips are passed to the wizard. If the Include Unpaid option is enabled, the unpaid payslips are assigned for processing, similar to [4]. The unpaid payslips cannot be empty, as they always include the currently processed payslip. Also, the rows are redefined for each payslip case and updated accordingly. Therefore, this commit ensures that the rows are created at the end from grouped payments. [1] https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip.py#L792-L809 [2] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L56 [3] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L97 [4]: https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip_run.py#L274-L288 sentry-7436885639 Forward-Port-Of: odoo/enterprise#115090
This update resolves an error that occurred when posting journal entries using accounts shared between companies during an open audit period. The issue stemmed from a permissions problem preventing users in one company from accessing audit status information, which blocked the posting process. This fix ensures accurate reporting across shared accounts.
Original PR description
Posting a journal entry using an account shared between multiple companies during an open audit period raises an AccessError. Steps to reproduce: - Configure an account to be shared between Company A and Company B. - Add Company A and Company B in 'Companies' - In the mapping tab, add a code for each company - In Company A, create a tax audit for a specific fiscal period. - Switch to Company B and keep just Company B selected. - Create and post a journal entry using the shared account within the same date period. Issue: An AccessError is raised when posting the move. The system attempts to check the status of the audit records linked to the shared account, to which the user in Company B does not have read access. opw-5993450 Forward-Port-Of: odoo/enterprise#116912 Forward-Port-Of: odoo/enterprise#115454
This update removes redundant logging messages within the account_edi_ubl_cii module. Previously, similar log entries were repeated multiple times, which didn't provide valuable insights. This change streamlines logging for better clarity and efficiency.
Original PR description
Before this commit, we had repeated logs (n-times if we had similar lines) but this doesn't help too much. To avoid this we decided to remove duplicated messages Task-None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263779
This update fixes an issue where currency rates were incorrectly calculated for VAT reports. Previously, the system used any invoice line, even non-product lines, leading to inaccurate rates. Now, the system prioritizes the first actual product line to ensure correct rate derivation, improving the reliability of VAT reporting.
Original PR description
The currency rate was previously computed using the first invoice line, regardless of its type. This caused incorrect rate calculation when the first line was not a product line (e.g., section, note, or display-only lines). This fix filters invoice_line_ids to use the first actual product line when extracting amount_currency and balance, ensuring that the derived rate reflects a valid monetary line. opw-5208724 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#239920 Forward-Port-Of: odoo/odoo#237535
This update fixes an issue where contacts enrolled in the same courses were incorrectly merged. Now, the system prevents this merge, displaying an error message to the user, ensuring data accuracy and preventing duplicate course information. This improves the reliability of our contact management system.
Original PR description
Expected Behaviour: Contacts enrolled in common courses should not be merged and the merge should fail. Steps to reproduce: 1- Go to one of the courses 2- Add two attendees to the course 3- Go to Contacts App 4- Select the two attendees you added to the course 5- Try merging the two contacts Actual Behaviour before the Fix: Contacts enrolled in common courses are getting merged and the common courses are kept in the destination contact. Behaviour with the Fix: Contacts enrolled in common courses are blocked from being merged and an error message is shown to the user saying that the reason the merge is blocked is a duplicate course. opw-5417223 Forward-Port-Of: odoo/odoo#263196 Forward-Port-Of: odoo/odoo#244500
This update resolves an issue where the 'Add a line' button was unresponsive at the top of mobile grid views (like Timesheets). The fix adjusts how elements are sized on smaller screens, ensuring the button is always clickable. This improves the user experience for mobile users.
Original PR description
**Steps to reproduce** On mobile: - Open a grid view (e.g. Timesheets > All timesheets) - Try to click on "Add a line" for the first employee - Issue: nothing happens. Notice that by scrolling down the list to employees at the bottom, it becomes possible to click on "Add a line". **Cause** `o_grid_cell_overlay` elements (with `h-100`) were taking more than the expected height in mobile, because the `o_grid_section_title` divs only have `position: sticky` on larger viewports. With the default `position: static`, the child element's height was exceeding its parent's height. opw-5853489 Forward-Port-Of: odoo/enterprise#113400
This update resolves a bug that prevented QR codes from being generated correctly during batch invoice sending. Previously, the QR code was calculated for all invoices before the signature was applied, resulting in an empty QR code. Now, the QR code is only generated for each invoice during the batch sending process, ensuring accurate signature application.
Original PR description
Description of the issue/feature this PR addresses: in this PR we aim to fix a bug where the l10n_sa_qr_code_str is not getting computed correctly when batch sending due to the qr_code being prematurely computed and cached before the invoice gets the signature filled. Current behavior before PR: Before this PR when batch sending the qr code was being computed for all the invoices being batch sent before each invoice runs _l10n_sa_generate_unsigned_data to set l10n_sa_invoice_signature which leads to an empty qr code. Desired behavior after PR is merged: after this PR we only compute the qr code for each invoice during sending which ensures that l10n_sa_invoice_signature was set. task-6164686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue preventing the correct display of the employee form within the South Africa (SA) localization of Odoo Enterprise. The fix ensures accurate data presentation and functionality for South African users, improving the overall user experience.
Original PR description
this commit fixes the broken view of employee form in SA localization. task-6205661
This update resolves an issue where setting a maximum package weight in Sendcloud prevented accurate shipping rate calculations. The fix ensures that package splitting is handled correctly, allowing rates to be generated accurately even when package weights exceed the maximum deliverable weight. This improves the reliability of shipping cost estimations.
Original PR description
Issue ----- Putting a max weight on a package type causes getting a rate with Sendcloud to fail. Steps to reproduce ----- - Setup Mondial Relay using Sendcloud - Set a default package type with max…
Issue ----- Putting a max weight on a package type causes getting a rate with Sendcloud to fail. Steps to reproduce ----- - Setup Mondial Relay using Sendcloud - Set a default package type with max weight 2kg - Create a product with a 500g weight - Create a SO with the product - Add delivery - Sendcloud Mondial Relay - Get rate > Impossible to get a rate Cause ----- When retrieving the shipping method to use when retrieving a rate, we use the real weight of the order. https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L67 https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L81 However, when making the rate call, we use the value returned by `_split_shipping` https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L91 which is equal to the maximum weight of the package. This is blocking in some cases, like if - the real weight is 750g - the package max is 2kg - Sendcloud returns a shipping method for [500g;1kg] Asking a rate for this method & a 2kg package will fail (rightfully so). Solution ----- The shipment should be split into packages before retrieving the shipping methods. Otherwise the problem might be the other way around where we retrieve a shipping method for the whole order, only to split it into multiple packages because they don't fit in one. Also, the `shipping_weight` returned by `_split_shipping` should only be different from the order's total weight if it is higher than the maximum deliverable weight. ----- Ticket: opw-5947199 Forward-Port-Of: odoo/enterprise#116415 Forward-Port-Of: odoo/enterprise#108315
This update resolves a bug that prevented price changes in the Blackbox POS module when the user's language used a comma (e.g., European format) instead of a dot as a decimal separator. The fix ensures accurate price calculations regardless of the user's locale, improving the reliability of order pricing.
Original PR description
Before this commit, when changing the price of an orderline with the blackbox installed, if the decimal separator of the user language was not a dot and was used during the price change, the price was not changed. This was due to the fact that we were comparing a string with a number, the string would be implicitly be converted to a number and, when there was a comma for example, it would return a NaN which would cause the discount to not be applied and thus the price to not change. Forward-Port-Of: odoo/enterprise#113341 Forward-Port-Of: odoo/enterprise#113151
This update fixes an issue where purchase orders merged with related sale orders didn't correctly link all associated sales. The change ensures that all linked sale orders are properly connected during the merge process, improving data accuracy and streamlining the purchasing workflow. This resolves a previous bug impacting order tracking and reporting.
Original PR description
### Steps to reproduce: - In the settings Enable: "Multi-Steps Routes" - Unarchive the MTO route - Create a storable product with MTO enabled and a set vendor - Create and confirm two sale orders for…
### Steps to reproduce: - In the settings Enable: "Multi-Steps Routes" - Unarchive the MTO route - Create a storable product with MTO enabled and a set vendor - Create and confirm two sale orders for 1 unit of that product - Go to the purchase order view, select both PO > Actions > Merge RFQs #### > The un-cancelled Purchase order is only linked to one of the 2 SOs ### Cause of the issue: The sale orders linked to a PO in this flow are linked through the stock references: https://github.com/odoo/odoo/blob/fb79136e259e2b56746afda64b2536bddf6755c0/addons/sale_purchase/models/purchase_order.py#L60-L61 https://github.com/odoo/odoo/blob/fb79136e259e2b56746afda64b2536bddf6755c0/addons/sale_purchase_stock/models/purchase_order.py#L14-L15 However, the references of the PO merged to the present one are not merged as well. opw-6150636 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263371 Forward-Port-Of: odoo/odoo#261578
A bug causing spreadsheet image insertion requests to hang and crash due to excessive data loading has been resolved. The fix bypasses the database security filtering process, reducing the amount of data loaded into memory and preventing performance issues with large attachments.
Original PR description
To reproduce: ============= - In a db with a large amount of attachments - Insert an image in a spreadsheet - Observe the request hanging then ending with an error Problem: ======== - `ir.attachment._search` is overridden to apply security rules by building a domain based on public, `res_model`, `res_id` and `create_uid` fields - When no `res_model` restriction is present, the fallback path ORs in `res_model != False`, which matches nearly every attachment in the database - All matching records are then loaded into memory for Python-side access filtering via `_filtered_access`, causing the request to time out and crash with a memory error Solution: ========= - Set `bypass_search_access=True` on the many2many field definition so the ORM skips the `_search` override and relies on the SQL join to restrict returned records opw-6152979 Forward-Port-Of: odoo/enterprise#115766
This update fixes an issue where the HTML editor's undo function sometimes restored the selection to an incorrect position. The fix ensures the selection is properly staged before deletion, guaranteeing accurate restoration during undo operations. This improves the user experience and prevents data inconsistencies.
Original PR description
Problem: In some cases, undo restores the selection to an incorrect position. Cause: The selection state was not staged before the deletion started, leading to an inconsistent selection being restored during undo. Solution: Stage the selection before performing the deletion to ensure it can be restored to the correct position. Steps to reproduce: - Go to To-Do → Create New. - Type something on the first line and press Enter. - Type something on the second line and apply styling to it. - Use the Up arrow key to move to the first line. - Remove a character. - Press Undo (Ctrl + Z). - Observe that the selection and toolbar appear on the second line. task-6142055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262896 Forward-Port-Of: odoo/odoo#260630
This update resolves an issue where the table number on the kitchen display was being cut off when the order title exceeded a certain length. This prevented kitchen staff from quickly identifying the correct table for an order, leading to potential delays. The fix ensures the table number is always visible, improving kitchen efficiency.
Original PR description
**Steps to reproduce:** - Download the German language - Set the restaurant to QR + Ordering - Set the Service at Table, pay after each order - Set the language to German - Go to the Self and order…
**Steps to reproduce:** - Download the German language - Set the restaurant to QR + Ordering - Set the Service at Table, pay after each order - Set the language to German - Go to the Self and order something while the language is German - Chose table 12 - Go to the kitchen display - The title is truncated, meaning we can't see the table number **Why the fix:** If the title is more than 150px it will be truncated and "..." will replace the table number. This has been introduced in ed5b010dc7b5c11bbbc8513c1edb0ec4f58778c1 but not being able to see the table number might be bad as some people would need to spend time trying to figure out which table the order is for, instead of just having to look at the kitchen display. We now revert this change to break to a new line in the case where the card title is too long, so we can always see the table number. Before: <img width="317" height="156" alt="image" src="https://github.com/user-attachments/assets/25e76026-bdad-4639-9dfc-0d75ffa8d8c8" /> Afer: <img width="329" height="174" alt="image" src="https://github.com/user-attachments/assets/f387dd5f-96d3-4148-bc76-215393c76e67" /> opw-6096111 Forward-Port-Of: odoo/enterprise#114859
This update resolves an issue preventing the barcode app from accurately scanning pack-in-pack inventory counts. The fix ensures that the system correctly identifies and updates quantities when scanning nested packages, improving inventory accuracy. This enhancement directly addresses a reported problem during physical inventory counts.
Original PR description
### Steps to reproduce: - In the settings enable "Packages" - Create a storable product A and put 1 unit in a package P in stock - Inventory > Products > Packages > open your package P - Set a parent…
### Steps to reproduce: - In the settings enable "Packages" - Create a storable product A and put 1 unit in a package P in stock - Inventory > Products > Packages > open your package P - Set a parent package PP as container - Inventory > Operations > Adjustments > Physical Inventory - Select you product line for A > Request a count (from the control panel button) - Enable Show Expected Quantity and confirm - Go to the barcode app > Count Inventory (1) - scan your parent package PP #### > traceback: Uncaught Promise > Cannot create property 'inventory_quantity' on boolean 'false' ### Cause of the issue: When the Package scan is processed, we loop over all quants related to it: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L566-L569 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L602-L617 And for each of these we try to find an existing line representing the quant to update or we do create a new line. Now, the issue, is that the subpackages of the quant are not provided to find the quant candidate line to update. As such, no line is found we enter the else clause and try to createa a NewLine: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L617-L627 This time however, the appropriate subpackage (the one of the quant) is provided to the arguments. And, since the line representing this quant is already existing, the `_createNewLine` will return False: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L393-L399 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L423 This leads to a traceback at the end of the else close since `false.inventory_quantity` doe not make sense (Cannot create property 'inventory_quantity' on boolean 'false') https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L626-L627 Fix: We adapt the `_processPackage` of the `BarcodeQuantModel` to mimic the existing 'update' behavior on the `BarcodePickingModel`: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_picking_model.js#L2110-L2133 Note that UOM converstion should not be required since quants are already uniformly expressed in the product uom: https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/stock/models/stock_quant.py#L52-L54 opw-5864591 Forward-Port-Of: odoo/enterprise#116715
This update fixes an issue where credit notes related to returned stock weren't accurately calculating the cost of goods sold (COGS). The fix ensures that the correct price unit (either from the original invoice or the returned stock movement) is used, regardless of how the credit note was created, leading to accurate financial reporting. This impacts inventory valuation and reporting accuracy.
Original PR description
**Steps to reproduce:** Problem A) - create a storable product avco perpetual - add 2 unit in stock and set a cost of 10 - set the invoicing policy as "delivered quantities" - create and confirm a SO…
**Steps to reproduce:** Problem A) - create a storable product avco perpetual - add 2 unit in stock and set a cost of 10 - set the invoicing policy as "delivered quantities" - create and confirm a SO for 2 quantities - validate the delivery - click on "Create Invoice" and confirm the invoice - from the delivery, create and validate a return for 1 unit. - from the product form, change the cost to 15 - from the sale order, click on "Create Invoice" - confirm the Credit Note Problem B) - create a storable product with fifo perpetual - confirm a PO for 1 unit at 10 and validate receive - confirm a PO for 1 unit at 20 and validate receive - confirm a PO for 1 unit at 60 and validate receive - create a SO for 3 unit - deliver 1 unit with backorder - deliver another unit with backorder - deliver the last unit - create and confirm invoice - return the second delivery - from the invoice click on 'credit note' and validate the credit note with a quantity of 1 **Current behavior:** Problem A) the cogs is 25 Problem B) the cogs is 30 **Expected behavior:** Problem A) it should be 10 Problem B) the cogs should be 20 cause the move returned had a value of 20 **Cause of the issue:** Inside \_get\_cogs_value(), if there is an original invoice linked to the credit note we take the unit_price from this invoice. But, if the credit note is not created from the invoice (via the Credit Note button) but via the sale order (via create invoices), the account\_move has no reverse\_entry_id so we won't use the price_unit from the original line. https://github.com/odoo/odoo/blob/686a0cf67bb1e818baf43309fc94f3f0462097ed/addons/stock_account/models/account_move_line.py#L56-L58 So basically what we do for now is: If the credit note was created from invoice we use the unit price from original invoice in all cases. If the credit note was created from sale order we use get\_price\_unit in all cases (which will work for fifo because we'll use the value of the returned move but fail for avco if the standard price has changed cause we use the standard price) https://github.com/odoo/odoo/blob/dccd2256660b1e211707b740074f5fbba95ae149/addons/stock_account/models/stock_move.py#L261-L265 **Fix:** Regardless of how the credit note is created, if it's fifo we use get\_price\_unit to adapt to the value of the moves, if not we use the unit_price from original invoice opw-6097090 Forward-Port-Of: odoo/odoo#259630
This update corrects a display issue where the 'Reconnect Bank' button appeared incorrectly when account online consent wasn't expiring. The fix ensures the button only appears when consent is actually about to expire, preventing unnecessary prompts and improving user experience. This change ensures the system behaves as expected under normal consent scenarios.
Original PR description
Since this commit 375516ccfd20d3a969c532376d0ba9db195b35fd, the reconnect bank button is displayed when the account online link doesn't have consent expiration date, which is wrong, if the consent doesn't expire, we shouldn't display the button. Why this happens? Because we don't check if expiring_synchronization_date is falsy, we only check if expiring_synchronization_due_day <= 0, which is always true in this case, has the compute set 0 as a fallback value. no-task
This update ensures that delivery orders are created correctly when sales orders are cancelled and then settled through the Point of Sale (PoS) system. Previously, products marked as 'delivered' remained on the sale order even when the delivery order was empty. This fix resolves an issue where PoS settlements were not properly reflected in the delivery process, leading to inaccurate inventory tracking.
Original PR description
Steps to reproduce ------------------ 1. Create a sale order with 2 products, confirm it 2. Cancel the SO, then click "Set to Quotation" 3. Open PoS, settle the order and pay 4. Check the delivery…
Steps to reproduce ------------------ 1. Create a sale order with 2 products, confirm it 2. Cancel the SO, then click "Set to Quotation" 3. Open PoS, settle the order and pay 4. Check the delivery order linked to the PoS order The delivery is empty, yet the products still show as "delivered" on the sale order. Why it's happening ------------------ When the SO is cancelled, its moves go to 'cancel' state. After resetting to quotation, those moves stay cancelled. When PoS creates the delivery, the filter in `_create_move_from_pos_order_lines` checks `has_valued_move_ids()` which returns False (all moves are cancelled), and `not move_ids` is also False (cancelled moves still exist). So the lines coming from the SO are excluded from the delivery. The fix ------- We now also create deliveries for lines whose SO moves are all cancelled. These are lines coming from a cancelled SO that now need to be shipped after we have settled their order from PoS. Note ---- The commit c0f338711f028088c98ea459f27c1669b29738d7 fixes this starting from saas-18.2, by introducing a separate `pos_repair` module which simplifies the main `pos_sale` code. In 18.2+, only the test will be forward ported. opw-6055856 Forward-Port-Of: odoo/odoo#263917 Forward-Port-Of: odoo/odoo#256693
This update corrects a technical issue within the l10n_be_hr_payroll module, specifically addressing how loop variables are handled. The change ensures the system operates more reliably and efficiently. This is a routine maintenance fix to improve the stability of the payroll processing.
Original PR description
Don't use `self` in loop body. Oversight of 724edab8d5be8e774f00ae84e9ebeb5a70f4fa93. Forward-Port-Of: odoo/enterprise#116915
This update resolves a bug that caused Purchase Orders to fail when the requested quantity was less than the vendor's minimum order quantity. The fix ensures a valid supplier is always selected, preventing crashes and allowing PO lines to be updated correctly, even with small orders.
Original PR description
FIX] purchase_stock: handle missing seller during PO line update (min_qty) **Steps to Reproduce:** - Install Sale, Inventory, Manufacturing, and Purchase. - Enable MTO, Units of Measure, and Routes.…
FIX] purchase_stock: handle missing seller during PO line update (min_qty)
**Steps to Reproduce:**
- Install Sale, Inventory, Manufacturing, and Purchase.
- Enable MTO, Units of Measure, and Routes.
- Create a product:
Set a vendor price with min_qty = 1.0.
Enable MTO route.
Add a BoM with a component product.
Set quantity to 0.1 (less than vendor min_qty).
- Create a Sale Order with the same product added twice.
- Confirm the Sale Order.
**Issue:**
During procurement:
- First procurement correctly fetches the supplier.
- On PO line update (_update_purchase_order_line), seller is recomputed.
Due to min_qty filtering, no seller is returned when quantity is low.
This results in: Missing seller, Missing product_uom, Invalid price
computation, And finally causes a crash when confirming the Purchase Order,
in _get_stock_move_price_unit: ZeroDivisionErroR
Root Cause:
- _select_seller filters suppliers using min_qty.
During merge/update flow, recomputed quantity may not satisfy min_qty.
Existing valid supplier (from initial procurement) is ignored.
No fallback handling in _update_purchase_order_line.
**Solution:**
- Add fallback logic when _select_seller returns no result: Use
_prepare_sellers() to fetch a valid supplier ignoring min_qty.
- Ensure a supplier is always available for: UoM resolution, Price computation
Prevents crash and ensures consistent PO line updates.
**Result:**
- No traceback when quantity < vendor min_qty
Supplier, UoM, and price are properly set
**OPW-6106487**
Forward-Port-Of: odoo/odoo#263699
Forward-Port-Of: odoo/odoo#259894This update resolves a problem where invoices created from timesheeted sales orders weren't correctly calculating the invoiceable quantities. The fix ensures that invoiceable lines are recomputed every time an invoice is created, regardless of whether dates are provided, leading to accurate invoicing for service-based products.
Original PR description
Steps --------- 1. Install Accounting, Sale and Timesheet 2. Create 2 product a. Product A - storable - invoiced on Ordered Quantity b. Product B - service - create a task on order - invoice on…
Steps
---------
1. Install Accounting, Sale and Timesheet
2. Create 2 product
a. Product A - storable - invoiced on Ordered Quantity
b. Product B - service - create a task on order - invoice on
timesheeted
3. Create an SO with 3 product A and 3 product B
4. Add a timesheet line for 1 hour of product A - can be done thanks to
the button appearing on the SO at confirmation
5. Create Invoice
6. Don't add dates to the wizard and confirm -> Both product appear
7. Add date range that do NOT include the timesheeted lines -> Only the
storable product appear
8. Repeat step 6 -> Only the storable product appear
Problem
---------
During the creation of the invoice, the invoiceable lines would get
computed dates where provided to the wizard
(`sale.order.line.qty_to_invoice`). When no dates were provided, we
would not manually trigger the invoiceable lines recomputation and were
relying one the data store in cache.
Solution
---------
Force the invoiceable quantity recomputation upon each invoice creation.
opw-6001094
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#261062