Daily updates from Odoo
Saturday, December 13, 2025
9 changes · saas-18.4
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