Thursday, December 11, 2025
7 changes · 17.0
Enhancements to existing features
This update enhances the Account Online synchronization process by adding a message to the chatter link for the Basiq provider. This message provides users with a direct path to revoke their consent for the Basiq widget, giving them greater control over their data sharing settings. This change supports compliance and user preference management.
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
Resolved issues and error corrections
This update ensures that quantities tracked with serial numbers in Odoo's stock management system remain whole units. Previously, breaking down serial numbers could lead to inaccurate tracking; now, quantities are rounded to the nearest whole number, maintaining data integrity and preventing discrepancies in stock levels.
Original PR description
Main Changes:
Enforce the quantity set on a move or move line with serial tracking to be parts of Whole numbers (in the product UoM).
Before:
It is possible to break a quantity tracked by a serial number
After:
When the user break a quantity tracked by a serial number, we round this quantity as a Whole number in the respective product UoM
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where POS invoices were incorrectly defaulting to the customer's first delivery address instead of the selected delivery address. The change ensures that invoices generated from POS orders accurately reflect the customer's chosen shipping address, aligning with the standard 'sale' module behavior. This improves order accuracy and customer satisfaction.
Original PR description
Currently, an incorrect shipping address is assigned to invoices generated from POS orders when the customer has multiple delivery addresses. **Steps to reproduce:** - Install the `point_of_sale` and…
Currently, an incorrect shipping address is assigned to invoices generated from POS orders when the customer has multiple delivery addresses. **Steps to reproduce:** - Install the `point_of_sale` and `contacts` modules. - Enable `Customer Addresses` from the settings. - Create a contact with `two` delivery addresses. - Open POS and create an order using the `second delivery address` as the customer. - Confirm the order with the `invoice`. - Observe the `shipping address` on the invoice. **Observation:** The invoice incorrectly shows the first delivery address instead of the second delivery address. **Cause:** At invoice creation in POS, only `partner_id` is set and `partner_shipping_id` is missing at [1]. As a result, the invoice defaults to the customer's first delivery address instead of the delivery address selected in POS. **Fix:** This commit adds `partner_shipping_id` to the invoice values to ensure the POS invoice uses the exact delivery address selected during order creation. same as the `sale` module behaviour. [1]: https://github.com/odoo/odoo/blob/1d1cd8648ed1c3f13febbde8d48e28928e18583f/addons/point_of_sale/models/pos_order.py#L667-L684 opw-5350137
This update fixes an issue where recurring product invoices weren't accurately reflecting the correct quantity based on invoice dates. The change ensures that updating invoice dates automatically adjusts the quantity invoiced, improving the accuracy of recurring billing reports. This resolves a previous bug related to zero-value invoice lines.
Original PR description
Quantity invoiced in the case of recurring products signifies the amount present on invoices in the period between the last and the next invoice, thus changing the dates should update the quantity. Also ensures recomputation of the field after the date is changed by action_post. As noted in #85544, the field fails to update correctly when the invoice posted has a line of value 0. Reverts changes from https://github.com/odoo/enterprise/pull/65203 Related discussion: https://discord.com/channels/678381219515465750/687337760452902925/1401885082171740170 Different PR targeting the same issue: https://github.com/odoo/enterprise/pull/85544 Related ticket: opw-4884433
This update allows non-administrator users to access the USPS delivery module by using sudo() to grant necessary permissions. Previously, limited access restricted functionality for users outside the 'system' group. This change ensures broader usability without compromising security.
Original PR description
Non-admin users are currently unable to use the delivery_usps_rest module because several fields are limited to the "base.group_system" group. It's obviously not feasible to give everyone the "Role / Administrator" role. This PR makes necessary sudo() calls the same way that delivery_ups_rest does.
This update fixes a security vulnerability where portal users with existing sales orders could modify their country information. Previously, this restriction was only enforced through the main website interface. Now, the system prevents users from changing their country when an invoice or sale order is associated with their account, ensuring data integrity.
Original PR description
Steps to reproduce: 1. Install website_forum, website_sale. 2. Confirm a Sale Order for a portal user. 3. Log in as the portal user, go to My Account -> Edit Information. 4. Country is in readonly. 5. Go to Forum -> Profile -> Edit 6. Edit the country 7. Nothing stops the user from doing so. --- Description of the issue this commit addresses: If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user. --- Desired behavior after the commit is merged: When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore. --- task-5331916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug in the Point of Sale configuration settings that caused an infinite loop when archiving fiscal positions. The fix ensures that fiscal positions are correctly updated, preventing disruptions to POS operations. This improves stability and reliability for users managing their sales transactions.
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