Tuesday, November 25, 2025
31 changes · 19.0
New functionality added to Odoo
This update introduces a new integration with Intervat, allowing Belgian companies to electronically submit VAT declarations. Additionally, it provides access to MyMinfin, enabling users to download previous VAT declaration files (PDF & XML) after submission. This improves compliance and simplifies record-keeping for our Belgian customers.
Original PR description
This commit ad new EDI integration for Intervat and MyMinfin api's, usable only for Belgian companies. Intervat: this api is used to send electronic vat declarations. MyMinfin: this api is used after a declaration submission, it allow the user to fetch and download files (pdf & xml) from previous submitted declarations. Linked: https://github.com/odoo/odoo/pull/221070 task-4624148
Enhancements to existing features
This update enhances account reports to ensure they only display journals relevant to the currently selected company when multi-company accounting is enabled. Previously, reports could inadvertently include data from other companies' ledgers. This change improves report accuracy and simplifies the user experience for businesses managing multiple companies.
Original PR description
When multi-company, if multi-ledger is visible to one company, exclude journals of other companies when opening the report. task-5180393
Resolved issues and error corrections
This update corrects a bug where reordering lists with multiple pages would cause elements to temporarily disappear. The fix prevents incorrect page loading when deleting the last item on a page, ensuring lists refresh correctly and data is consistently displayed. This improves the user experience for all users managing sortable lists.
Original PR description
****Behavior:**** **Current:** When adding an element to any reorderable empty list, then deleting it, then adding two new ones, and lastly trying to reorder them. They will disappear until you…
****Behavior:**** **Current:** When adding an element to any reorderable empty list, then deleting it, then adding two new ones, and lastly trying to reorder them. They will disappear until you reload the list. This is occurring since list can be presented in multiple pages, the length of which is defined by the variable limit and the current page is represented by offset (multiple of limit) and when the last element of a page is deleted, we load the previous page (deduce limit from offset), the issue is that there isnt any checks that we are not currently on the first page of the list, and thus we change offset to a negative number (0-limit) which results in an empty list when trying to load the ids of the records (which happens when we reorder the list, and not when adding new elements which explains why they only disappear at that moment) **Steps to reproduce:** (example with sale orders but works with any manually sortable list) - Create a Sale Order - Add any product - Delete it - Add any two combination of product or sections - Swap the order of both - You'll see the elements disappear, when reloading the page they should come back. opw-5191103
This update enhances the multi-company ledger feature by preventing confusion when multiple companies are selected. It now includes the company name in the journal selection options, making it easier to manage and understand which companies are associated with a particular ledger.
Original PR description
* When a company is selected on multi-ledger, exclude other companies journal from excluded journals view. * When multi-ledger is visible for all companies, add the company name to the tags list and autocomplete options of the excluded journals to avoid confusion. task-5180393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces new tax groups for AR withholdings and perceptions, enhancing tax tracking accuracy. By creating distinct groups for withholdings and aligning with existing sales/purchase structures, this change simplifies tax reporting and improves data management. It also corrects naming conventions for key accounts.
Original PR description
Update id and tax groups on tax csv files. Before this change all the perceptions and withholdings were in the same tax group. New withholding tax groups are created on…
Update id and tax groups on tax csv files. Before this change all the perceptions and withholdings were in the same tax group. New withholding tax groups are created on addons/l10n_ar_withholding/data/template/account.tax.group-ar_base.csv and addons/l10n_ar_withholding/data/template/account.tax.group-ar_ex.csv 1) Replace/unify "ARBA" with "PBA" and "Provincia de Buenos Aires (P. Buenos Aires)" 2) Replace/unify "CABA" with "CABA" and "Ciudad Autónoma de Buenos Aires" 3) Multiply the tax groups for AR withholdings taxes: a) To improve tax tracking. Currently, all withholdings are grouped into a single group, making it very difficult to retrieve all taxes related to a specific withholding. The tax group concept fits this need well. b) Aligns with how tax groups are structured for sales/purchases. c) Also, the current single withholding group is incorrectly named "VAT Withholding". 4) Fix the name of the generic account from "Default VAT Payable/Receivable Account" to "Default Tax Payable/Receivable Account" Task Adhoc side: 57644 Task Latam side: 1361 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the HTML editor's syntax highlighting by adding a dedicated read-only component, ensuring highlighting is visible even when the editor is in read-only mode. It also refactors the underlying component structure for better efficiency and maintainability, addressing several related improvements and bug fixes.
Original PR description
The syntax highlighting plugin cleans itself up on save so the `pre` is not dependent on Prism's css. But we still want to see the highlighting in readonly mode, so this adds a readonly version of the component in order to parse the `pre` in readonly as well. This also refactors the syntax highlighting embedded component so it uses an embedded state instead of reinventing it with `commitToHost`. task-5159286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update significantly speeds up the process of finding deliveries associated with stock lots. By optimizing a key database query, the system now responds much faster, particularly when dealing with a large number of lots. This improves overall system responsiveness and efficiency.
Original PR description
### Description: This refactoring replaces the recursive calculation in `_find_delivery_ids_by_lot` with an iterative process. This change significantly reduces the amount of database queries by prefetching and batching all required lines in a single pass, and it also eliminates the overhead caused by repeated recursive function calls. ### Benchmark: | Total Lots | Before | After | |------------|--------|--------| | 69 | 1 sec | 106 ms | | 1152 | 1 min | 5 sec | ### Reference: opw-5096599 Forward-Port-Of: odoo/odoo#236773 Forward-Port-Of: odoo/odoo#233478
This update resolves an issue where changing a journal's currency caused outstanding account information to disappear from payment method lines. This change ensures that account details remain accurate after currency adjustments, preventing data loss and maintaining financial reporting integrity. The fix was triggered by a bank sync updating currency.
Original PR description
Changing the currency on a journal triggers the compute of inbound/outbound method lines, which clears the method lines before reasign the default method lines. This leads to the loss of any outstanding account set on the method lines. Steps: - Have a bank journal with outstanding accounts set on the payment method lines - Change the currency (in our case, this is the bank sync that changed the currency of the journal) -> Outstanding accounts are missing on the payment method lines, even if the accounts currency is the same as the journals or no currency is set on the accounts. opw-5175794 Forward-Port-Of: odoo/odoo#234008
This update resolves an error that occurred when the system automatically cleaned up data related to withhold payments. The fix ensures that linked data is properly disconnected before cleanup, preventing database errors. This improves the stability of the EC company accounting processes.
Original PR description
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653
This update resolves a memory issue that occurred when processing sales documents in the RS (Romania) region. The fix pre-fetches key data, preventing the system from running out of memory and improving processing speed. This ensures accurate and efficient handling of RS EDI transactions.
Original PR description
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in…
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory records ``` sagu_3267671=> select count(id) from account_move; count --------- 1034179 (1 row) ``` ``` File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine return needle(*args) File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed') File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__ self.compute_value(recs) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value records._compute_field_value(self) File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine return needle(records, *args) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp> values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__ return self._fields[key].__get__(self, self.env.registry[self._name]) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__ return super().__get__(records, owner) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__ recs._fetch_field(self) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field self.fetch(fnames) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch fetched = self._fetch_query(query, fields_to_fetch) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query self.env.cache.insert_missing(fetched, field, values) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing field_cache.setdefault(id_, val) MemoryError ``` upg-3267671 opw-5246681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235919
This update resolves an issue where preparation printing failed when no order was selected in the POS service. The fix prevents a traceback during preparation, ensuring UrbanPiper orders are correctly sent for printing. This improves the reliability of the restaurant's preparation workflow.
Original PR description
Steps to reproduce: - Set up UrbanPiper and a preparation printer in the restaurant. - Open the Ticket Screen from the Floor Screen. - Accept an UrbanPiper order. Issue: - Traceback occurs when sending the order for preparation if no order is currently selected in the POS service. Fix: - Prevent error during preparation printing when no order is selected. ---- Remove redundant `modeUpdate` logic from `categoryCount` computation Task-5241128
This update fixes an issue where MTO backorders incorrectly displayed the delivered quantity instead of the original order total. The fix ensures that the 'Ordered' quantity accurately reflects the remaining demand for MTO products, resolving a discrepancy in reporting. This improves the accuracy of inventory tracking for MTO orders.
Original PR description
Steps To Reproduce ------------------ 1- Create an MTO product. 2- Create an SO for 10 units and confirm. 3- Deliver 5 on the first picking, validate, and create the backorder. 4- Print the delivery…
Steps To Reproduce ------------------ 1- Create an MTO product. 2- Create an SO for 10 units and confirm. 3- Deliver 5 on the first picking, validate, and create the backorder. 4- Print the delivery slip of the first (done) picking. Issue ----- 1- MTO: Ordered = 5, Delivered = 5, Remaining = 5. 2- Normal product: Ordered = 10, Delivered = 5, Remaining = 5. The ordered quantity for MTO products is wrong, it shows the delivered amount instead of the original order total. Cause ----- The delivery report calculates the "Ordered" quantity by adding what we just delivered to what is left in the backorders. I found that the code was looking for move lines in the backorders to count what is left. When I checked a backorder that is waiting for stock (like MTO), there is no reserved stock yet, so no move lines exist. Because of this, the report thought the backorder was empty and ignored the remaining quantity. Fix --- I changed the code to look at the `move_ids` instead of the `move_line_ids`. While debugging I found out that the `move_ids` record always holds the correct demand regardless of the product. opw-5112467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes the performance of our sales order system by adding an index to a key field. This change addresses a potential slowdown when filtering sales orders by the sales team assigned to them. By indexing this field, we're speeding up searches and improving overall system responsiveness.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237116
This update resolves an issue where pressing Alt+A in the website builder didn't correctly open the translation mode. The fix adds a necessary parameter to ensure the translation features are activated, allowing users to translate website content. This improves the usability of the website builder for multilingual sites.
Original PR description
__Before this commit:__ 1. Add a 2nd language to your site 2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page) 3. Press Alt+A…
__Before this commit:__ 1. Add a 2nd language to your site 2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page) 3. Press Alt+A (the shortcut to open the builder) => The builder opens, but it is unusable. The builder options are the translation options, but the iframe is not in a translatable state. __Cause:__ Pressing Alt+A outside the admin backend just [adds `enable_editor=1` in the URL][1]. When the page is displayed in the 2nd language `data-translatable` is included in the metadata so the translation mode opens. However the iframe relies on the `edit_translations` search param being set to include the translation branding (i.e. `data-oe-translation-source-sha`) which is not the case after pressing Alt+A. __The fix:__ Add `edit_translations` when pressing Alt+A in any case. If the page is translatable, the translation mode will correclty open, otherwise it will be ignored and the edit mode will open instead. NB: By doing this, we bypass the checks in [`attemptStartTranslate`][2] therefore a user who doesn't have the proper access rights will still be able to open the translation mode but they will not be able to do anything. Using those checks would add too much complexity to the code in regards to how niche the feature is anyway. [1]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/js/content/redirect.js#L33 [2]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/client_actions/website_preview/edit_website_systray_item.js#L54 task-5125700 Forward-Port-Of: odoo/odoo#236039
This update resolves a payroll error that occurred after the introduction of versioning in the 19.0 release. The issue stemmed from outdated data files that didn't reflect the change of the 'contract' key to 'version', along with a data type error. This fix ensures 'Cadre' employee pay runs can now be processed correctly.
Original PR description
To reproduce: ============= - in FR company create employee with "Cadre" status - in Payroll -> Pay runs, create a new pay run for this employee for a given month -> Error occurs Problem: ======== after intoducing Versioning in 19, `contract` key was changed to `version` but these data files were not updated accordingly. also there was a typo in lines with `company_20id` instead of `company_id` opw-5244193
This update resolves an issue where the Facturae export XML incorrectly displayed negative values for withholding taxes. The fix ensures that withholding tax amounts are always positive, preventing rejection by the FAC (Foreign Agents Control). This improves the accuracy of Facturae submissions.
Original PR description
## Issue: The `TotalTaxesWithhold` field in the exported XML could be negative, causing FACE to reject the document. ## Cause: A previous change (https://github.com/odoo/odoo/pull/229236) added `values['tax_amount_currency']` to `TotalTaxesWithhold` without converting it to a positive value: https://github.com/odoo/odoo/blob/88b7ee6d9d2a7fe96512da0a7eaf8efcf9020ee1/addons/l10n_es_edi_facturae/models/account_move.py#L449 ## Steps to reproduce: - Install `l10n_es_edi_facturae` - With the ES company, create an invoice with a product and a withholding tax (e.g., 15% WHI) - Confirm the invoice and Send (Facturae) - Open the XML attached in the chatter - Observe that `TotalTaxesWithhold` is negative opw-5220205 Forward-Port-Of: odoo/odoo#235774
This update significantly speeds up payroll processing, specifically when regenerating work entries for a large number of employees. The change reduces query execution time from 20 seconds to 2 seconds, improving overall system responsiveness and efficiency. This enhancement ensures smoother payroll operations for companies with many employees.
This update allows spreadsheet reports to group data by many2one references, specifically Lead -> Activity relationships. This addresses a request from a partner at OXP, enabling more detailed reporting on activity status linked to Leads. It's important to note that grouping by many2one_reference requires careful consideration to avoid combining data from different models.
Original PR description
This is a feedback from a partner at OXP, he wants to know the number of activities (late or not) linked to some Lead -> activities grouped by res_id. But grouping a pivot by a many2one_reference is currently not supported. This commit adds the support. Note that carelessly grouping by a many2one_reference mixes records linked to different models (same id, but different model). To avoid mixin apples and oranges, you have to either groupby model, *then* by res_id, or add the model to the domain. Task: 5102923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234142 Forward-Port-Of: odoo/odoo#227939
This update fixes an issue where the website builder's save button would remain disabled after canceling the language selection dialog. The change introduces a mechanism to ensure after-save handlers are executed only when necessary, improving the user experience when adding or modifying languages.
Original PR description
### [FIX] mail: clean the "beforeunload" listener in tests Some tests trigger a call to the function `Rtc.joinCall` which adds a listener on `beforeunload` event that cancels the event. Some of these…
### [FIX] mail: clean the "beforeunload" listener in tests Some tests trigger a call to the function `Rtc.joinCall` which adds a listener on `beforeunload` event that cancels the event. Some of these tests do not trigger a later call to `Rpc.clear`, thus the listener stays registered. This could mess with other unrelated tests that check their own handlers of `beforeunload` are correct. This commit adds a cleanup on the helper used by the problematic tests. task-5138313 ### [FIX] website, html_builder: run after-save handlers if aborted Usually, running the after save handlers is not needed after the save because we are about to close or reload the builder. Thus they are not run as an optimization. But there are a few cases where they are needed: - The saving of the page failed. This case was correctly handled only when clicking on the save button or adding a module - When adding a language, but cancelling the dialog to choose the language This commit changes the save function of the save plugin, to take a async callback to determine whether the after-save handlers should run. The callback is async to be able to wait for the language choice dialog. If the callback returns `true`, then the after-save handlers are run. Steps to reproduce: - Open website builder - Open "Theme" tab - Click "Add Language" - Confirm the first dialog (about save) - Cancel the second dialog (language choice) - Bug: the save button stays disabled with the spinning wheel next to it task-5138313 Forward-Port-Of: odoo/odoo#229843
This update fixes an issue where the stock forecast was incorrectly displaying negative quantities due to how it was calculating demand based on completed stock moves. The fix ensures the forecast accurately reflects the actual available stock by basing calculations on the quantity of the move itself, not the original demand.
Original PR description
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form >…
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of -50 for every date in the past ### Cause of the issue: The part of the report query relying on done moves is based on the `prodcut_uom_qty` of the move and hence on its demand. However, when the move is 'done' only its quantity should be relevant. #### Note: The same issue happen if you receive more than the demand. That is: - Mark as to do, set the quantity to 150 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of 50 for every date in the past The issue did not happen prior to 17.0 because validating a move for a quantity that differs from the demand would: - in case quantity < product_uom_qty: split the move in 2: one done move where the demand matches the quantity and one cancelled move with the remaining demand. - in case quantity > product_uom_qty: the demand of the move was updated to match the quantity of the move. This has been changed in f9867a5fa572a15fb89c49c61e569427d6388cbc now, validating a move for a quantity that differs from the demand will keep the demand intact. opw-5152570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234576
This update resolves an issue in the 3-step manufacturing process where changing the production rule to MTSO didn't correctly trigger replenishment orders. The fix ensures that sufficient component quantities are automatically ordered when needed, maintaining accurate stock levels and preventing production delays. This improves the efficiency of the manufacturing workflow.
Original PR description
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod,…
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity. Steps to reproduce ----- - Enable warehouses and multi-step routes - Set warehouse manufacturing to 3 step - Edit the 3 step production route - Change the pre-prod -> prod rule to mts else mto - Create a product "Comp" - Set a quantity of 5 in location pre-prod - Create a product "Prod" - Add a BoM with "Comp" as component - Create a MO for 10 of Prod - Confirm MO > There is a transfer stock -> pre-prod for 5 of Comp - Open the production quantity wizard, update value to 12 and confirm > The transfer still shows 5 of Comp instead of the needed 7 Cause ----- Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement` https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485 Before actually running any procurement we do https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492 Since the procurement group's method is `mts_else_mto`, when we go through https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332 we go into the `else` part and set the move's `procure_method` to mts. This means that, in the `run_procurement` method https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504 is not true, so we don't add any procurement to run. Solution ----- In `_adjust_procure_method` we update the move's rule to the MTSO one we found https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328 This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO. ----- Ticket: opw-5008871 Forward-Port-Of: odoo/odoo#235125
Accessing the chat tab in the messaging menu with many chats causes a max call stack error. This commit reverts a computed field to a getter to break the compute cycle and improve performance.
Original PR description
- Description: Signing the individual CLA for my contributions. Signed by Mahmoud Essam, esame4166@gmail.com --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that refund orders in Point of Sale now correctly apply the same price list as the original order they were placed under. Previously, refund orders defaulted to the standard price list, leading to potential pricing discrepancies. This change improves accuracy and consistency in refund calculations.
Original PR description
Before this commit: ------------- - Refund order price list was set to the default one, while the original order used a different price list. After this commit: ------------------ - Refund order now applies the same price list as the original order. Task-5215488
This update resolves an issue where the gross salary displayed in the Indian payroll salary calculator was incorrectly showing as zero. The fix ensures the gross salary is accurately calculated by retrieving default percentage rules, addressing a discrepancy in the underlying calculations. This ensures correct payroll processing for Indian company users.
Original PR description
## Issue: - When we try the salary calculator for 'IN company' the gross was showing '0'. ## Reason: - Basic salary amount is calculated based on l10n_in_basic_percentage and due to dependency of l10n_in_basic_salary_amount on l10n_in_basic_percentage and vice versa, it gives '0' percentage. ## Fix: - Fetched the default percentage from rule parameters to calculate the gross salary. Fixed the issue of gross salary displaying '0' in salary calculator for Indian Payroll. Added the default percentage in compute of basic percentage so that it fetches values from rule parameters and calculates the basic salary amount. task - 5062259
This update resolves an error that occurred when users tried to replace work entries within a payslip using the Gantt view. The issue stemmed from incorrect data being passed to the view, causing 'Missing record' or 'Contract out of range' errors. This fix ensures the correct employee ID is used, improving the reliability of the work entry scheduling process.
Original PR description
**Steps to reproduce:** - Install the hr_payroll module. - Open the form view of an employee with a running contract and click on the Payslip smart button. - Create or open an existing payslip, then open the Work Entries from smart button. - Click on any day cell and then click the Quick Replace button. **Issue:** Clicking the Quick Replace button (next to Set) triggers an error, 'Missing record' or 'Contract out of range.' **Cause:** The issue occurs due to an incorrect context being passed in the Gantt view (https://github.com/odoo/odoo/pull/223409). The view incorrectly passes the payslip ID instead of the employee ID. **Fix:** This PR updates the context to ensure the correct employee ID is passed to the Gantt view. task-5219487