Saturday, April 19, 2025
12 changes · saas-18.1
Resolved issues and error corrections
This fixes an incorrectly named function in the Dutch reporting module that could affect report-related processing. It helps ensure Dutch tax and audit exports continue to work reliably for affected users.
Users can now scroll through pivot dimensions in the spreadsheet side panel when the document is in readonly mode. This fixes a usability issue that prevented viewing all available pivot information without changing editing permissions.
Original PR description
The `pointer-events: none;` property prevents elements (and their children) from receiving any pointer events, including scroll gestures. As a result, scrolling the pivot dimensions in readonly mode was not possible. To fix this, we removed `pointer-events: none;` from the main container and applied it only to the child elements of the pivot dimensions. Task: 4655830
Miscellaneous changes
Accounts of the following account types should generally speaking not be reconcilable: - `asset_cash` - `liability_credit_card` - `off_balance` That is why the "Allow Reconciliation" (`reconcile`) field is already invisible on the 'account.account' form and list views. After this commit - All such accounts in the standard chart of accounts are not reconcilable (there were non for `off_balance`) - The compute function on 'account.account' sets those accounts to not be reconcila
Original PR description
Accounts of the following account types should generally speaking not be reconcilable: - `asset_cash` - `liability_credit_card` - `off_balance` That is why the "Allow Reconciliation" (`reconcile`) field is already invisible on the 'account.account' form and list views. After this commit - All such accounts in the standard chart of accounts are not reconcilable (there were non for `off_balance`) - The compute function on 'account.account' sets those accounts to not be reconcilable (already done for `asset_cash`) when changing the account type. task: None Forward-Port-Of: odoo/odoo#206700 Forward-Port-Of: odoo/odoo#206011
Until version 0.9.8 of vobject we need to ignore: - DeprecationWarning in python 3.6 and after - SyntaxWarning since python 3.12 See https://github.com/py-vobject/vobject/commit/da50fdb5fa871e4c5c3420d1e2e34e7c9ce6bb30 The warning occurs only during the first precompilation of the library. It does not occur on readonly filesystem, ie runbot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206529 Forward-Port-Of:
Original PR description
Until version 0.9.8 of vobject we need to ignore: - DeprecationWarning in python 3.6 and after - SyntaxWarning since python 3.12 See https://github.com/py-vobject/vobject/commit/da50fdb5fa871e4c5c3420d1e2e34e7c9ce6bb30 The warning occurs only during the first precompilation of the library. It does not occur on readonly filesystem, ie runbot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206529 Forward-Port-Of: odoo/odoo#206115
Steps to reproduce ------------------ - Create a product with price $80 - Create a fixed discount reward for this product with $40 - In PoS config, enable global discount - In a new PoS order, add the product created in the first step and observe that we now have 2 orderlines, the product at $80 and the discount at $40. Total amount remaining to pay is $40 - Add a global discount of 50% -> At this point, we are expecting to apply the 50% discount on the remaining $40, and hence, a disco
Original PR description
Steps to reproduce ------------------ - Create a product with price $80 - Create a fixed discount reward for this product with $40 - In PoS config, enable global discount - In a new PoS order, add…
Steps to reproduce ------------------ - Create a product with price $80 - Create a fixed discount reward for this product with $40 - In PoS config, enable global discount - In a new PoS order, add the product created in the first step and observe that we now have 2 orderlines, the product at $80 and the discount at $40. Total amount remaining to pay is $40 - Add a global discount of 50% -> At this point, we are expecting to apply the 50% discount on the remaining $40, and hence, a discount of $20, which changes the order's total price to $20. We also expect the fixed discount line of $40 to remain at $40, as it's a fixed price discount. Indeed, we now see a $20 global discount as an orderline, but the $40 fixed discount has changed its value from $40 to $53.33, and thus, the total amount has decreased to $6.67 instead of $20 -> A corrupted final amount!! In some other pricing configs, this final total amount will even become negative. Reason ------ After applying the global discount, we recalculate the value of the discounts to keep everything in sync, so we recompute the discount value of the fixed $40 discount in `_getRewardLineValuesDiscount`, and since now the total amount to pay, i.e. `order.get_total_with_tax()` is less then the value of the product (due to the global discount), `discountFactor` [1] of the fixed discount increases since `discountable` decreases. However, at the end when we calculate the new `unit_price` of this fixed discount, we multiply the `discountFactor` by the intial product price, i.e. by the price before the global discount, and hence, the amount of the fixed tax will be higher than expected, causing this buggy behavior. Below is a math representation of the bad (current) vs good (new) behavior: Bad: discountable = $60 = $80 - $20, where $20 is (total - fixed) * discount, i.e. (80-40)*0.5 discountFactor = $40 / $60 = 0.666666 price_unit = 0.666666 * $80 = $53.3333 (instead of $40) Good should be: discountable = $60 = $80 - $20, where $20 is (total - fixed) * discount, i.e. (80-40)*0.5 discountFactor = $40 / $60 = 0.666666 price_unit = 0.666666 * $60 = $40 I.e the good behavior should be multiplying the `discountFactor` by the the min of the remaining total price (after applying the global discount, so $60), and the initial value of the product (here $80). The formula has been updated accordingly. [1]: https://github.com/odoo/odoo/blob/76e2aa6b70d1fb03b8ce2f8e4a7e9c3d9425270f/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1163 opw-4622428 Forward-Port-Of: odoo/odoo#202334
In the _compute_name_placeholder method, self.date is used inside the for move in self loop which causes a singleton error when self is a multiple records recordset. This commit replaces self by move to avoid the singleton error. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206553
Original PR description
In the _compute_name_placeholder method, self.date is used inside the for move in self loop which causes a singleton error when self is a multiple records recordset. This commit replaces self by move to avoid the singleton error. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206553
Description of the issue this commit addresses: Items with a null residual are not reconcilable but when using the unreconciled filter implying that shown items have to be reconciled, those items are not hidden which is confusing. --- Desired behavior after this commit is merged: Using the Unreconciled filter on Journal Items will filter out items that have a null residual. --- task-4723956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/sub
Original PR description
Description of the issue this commit addresses: Items with a null residual are not reconcilable but when using the unreconciled filter implying that shown items have to be reconciled, those items are not hidden which is confusing. --- Desired behavior after this commit is merged: Using the Unreconciled filter on Journal Items will filter out items that have a null residual. --- task-4723956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205845
### [IMP] account: fix the summary of account.move.send.batch.wizard *: account_peppol, snailmail_account The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened). We al
Original PR description
### [IMP] account: fix the summary of account.move.send.batch.wizard *: account_peppol, snailmail_account The summary was displaying wrong numbers of invoices. Indeed, it was computed on default…
### [IMP] account: fix the summary of account.move.send.batch.wizard *: account_peppol, snailmail_account The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened). We also always put email as a fallback, even if no email is set, since it can be added through the wizard. task-no (review with TSB/PMAX) ---------------------------- ### [FIX] account_peppol: Remove 'skipped' state of Peppol moves This state doesn't really make sense. It only happens when there is an error while generating the XML file to send, which can be considered as a blocking error. task-no ---------------------------- ### [FIX] account_peppol: fix batch send of Peppol invoices when no format set In previous commit[1], we set the BIS3 format on invoices that were meant to be sent trough Peppol, even if no invoice_edi_format was set on the Partner. This commit fixes some cases when sending multiple invoices with no invoice_edi_format but Peppol as default sending method ended up not being sent. [1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad task-no Forward-Port-Of: odoo/odoo#204419
When using a fiscal position the tax group labels on the receipt order lines where not adapted correctly Steps to reproduce: ------------------- * Create 2 taxes A and B * For each tax go to their corresponding tax group and set the label to "A" and "B" * Create a fiscal position that will match A on B * Add the fiscal position to the PoS * Create a new order and add a product that uses the A tax * Activate the fiscal position * Validate the order and go to the receipt > Observation:
Original PR description
When using a fiscal position the tax group labels on the receipt order lines where not adapted correctly Steps to reproduce: ------------------- * Create 2 taxes A and B * For each tax go to their corresponding tax group and set the label to "A" and "B" * Create a fiscal position that will match A on B * Add the fiscal position to the PoS * Create a new order and add a product that uses the A tax * Activate the fiscal position * Validate the order and go to the receipt > Observation: The orderline will show the label A but the order tax detail will correctly show the label B Why the fix: ------------ When generating the display data for the orderline we need to first map the taxes according to the fiscal position. opw-4579223 Forward-Port-Of: odoo/odoo#203294
Before thos commit, the next invoice date was updated at post invoice based on the order line properties. pre paid lines are will use the last deferred end date of the linked account move lines and post paid line simply increment the next invoice date. Before this commit, the post paid detection was faulty: we checked that all line were postpaid but if line notes or non recurring lines existed, they would not have the postpaid property. As a result, the next invoice date would be incremented
Original PR description
Before thos commit, the next invoice date was updated at post invoice based on the order line properties. pre paid lines are will use the last deferred end date of the linked account move lines and post paid line simply increment the next invoice date. Before this commit, the post paid detection was faulty: we checked that all line were postpaid but if line notes or non recurring lines existed, they would not have the postpaid property. As a result, the next invoice date would be incremented with the prepaid condition. As a result, the next invoice date would only be incremented by one day and the cron would run on these contracts every day. opw-4618947 opw-4668741 opw-4686930 Forward-Port-Of: odoo/enterprise#83438
This PR fixes an issue where the switch buttons in the documents module had incorrect padding when clicking on the activity switch view button.This fix ensures proper spacing and alignment across the interface. Task-4680512 Forward-Port-Of: odoo/enterprise#82747
Original PR description
This PR fixes an issue where the switch buttons in the documents module had incorrect padding when clicking on the activity switch view button.This fix ensures proper spacing and alignment across the interface. Task-4680512 Forward-Port-Of: odoo/enterprise#82747
*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi 1. fix the summary of account.move.send.batch.wizard The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened). We al
Original PR description
*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi 1. fix the summary of account.move.send.batch.wizard The summary was displaying wrong numbers of invoices. Indeed, it was computed on default…
*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi 1. fix the summary of account.move.send.batch.wizard The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened). We also always put email as a fallback, even if no email is set, since it can be added through the wizard. 2. fix batch send of Peppol invoices when no format set In previous commit[1], we set the BIS3 format on invoices that were meant to be sent trough Peppol, even if no invoice_edi_format was set on the Partner. This commit fixes some cases when sending multiple invoices with no invoice_edi_format but Peppol as default sending method ended up not being sent. [1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad 3. Remove 'skipped' state of Peppol moves This state doesn't really make sense. It only happens when there is an error while generating the XML file to send, which can be considered as a blocking error. task-no (review with TSB and PMAX) Forward-Port-Of: odoo/enterprise#83443