Saturday, March 15, 2025
13 changes · master
Miscellaneous changes
It should be `invoice_sending_failed`, we don't have `invoice_sent_failed` :D (for more info see `ciusro_document.py`, the `state` selection field) task-None Forward-Port-Of: odoo/odoo#201629
Original PR description
It should be `invoice_sending_failed`, we don't have `invoice_sent_failed` :D (for more info see `ciusro_document.py`, the `state` selection field) task-None Forward-Port-Of: odoo/odoo#201629
Following the fixes - https://github.com/odoo/odoo/commit/ce92dedea0fd3cdc73da6366c20b8052bb04f7e9 & https://github.com/odoo/odoo/commit/4dc901e77dc7e2873a94ea3a541450fc9fb2eb5e Investing more into the issues, we found out that E-waybill portal, doesn't allow generation of E-waybill as Inwards (Tax Invoice) type for Sales Return, Only Challan Type is accepted it means that the Sales Return, E-waybill should be generated by the E-waybill on Stock/Inventory. Not through the Invoice/Account App.
Original PR description
Following the fixes - https://github.com/odoo/odoo/commit/ce92dedea0fd3cdc73da6366c20b8052bb04f7e9 & https://github.com/odoo/odoo/commit/4dc901e77dc7e2873a94ea3a541450fc9fb2eb5e Investing more into the issues, we found out that E-waybill portal, doesn't allow generation of E-waybill as Inwards (Tax Invoice) type for Sales Return, Only Challan Type is accepted it means that the Sales Return, E-waybill should be generated by the E-waybill on Stock/Inventory. Not through the Invoice/Account App. This commit intends to do a soft block for generation of E-waybill through Sales Credit Note task-4441603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200629 Forward-Port-Of: odoo/odoo#192090
Before this commit, logs had to be downloaded from the tab that hosted the call from which we wanted the logs. If we want logs from all the calls that happened across tabs, they currently have to be downloaded separately. Moreover, since the addition of a shared call state between tabs, it has become less obvious to know which tab actually hosts the call. This commit fixes this issue by collecting logs from all tabs before generating the file. Forward-Port-Of: odoo/odoo#201260
Original PR description
Before this commit, logs had to be downloaded from the tab that hosted the call from which we wanted the logs. If we want logs from all the calls that happened across tabs, they currently have to be downloaded separately. Moreover, since the addition of a shared call state between tabs, it has become less obvious to know which tab actually hosts the call. This commit fixes this issue by collecting logs from all tabs before generating the file. Forward-Port-Of: odoo/odoo#201260
For existing customers, when coretax is installed, the new luxury tax group and its tax will not be loaded into Odoo. During XML generation, it will look for the tax group by XML ID which will not be found and hence resulting to traceback error. To mitigate this issue, we will introduce a post_init_hook to manually create the tax group and not raise exception when env.ref() doesn't find the tax group opw-4635356 --- I confirm I have signed the CLA and read the PR guidelines at www.odo
Original PR description
For existing customers, when coretax is installed, the new luxury tax group and its tax will not be loaded into Odoo. During XML generation, it will look for the tax group by XML ID which will not be found and hence resulting to traceback error. To mitigate this issue, we will introduce a post_init_hook to manually create the tax group and not raise exception when env.ref() doesn't find the tax group opw-4635356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201643 Forward-Port-Of: odoo/odoo#201523
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#201843 Forward-Port-Of: odoo/odoo#201601
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201843 Forward-Port-Of: odoo/odoo#201601
This commit gives the users access to the XML of an invoice whose submission to JoFotara failed. This allows for better debugging of failed invoices. It also prevents the users from deleting PDFs of successfully submitted invoices. task-4571479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201943 Forward-Port-Of: odoo/odoo#199210
Original PR description
This commit gives the users access to the XML of an invoice whose submission to JoFotara failed. This allows for better debugging of failed invoices. It also prevents the users from deleting PDFs of successfully submitted invoices. task-4571479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201943 Forward-Port-Of: odoo/odoo#199210
The export is completely wrong when it comes to multiple taxes affecting each others. It would recompute the withholding taxes one by one based on the price subtotal instead of taking into account all other taxes as you would expect. task-4641930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201809 Forward-Port-Of: odoo/odoo#201489
Original PR description
The export is completely wrong when it comes to multiple taxes affecting each others. It would recompute the withholding taxes one by one based on the price subtotal instead of taking into account all other taxes as you would expect. task-4641930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201809 Forward-Port-Of: odoo/odoo#201489
In commit b81314b we replaced a join on a case with a join on a boolean expression- however this did not materially increase performance (same order of magnitutde). Instead we should have simply used a valued case expression, which permits an entirely different (and much more optimal) query plan- specifically during sequential scans of the warehouse_cte common table expression. *See PR for further details* Forward-Port-Of: odoo/odoo#201318
Original PR description
In commit b81314b we replaced a join on a case with a join on a boolean expression- however this did not materially increase performance (same order of magnitutde). Instead we should have simply used a valued case expression, which permits an entirely different (and much more optimal) query plan- specifically during sequential scans of the warehouse_cte common table expression. *See PR for further details* Forward-Port-Of: odoo/odoo#201318
Previously, the auto_install flag was set on both account and l10n_fr, preventing proper installation of the fiscal localization package. Now, the fiscal localization package is correctly installed when a French company is created and the account module is installed. opw-4630911 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201729 Forward-Port-Of: odoo/odoo#201591
Original PR description
Previously, the auto_install flag was set on both account and l10n_fr, preventing proper installation of the fiscal localization package. Now, the fiscal localization package is correctly installed when a French company is created and the account module is installed. opw-4630911 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201729 Forward-Port-Of: odoo/odoo#201591
Forward-Port-Of: odoo/enterprise#81496
Original PR description
Forward-Port-Of: odoo/enterprise#81496
Documents created in a company folder should by default be assigned to the same company, as it was before sharepocalypse. Editing a folder company should then propagate to the accessible children. Task-4491333 Forward-Port-Of: odoo/enterprise#81527 Forward-Port-Of: odoo/enterprise#80591
Original PR description
Documents created in a company folder should by default be assigned to the same company, as it was before sharepocalypse. Editing a folder company should then propagate to the accessible children. Task-4491333 Forward-Port-Of: odoo/enterprise#81527 Forward-Port-Of: odoo/enterprise#80591
Steps to Reproduce: 1. Create a storable product with inventory tracking and assign a barcode. 2. Create an internal transfer from “Partners/Customers” to “Virtual Locations/Inventory Adjustment”. 3. This will generate two quants, one in Customers and another in Inventory Adjustment. 4. Navigate to Barcode > Inventory Adjustment and scan the product’s barcode. Issue: The scan triggers an inventory adjustment for the “Customer” location instead of the correct stock location. Tech
Original PR description
Steps to Reproduce: 1. Create a storable product with inventory tracking and assign a barcode. 2. Create an internal transfer from “Partners/Customers” to “Virtual Locations/Inventory Adjustment”. 3.…
Steps to Reproduce: 1. Create a storable product with inventory tracking and assign a barcode. 2. Create an internal transfer from “Partners/Customers” to “Virtual Locations/Inventory Adjustment”. 3. This will generate two quants, one in Customers and another in Inventory Adjustment. 4. Navigate to Barcode > Inventory Adjustment and scan the product’s barcode. Issue: The scan triggers an inventory adjustment for the “Customer” location instead of the correct stock location. Technical Explanation: • The system fetches all quants related to the product, including those in Vendor, Customer, and Inventory Adjustment locations. • These locations have IDs lower than the stock location (e.g., Customers = 5, Stock = 8). • The front-end caches this data (dbIdCache) and calls _defaultLocation() to determine the location. • Since the cache is ordered by ID, the first location (Customers, ID 5) is incorrectly selected instead of the stock location (8). • As a result, the inventory adjustment is applied to the wrong location. Proposed Fix: • Filter the results to include only internal locations when fetching quants. • This prevents non-internal locations (Vendor, Customers, Inventory Adjustment) from being selected by default. • If a user needs to adjust inventory for an external location, they must first scan the location barcode before scanning the product. Task-4596699 Forward-Port-Of: odoo/enterprise#81434 Forward-Port-Of: odoo/enterprise#81107
The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This
Original PR description
The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This revision changes the flow by simply re-instanciating a new `Model` every time we change the target revision. Task-4506832 Forward-Port-Of: odoo/enterprise#81491 Forward-Port-Of: odoo/enterprise#77667