Daily updates from Odoo
Navigate
Branch
Saturday, December 13, 2025
24 changes
9 changes
Enhancements to existing features
This update adds a message to the Account Online link, allowing users to easily revoke consent for the Basiq provider widget. This provides greater control and transparency regarding data sharing, aligning with our commitment to user privacy.
Original PR description
This commit will add a message on the account online link chatter for the basiq provider. This message will allow the user to be redirected to an odoofin page with a button to revoke his consent on a basiq widget task-5187621 Forward-Port-Of: odoo/enterprise#101972 Forward-Port-Of: odoo/enterprise#101801
PayPal has requested a unique identifier be added to Odoo transactions processed through their payment method. This change improves PayPal's ability to track transactions originating from Odoo, leading to better reconciliation and reporting. This update ensures seamless integration and collaboration with PayPal.
Original PR description
PayPal requested that we add an identifier so that they know which transactions are coming from Odoo for better trackability. task-5358321 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239750 Forward-Port-Of: odoo/odoo#237336
This update enhances the formatting of tax amounts in invoices for the Co-dian localization module. It standardizes the float format used in account_edi_common, ensuring accurate tax calculations and reporting for this specific region. This change improves the reliability of financial data related to Co-dian transactions.
Original PR description
Forward-Port-Of: odoo/enterprise#101999 Forward-Port-Of: odoo/enterprise#101288
Resolved issues and error corrections
This update optimizes how the loyalty program calculates potential free product quantities. Previously, the system unnecessarily checked all reward products, even after a valid one was found, leading to slower performance. This change improves the speed and efficiency of the loyalty program, particularly when multiple rewards are involved.
Original PR description
Before this commit, the computation of potential free product quantities looped through all reward products even after finding a valid one. This led to unnecessary calculations and performance degradation, especially when multiple reward products were involved. opw-5268991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239442
This update resolves two issues related to invoice attachments. Previously, incorrect invoice formats prevented attachment buttons from appearing, leading to errors. Additionally, warnings about unsupported attachments persisted even when the 'peppol' sending method was disabled, causing unnecessary notifications. This ensures consistent and reliable invoice attachment functionality.
Original PR description
[FIX] account{_edi_ubl_cii, _peppol}: Attachment fix
2 scenarios fixed in this commit :
1:
When a user invoice_edi_format is not 'ubl_bis3' the attachment button is not displayed and the key doesn't exists in the invoice_data. This causes traceback when trying to access the key.
2:
When a user send and print an invoice, with 'email' and 'peppol' as sending_methods, warnings will be displayed next to attachments not supported by peppol.
But if the user uncheck 'peppol', warnings will stay while no sending method requires them anymore.
See odoo/odoo#234339
Forward-Port-Of: odoo/odoo#239769
Forward-Port-Of: odoo/odoo#239684This update resolves a recursion error that occurred when editing POS configuration settings, specifically related to fiscal positions. The fix prevents an infinite loop caused by archiving fiscal positions, ensuring smoother configuration updates and preventing disruptions to the POS system. This improves stability and usability for users managing their point-of-sale operations.
Original PR description
**Steps To Reproduce:-** 1. Install point_of_sale in 17.0 2. Activate flexible taxes setting 3. set default fiscal position and after that archived that fiscal position. 4. try edit and save the POS…
**Steps To Reproduce:-**
1. Install point_of_sale in 17.0
2. Activate flexible taxes setting
3. set default fiscal position and after that archived that fiscal position.
4. try edit and save the POS config any operation below mentioned recursion error will come.
**Issue :-**
Due to archived record of fiscal postion is keep updating due to not satisfying this condition [config.default_fiscal_position_id.id not in config.fiscal_position_ids.ids](https://github.com/odoo/odoo/blob/62652ba3a7a90699e7aa8ff98e2d4980f1b43694/addons/point_of_sale/models/pos_config.py#L529) here ``config.fiscal_position_ids`` on this active filter is applying and it coming empty and going to update many2many field this process goes infinite due to archive fiscal position record
**FIX:-**
adding the check of active record fiscal position
```
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
records.write({self.name: write_value})
File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
return super(PosConfig, self).write(vals)
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
self.sudo()._set_fiscal_position()
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
records.write({self.name: write_value})
File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
return super(PosConfig, self).write(vals)
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
self.sudo()._set_fiscal_position()
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
records.write({self.name: write_value})
File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
return super(PosConfig, self).write(vals)
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
self.sudo()._set_fiscal_position()
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
records.write({self.name: write_value})
File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
return super(PosConfig, self).write(vals)
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 418, in write
result = super(PosConfig, self).write(vals)
File "/data/build/odoo/odoo/models.py", line 3820, in write
field.write(self, value)
File "/data/build/odoo/odoo/fields.py", line 4287, in write
return self.write_batch([(records, value)])
File "/data/build/odoo/odoo/fields.py", line 4308, in write_batch
return self.write_real(records_commands_list, create)
File "/data/build/odoo/odoo/fields.py", line 4835, in write_real
old_relation = {record.id: set(record[self.name]._ids) for record in records}
File "/data/build/odoo/odoo/fields.py", line 4835, in <dictcomp>
old_relation = {record.id: set(record[self.name]._ids) for record in records}
File "/data/build/odoo/odoo/models.py", line 6007, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/data/build/odoo/odoo/fields.py", line 2824, in __get__
return super().__get__(records, owner)
File "/data/build/odoo/odoo/fields.py", line 1270, in __get__
return self.convert_to_record(value, record)
File "/data/build/odoo/odoo/fields.py", line 4199, in convert_to_record
corecords = corecords.filtered(Comodel._active_name).with_prefetch(prefetch_ids)
File "/data/build/odoo/odoo/models.py", line 5496, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/data/build/odoo/odoo/models.py", line 5496, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/data/build/odoo/odoo/models.py", line 5493, in <lambda>
func = lambda rec: any(rec.mapped(name))
File "/data/build/odoo/odoo/models.py", line 5470, in mapped
recs = recs._fields[name].mapped(recs)
File "/data/build/odoo/odoo/fields.py", line 1299, in mapped
return self.convert_to_record_multi(vals, records)
File "/data/build/odoo/odoo/fields.py", line 942, in convert_to_record_multi
return [convert(value, record) for value, record in zip(values, records)]
File "/data/build/odoo/odoo/fields.py", line 942, in <listcomp>
return [convert(value, record) for value, record in zip(values, records)]
File "/data/build/odoo/odoo/models.py", line 5844, in __iter__
yield self.__class__(self.env, (id_,), self._prefetch_ids)
RecursionError: maximum recursion depth exceeded
```
**OPW** - 5208462
**UPG** - 3248441
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239840
Forward-Port-Of: odoo/odoo#233358This update resolves an issue where exporting batch payments with mixed payment types (IBAN, Bankgiro, etc.) was generating incorrect XML files. The team reverted a faulty fix and is now focusing solely on generating the necessary zip file, correctly identifying payment types for accurate XML formatting. This ensures reliable batch payment processing for Swedish customers.
Original PR description
Here https://github.com/odoo/enterprise/pull/95463, we add the possibility to export
batch payments with mixed IBAN and Bankgiro/Plusgiro/BBAN payments, but this introduced
few bug in the xml format.
The reason is, we were using new custom logics and not the main one. The problem is
the custom logics is wrong, not the main one.
This commit remove most of the custom logics we added and use all the main one.
This has been done by:
1 - Reverting the original commit
2 - Adding only the zip file generation, passing a context key to know if we are
with bban or iban payments.
opw-5181340
Forward-Port-Of: odoo/enterprise#101917
Forward-Port-Of: odoo/enterprise#100014This update resolves an issue where users connected to a POS session couldn't access the backend. Previously, access was limited to the initial session opener. Now, users connected to a POS session can access the backend, ensuring smoother workflow for employees. This improves usability for users working within connected POS environments.
Original PR description
Currently a user that connected to a pos user cannot go backend if he was not the person who opened the session the first time. Steps to reproduce: ------------------- * Modify settings of the shop…
Currently a user that connected to a pos user cannot go backend if he was not the person who opened the session the first time. Steps to reproduce: ------------------- * Modify settings of the shop to use employee feature * Make sure admin and demo can access the shop, set them advenced employee for example. * Logged as Mitchell Admin, open the pos (It should have been closed before) * Use Mitchel admin employee * Complete cash control * Go backend * Log out * Log back in with Marc Demo * Enter the shop (it was already "opened" by Admin) * Use Marc demo employee * Now try to see the backend button > Observation: Backend button is not available Why the fix: ------------ Quoting this commit: https://github.com/odoo/odoo/commit/61df2871e1aac0144d26022a2a49c75ea9ecad4a > Now, the only employees that can go back to the backend are those binded to the user connected. However, `this.pos.session.user_id` only reflects the user who opened the pos the first time, in our case Mitchell Admin. It does not represent the connected user. opw-5276950 Forward-Port-Of: odoo/odoo#239627 Forward-Port-Of: odoo/odoo#238636
This update fixes issues related to how BIS3 export calculations are performed, specifically separating the BIS3 format from UBL dependencies. It introduces new tax helpers to manage tax data more effectively, improving accuracy and flexibility in generating EDI invoices. This change enhances the reliability of BIS3 export functionality.
Original PR description
**[IMP] account: Add new tax helpers for EDI** (backport) task_id: 5096249 **[FIX] account_edi_ubl_cii: Fix management of fixed taxes** (backport) This commit contains 2 things: - an helper to…
**[IMP] account: Add new tax helpers for EDI** (backport) task_id: 5096249 **[FIX] account_edi_ubl_cii: Fix management of fixed taxes** (backport) This commit contains 2 things: - an helper to extract any tax_data and move it to another base_line - the usage of this helper in UBL to turn emptying taxes into additional base_lines == Add helpers to turn tax_data into new base_lines easily == With this helper, you can now exclude any tax from any base line and turn them into new base lines. Also, I changed a bit the smooth distribution of rounding because the math.ceil is sometimes too greedy and make the whole results to be less accurate. == Make a different behavior between recycling contribution taxes / emptying taxes == In UBL, all fixed taxes are treated as allowances/charges. In this commit, we make a clear distinction between recycling contribution taxes that are treated as allowances/charges and emptying taxes that are exempted of tax and are treated as addition invoice lines in the document. == Fix a small issue with aggregate_function passed to reduce_base_lines_with_grouping_function == The aggregator wasn't called when setting the 'target_base_line' at the very first time. task_id: 5182783 **[FIX] account_edi_ubl_cii: Reword export BIS3** - Separate the BIS3 from the annoying dependency between all the UBL files. You are not supposed to generate an UBL 2.0 & 2.1 UBL files. Those are templates with all the options you have to build your format on top of it. However, since we used them as a hierarchy and since most of the code and implementation are inside UBL 2.0, "fixing" any use case for one single implementation has impacts in all others. In order to fix issues about ways amounts are computed in BIS3, we first split BIS3 to be independant from UBL 2.0 / UBL 2.1 but using new generic helpers that could be used for any single format. The future goal will be to make all formats independant but that part is already big enough and we are in a hurry. "To be continued in a next PR" - Reword the test suite for exported files to be more explicit about which test is testing what exactly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239799 Forward-Port-Of: odoo/odoo#238560
5 changes
Enhancements to existing features
This update adds a message to the Account Online link, allowing users to easily revoke consent for the Basiq provider widget. This provides greater control over data sharing and aligns with privacy best practices. It redirects users to a dedicated Odoo page for managing their Basiq consent.
Original PR description
This commit will add a message on the account online link chatter for the basiq provider. This message will allow the user to be redirected to an odoofin page with a button to revoke his consent on a basiq widget task-5187621 Forward-Port-Of: odoo/enterprise#101972 Forward-Port-Of: odoo/enterprise#101801
Resolved issues and error corrections
This update optimizes how the loyalty program calculates potential free products. Previously, the system unnecessarily checked all reward products, even after a valid one was found, leading to slower performance. This change improves the speed and efficiency of the loyalty program, particularly when multiple rewards are involved.
Original PR description
Before this commit, the computation of potential free product quantities looped through all reward products even after finding a valid one. This led to unnecessary calculations and performance degradation, especially when multiple reward products were involved. opw-5268991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239442
This update corrects a bug in the l10n_es_edi_tbai module that prevented the correct generation of the `FechaOperacion` field in TBAI XML invoices. Specifically, when the invoice date and delivery date are set to a past date, the `FechaOperacion` was missing. This ensures compliance with Spanish tax regulations.
Original PR description
With l10n_es_tbai: - Create an invoice with an `invoice_date` and `delivery_date` that are the same and earlier than today. - In the generated TBAI XML, `FechaOperacion` is missing. In the TBAI XML, `FechaExpedicionFactura` corresponds to the date on which the XML is generated. `FechaOperacion` corresponds to the `delivery_date` and should appear whenever it differs from the issue date. The TicketBAI specs define `FechaOperacion` as: > “Date on which the transaction was carried out, whenever it differs from the issue date.” So when the invoice date and delivery date are equal but set in the past, `FechaOperacion` is not generated, even though it should be. opw-4477135 opw-4477135 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#239189
This update resolves an issue where exporting batch payments with mixed IBAN and Swedish payment methods (Bankgiro, Plusgiro, BBAN) was generating incorrect XML files. The team reverted a faulty fix and is now focusing solely on generating the necessary zip file, utilizing the correct payment type context.
Original PR description
Here https://github.com/odoo/enterprise/pull/95463, we add the possibility to export
batch payments with mixed IBAN and Bankgiro/Plusgiro/BBAN payments, but this introduced
few bug in the xml format.
The reason is, we were using new custom logics and not the main one. The problem is
the custom logics is wrong, not the main one.
This commit remove most of the custom logics we added and use all the main one.
This has been done by:
1 - Reverting the original commit
2 - Adding only the zip file generation, passing a context key to know if we are
with bban or iban payments.
opw-5181340
Forward-Port-Of: odoo/enterprise#101917
Forward-Port-Of: odoo/enterprise#100014This update resolves issues related to invoice attachments, specifically when using different EDI formats or sending invoices via email and Peppol. Previously, incorrect display and error messages occurred, now attachments function correctly regardless of the invoice format or sending method selected.
Original PR description
[FIX] account{_edi_ubl_cii, _peppol}: Attachment fix
2 scenarios fixed in this commit :
1:
When a user invoice_edi_format is not 'ubl_bis3' the attachment button is not displayed and the key doesn't exists in the invoice_data. This causes traceback when trying to access the key.
2:
When a user send and print an invoice, with 'email' and 'peppol' as sending_methods, warnings will be displayed next to attachments not supported by peppol.
But if the user uncheck 'peppol', warnings will stay while no sending method requires them anymore.
See odoo/odoo#234339
Forward-Port-Of: odoo/odoo#239769
Forward-Port-Of: odoo/odoo#2396841 change
Enhancements to existing features
This update adds a message to the Account Online link, allowing users to easily revoke consent for the Basiq provider. This provides greater control over data sharing and aligns with privacy best practices. The change redirects users to a dedicated page with a clear revocation button.
Original PR description
This commit will add a message on the account online link chatter for the basiq provider. This message will allow the user to be redirected to an odoofin page with a button to revoke his consent on a basiq widget task-5187621 Forward-Port-Of: odoo/enterprise#101972 Forward-Port-Of: odoo/enterprise#101801
2 changes
Enhancements to existing features
This update adds a message within the Account Online link chatter, specifically for users utilizing the Basiq provider. This allows users to easily revoke their consent for the Basiq widget through a redirect to a dedicated Odoo page, enhancing control over data sharing.
Original PR description
This commit will add a message on the account online link chatter for the basiq provider. This message will allow the user to be redirected to an odoofin page with a button to revoke his consent on a basiq widget task-5187621 Forward-Port-Of: odoo/enterprise#101972 Forward-Port-Of: odoo/enterprise#101801
Resolved issues and error corrections
This update fixes a bug in the Arabic financial reports that was causing incorrect balance calculations due to duplicate account entries. A missing 'DISTINCT' clause in a database query was incorrectly processing multiple account tags, leading to inaccurate report totals. The fix ensures accurate financial reporting for Arabic VAT book exports.
Original PR description
For ease of reuse, we use a CTE to find the operation type of the lines we care about. This works great however, a `DISTINCT ON (aml.id)` was missed on the CTE as if an account had multiple tags associated with it, it would end up appearing multiple times and multiplying the total balance by the number of tags, making the report wrong. We need to use a special CASE in the order by because we want to prioritize the right account tag on the account that way we can properly determine when to set the operation type to whatever it needs to be. The same issue appears in both the purchase and sales exports, so it has been fixed in both queries. opw-5406043 Forward-Port-Of: odoo/enterprise#101875
5 changes
Enhancements to existing features
This update adds a message to the Account Online link, allowing users to easily revoke consent for the Basiq widget. This provides greater control over data sharing and aligns with privacy best practices. It redirects users to a dedicated page with a clear revocation button.
Original PR description
This commit will add a message on the account online link chatter for the basiq provider. This message will allow the user to be redirected to an odoofin page with a button to revoke his consent on a basiq widget task-5187621 Forward-Port-Of: odoo/enterprise#101972 Forward-Port-Of: odoo/enterprise#101801
This update streamlines the bank reconciliation process by automatically triggering reconciliation when records are created through the Kanban or List views, rather than relying solely on manual posting. It also centralizes the auto-processing logic, improving efficiency and reducing manual steps. This change enhances the user experience and simplifies bank statement integration.
Original PR description
this pr will do multiple things: - Remove the calls to the cron when posting the move, now adding through the kanban or list view will trigger the try_auto_reconcile from the create with the auto_statement_processing context key - Tries to unify the auto processing in the create (except in account online sync where we kept the logic since we need the start time to compute the cron limit) no task id
Resolved issues and error corrections
This update fixes a calculation error in financial reports for Arabic-speaking customers. The issue stemmed from a missing 'distinct' clause in a database query, which was incorrectly multiplying account balances. The fix ensures accurate reporting by prioritizing account tags and correctly determining operation types.
Original PR description
For ease of reuse, we use a CTE to find the operation type of the lines we care about. This works great however, a `DISTINCT ON (aml.id)` was missed on the CTE as if an account had multiple tags associated with it, it would end up appearing multiple times and multiplying the total balance by the number of tags, making the report wrong. We need to use a special CASE in the order by because we want to prioritize the right account tag on the account that way we can properly determine when to set the operation type to whatever it needs to be. The same issue appears in both the purchase and sales exports, so it has been fixed in both queries. opw-5406043
This update resolves an issue where exporting batch payments with mixed IBAN and Swedish payment methods (Bankgiro, Plusgiro, BBAN) was generating incorrect XML files. The team reverted a previous, flawed fix and is now focusing solely on generating the necessary zip file, correctly identifying payment types.
Original PR description
Here https://github.com/odoo/enterprise/pull/95463, we add the possibility to export
batch payments with mixed IBAN and Bankgiro/Plusgiro/BBAN payments, but this introduced
few bug in the xml format.
The reason is, we were using new custom logics and not the main one. The problem is
the custom logics is wrong, not the main one.
This commit remove most of the custom logics we added and use all the main one.
This has been done by:
1 - Reverting the original commit
2 - Adding only the zip file generation, passing a context key to know if we are
with bban or iban payments.
opw-5181340
Forward-Port-Of: odoo/enterprise#101917
Forward-Port-Of: odoo/enterprise#100014This update enhances the accuracy of tax calculations within the bank reconciliation widget. It prevents accidental tax line deletions, automatically creates tax lines when default taxes are added, and ensures correct tax recomputation across various scenarios, improving the reliability of financial reporting.
Original PR description
This commit will do multiple things: - Prevent users from deleting a tax line - Adding default taxes on an account will create a tax line for it - Removing a taxes from a line will recompute the taxes correctly - Removing and adding new taxes will recompute the taxes correctly - Removing a base line that has a tax linked to it will recompute the taxes correctly - Add a simple way for users to delete the tax directly from the ui without going to the edit line button task: 5081786 Forward-Port-Of: odoo/enterprise#101858 Forward-Port-Of: odoo/enterprise#94552
2 changes
Resolved issues and error corrections
This change resolves an issue preventing the export of invoice lines without associated products to the WSFEX service. The update now automatically assigns a generic unit of measure when a product is missing, ensuring accurate data transmission. This improves the reliability of export processes for Arabic VAT invoices.
Original PR description
Before this change we ware not able to send to Exportation WS an invoice line that have not product because the unit or measure was empty in the webservice request. we this change we force that if we do not have any product then we will send a generic unit of measure.
This update resolves an issue where tax grouping keys in the account_edi_ubl module could sometimes be unexpectedly empty (None). This fix ensures accurate tax calculations and reporting, particularly when using customizations. Additionally, a minor correction was made regarding excise taxes.
Original PR description
Some overrides assign a value to the tax's grouping_key after the super call. However, the returned value could be None. Also fix a little mistake regarding excise taxes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr