Daily updates from Odoo
Friday, February 27, 2026
24 changes · 17.0
New functionality added to Odoo
This update adds the ability to automatically process and export Peppol self-billing invoices, streamlining invoice handling for vendors. It allows for the creation of self-billed invoices based on specific journal settings, improving efficiency in international transactions. This enhancement supports compliance with Peppol standards.
Original PR description
Backport of 8c590efd369b to 17.0. In existing modules, added ability to receive via Peppol and decode BIS3 self-billing invoices as sale invoices. In new module account_peppol_selfbilling, added ability to export self-billed invoices and send them via Peppol. Vendor bills are considered to be self-billed invoices if they are created in a journal where the `is_self_billing` field is True. task-5865317
Enhancements to existing features
This update enhances the 'Unpaid' bill filter in the accounting module to now include draft vendor bills, providing a more complete view of outstanding payments. Additionally, the system now correctly filters out journal entries from the 'Unpaid' filter, ensuring accurate reporting. This improves financial visibility and reporting accuracy.
Original PR description
In this commit: - Updated the `Unpaid` filter to show draft bills in addition to posted bills. The filter now includes all non-cancelled bills with payment status `Not Paid` or `Partially Paid`. - Backported the logic from 18.0 to ensure journal entries are filtered out by checking that type is not equal to `journal_entry`. task-5900283
This update significantly speeds up a core process within Odoo that identifies relevant bank accounts for financial reporting. By optimizing the data retrieval method, the system now completes this task in milliseconds instead of seconds, leading to faster reporting and a smoother user experience. This change focuses on internal performance improvements.
Original PR description
Before this commit, retrieving the `account_ids` from the properties in the method `_get_default_amls_matching_domain` involved searching for all the properties and calling the method `get_by_record` on each record. The `accounts` were fetched only to get the ids to add them to the `blaclisted_stock_account_ids`. Since, the domain had the condition `value_reference != False`, and the field holds the model name and the id of the record, we can directly fetch the `ids` by doing a read_group to eliminate possible duplicates and add the ids to a set of `account_ids`. This will eliminate a search to every record of the `properties` fetched which will improve the performance significantly. The benchmark done below was on a database that fetched **15630** properties and it was only tied to **two** accounts. | Scenario | Time (seconds) | |-----------|----------------| | **Before** | **7s** | | **After** | **27ms** | opw-5868236
Resolved issues and error corrections
This update resolves a warning generated during testing related to fake PDF content. The change replaces these fake files with a minimal PDF file, ensuring consistent test results and preventing potential issues with the PyPDF library. This improves the reliability of our testing process.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278
This update corrects a problem with how leave periods are calculated, specifically related to time zone differences. By using `request_date_from` and `request_date_to`, the system now accurately reflects leave interruptions, ensuring correct payroll processing for employees in Switzerland. This resolves potential discrepancies and improves data accuracy.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences. task-5966780
This update resolves an issue where importing data files with incorrect field definitions would cause a system error. The fix ensures that the system gracefully handles invalid field data during the import process, preventing crashes and improving data import reliability.
Original PR description
This traceback arises when the user imports a file with invalid fields on a model. To reproduce this issue: 1) Import a file with an invalid field ex:-(`in_group_44`) for a model (`Users`) Error:-…
This traceback arises when the user imports a file with invalid fields on a model.
To reproduce this issue:
1) Import a file with an invalid field ex:-(`in_group_44`) for a model (`Users`)
Error:-
```
KeyError: 'in_group_44'
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/base_import/models/base_import.py", line 1378, in execute_import
import_result = model.load(import_fields, merged_data)
File "odoo/models.py", line 1220, in load
if isinstance(model_fields[field_name], odoo.fields.One2many):
```
when the user tries to import a file with an invalid filed it leads to a traceback from here
https://github.com/odoo/odoo/blob/be611deca82c0f0e9c110d2ff35f3e081e94b3be/odoo/models.py#L1192
After applying this commit will resolve this issue by raising an exception
sentry-5093791365This update resolves a bug that occurred when users clicked the status bar on Follow-up Reports after excluding certain records. The issue stemmed from a missing data field within the system, preventing proper report rendering. This fix adds a check to ensure the necessary data is present before processing, improving report stability.
Original PR description
This traceback occurs when the user clicks on the `statusbar` of `followup reports` by excluding all `aml's`. To reproduce this issue:- 1) Install `Accounting` 2) Open the `Follow-up-report` from…
This traceback occurs when the user clicks on the `statusbar` of `followup reports`
by excluding all `aml's`.
To reproduce this issue:-
1) Install `Accounting`
2) Open the `Follow-up-report` from `dropdown menu` of
`Customer Invoices` in `accounting onboarding dashboard`.
3) Open any one record by removing the default filter
4) Enable the `Exclude from follow-ups` for all `aml's`
5) Now click on the `status bar`
Error:-
```
KeyError: 1
File "odoo/http.py", line 2256, in __call__
response = request._serve_db()
File "odoo/http.py", line 1832, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1852, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1830, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1837, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2062, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 742, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 76, in web_save
return self.with_context(bin_size=True).web_read(specification)
File "addons/web/models/models.py", line 129, in web_read
vals = many2one_data[values[field_name]]
```
When the user `Excludes` all the `Followups` and clicks on the `status-bar`,
the `web_read` method triggers with a record of `res.partner` having no `followup_line_id`.
Because of that, there will be no `many2one_data` as `extra_fields` are `{}`
values_list is also empty for the recursive call of many2one_data as `co_records` is also
having no recordsets.
Which leads to an exception from the below line (128).
https://github.com/odoo/odoo/blob/0d1399d06bd5ab30918b1a84abccb0f44504a508/addons/web/models/models.py#L116-L128
After applying this commit, it will resolve this issue by adding an extra check of "many2one_data" before assigning the value from many2one_data. Which makes the code more robust.
sentry-4982604710This update resolves a technical issue that prevented users from correctly attaching receipts to expense records. Specifically, a bug caused an error when a user canceled the attachment process. The fix ensures the system handles this cancellation gracefully, preventing a crash and improving the user experience.
Original PR description
A traceback is occurring when the user tries to attach a receipt in the expense To reproduce this issue: 1) Install `hr_expense` 2) Open any existing `my expense` record 3) Click on the `Attach Receipt` button and attach a file 4) Now again attach a file through the `Attach Receipt` button 5) This time click on `cancel` while attaching a file through `Attach Receipt` Error:- ``` IndexError: list index out of range ``` When the user clicks on the cancel button when trying to attach a file, it triggers an `orm` call with `attachments` as an empty list with respected `model` & `action`. Which leads to the above traceback in the backend. After applying this commit, will resolve this issue by checking the length of the file before triggering the form. Which makes code more robust. sentry-4705156379
This update changes how payment errors are displayed to users. Instead of showing a technical exception, the system now presents a standard validation error, making it easier for users to understand and correct issues. This improves the overall user experience and reduces confusion.
Original PR description
Currently, we are showing an exception to the end user when the transaction operation fails from the below line https://github.com/odoo/odoo/blob/8b035af881a72048027072743f7ba80accd73109/addons/payment/controllers/post_processing.py#L57 Error: ``` Exception: retry ``` Which is not a valid case to show traceback to the end user, Instead of a traceback, it's better to raise a validation error. After applying this commit, the message should be shown as ValidationError sentry-5512362745
This update resolves an issue that occurred when a user deleted a warehouse and then attempted to create a new scrap. The fix prevents a traceback by ensuring a valid warehouse is selected during scrap creation, improving data integrity and preventing errors.
Original PR description
Currently, a traceback occurs when the user deletes a warehouse and tries to create a new scrap. To reproduce this issue: 1) Install `stock` without demo data 2) Archive the `warehouse` from the…
Currently, a traceback occurs when the user deletes a warehouse and tries to create a new scrap.
To reproduce this issue:
1) Install `stock` without demo data
2) Archive the `warehouse` from the stock configuration
3) Now create a new `Scrap` from `Inventory/Operations`
Error:-
```
KeyError: False
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1006, in onchange
todo = [
File "addons/web/models/models.py", line 1009, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1122, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6610, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 2954, in __get__
return super().__get__(records, owner)
File "odoo/fields.py", line 1206, in __get__
self.recompute(record)
File "odoo/fields.py", line 1421, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1394, in apply_except_missing
func(records)
File "odoo/fields.py", line 1443, in compute_value
records._compute_field_value(self)
File "addons/mail/models/mail_thread.py", line 416, in _compute_field_value
return super()._compute_field_value(field)
File "odoo/models.py", line 4936, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 100, in determine
return needle(*args)
File "addons/mrp/models/stock_scrap.py", line 38, in _compute_location_id
res = super(StockScrap, remaining_scrap)._compute_location_id()
File "addons/stock/models/stock_scrap.py", line 74, in _compute_location_id
scrap.location_id = locations_per_company[scrap.company_id.id]
```
When the user tries to create a new scrap without a warehouse a traceback occurs, because in the below lines `locations_per_company` is getting through the warehouse.
If there is no warehouse for that company the `locations_per_company` will be empty.
which leads to the above traceback when fetching a value from `locations_per_company`.
https://github.com/odoo/odoo/blob/0ac43fa3cffce83e88accda435f3315600af558a/addons/stock/models/stock_scrap.py#L64-L74
After applying this commit, it will resolve this issue by raising an usererror when there is no `locations_per_company`
sentry-5631303884This update resolves an issue where new sale orders were created without a specified Incoterm. The change ensures that the company's default Incoterm is automatically applied when a new sale order is created, streamlining the sales process and improving data consistency. This prevents manual entry of Incoterms and reduces potential errors.
Original PR description
Currently, when creating a new sale order Incoterm value remains empty. <b>Steps to reproduce:</b> 1) Install sales, stocks, and enable incoterms for sales in settings 2) Give the default Incoterms value in the settings 3) Try to create a new SO record <b>Issue:-</b> Even after providing the default incoterm value in the settings, The value of incoterm remains empty while creating the SO. <b>Solution:-</b> Give the company incoterm value as the default incoterm in the definition of incoterm in sale order. opw-4700346
This update fixes a bug that occurred when users entered a maximum appointment duration. The issue caused a system error due to an overly large number being processed. This change ensures the system can correctly handle maximum duration values without crashing, improving the user experience when scheduling appointments.
Original PR description
A traceback occurs when the user gives a maximum duration value while updating an appointment. To reproduce this issue: 1) Install appointment 2) Open an appointment record from the grant view of the calendar event 3) Give the maximum duration value 4) Click on preview Error:- ``` OverflowError: Python int too large to convert to C int ``` This is because when the user gives a maximum duration value, it calculates the time from the below. https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/appointment/models/appointment_type.py#L623-L624 This leads to the above traceback because of the duration value sentry-5926537828
This update resolves an issue where creating a new appointment with the maximum allowed duration caused a system error. The fix prevents an 'OverflowError' by correctly handling large duration values, ensuring users can accurately set appointment lengths without disrupting the system. This improves the appointment scheduling process.
Original PR description
A traceback occurs when the user gives a maximum duration value while creating a new calendar event. To reproduce this issue: 1) Install appointment 2) Create a new appointment from the Gantt view 3) Give the maximum duration value Error:- ``` OverflowError: Python int too large to convert to C int ``` This is because when the user gives a maximum duration value it is used to calculate the time from the below. https://github.com/odoo/odoo/blob/a4c46f358401077a65106a6172b2a636755d41aa/addons/calendar/models/calendar_event.py#L369 This leads to the above traceback because of the duration value sentry-5926537828
This update resolves a bug that caused an error when users attempted to access the website after deleting all websites within the Odoo system. The fix ensures a minimum website requirement is maintained, preventing the 'ValueError: Expected singleton: website()' error. This improves website functionality for all users.
Original PR description
Currently, a traceback occurs when the user deletes all the websites and tries to open the website. To reproduce this issue: 1) Install the website 2) Delete the default website from external identifiers in settings/technical 3) Now delete all websites from website/configuration/websites 4) Tries to access or open the website Error:- ``` ValueError: Expected singleton: website() ``` Initially, there is a check for at least one website while uninstalling the websites, But after the below commit the code is changed only to check for the default website. But if the user deleted the external identifier of the default website and deleted all the websites it leads to a traceback. https://github.com/odoo/odoo/pull/113405/commits/60adaf5632ddfe3f68da369a2e9642ad639da37e After applying this commit, it will resolve this issue by ensuring at least one website is required. sentry-5900356108
This update corrects a technical issue that prevented users from uploading files without a name, resulting in a traceback error. By providing a default value, the system now handles this scenario gracefully, ensuring a smoother user experience.
Original PR description
Currently, a traceback may arise when the user uploads a file with no name. Error:- ``` TypeError: Web_Editor.add_data() missing 1 required positional argument: 'name' ``` When the value of the `name` we get from the RPC call is `undefined`, we get this traceback on the backend. If there is no `name`, this case is already handled in the python side https://github.com/odoo/odoo/blob/6838782baf222db4591edce5fe80f5af3a39810c/addons/web_editor/controllers/main.py#L261-L266 So by just giving the fallback value if there is no name, we can resolve this issue. sentry-5741581459
This update resolves a technical issue that caused a traceback when users removed the UOM from Sale Order Lines. The fix ensures the UOM is correctly handled during price calculations, preventing errors and improving data accuracy. This impacts the pricing of sales orders.
Original PR description
Currently, a traceback occurs when the user removes the UMO from the Sale Order Line. To reproduce this issue: 1) Install `sale` 2) Enable `UOM`, and `Pricelist` with advanced rules from sales…
Currently, a traceback occurs when the user removes the UMO from the Sale Order Line. To reproduce this issue: 1) Install `sale` 2) Enable `UOM`, and `Pricelist` with advanced rules from sales configuration 3) Create a new pricelist with a `price rule` of `discount` and make sure to change the `discount policy` to `without_discount` from the pricelist configuration 4) Now create a new `Quotation` with the pricelist 5) Remove the `UOM` from the Order Lines and update the Quantity Error:- ``` ValueError: Expected singleton: uom.uom() ``` When the user removes UOM from the SOL it triggers a compute method `_compute_discount` through which another method `_get_pricelist_price`. https://github.com/odoo/odoo/blob/d83bd4f8970e5495205cf2fa583d9343368b5d70/addons/sale/models/sale_order_line.py#L518-L522 In the second method, UMO is used to compute the price for the `pricelist item`, but in that `_compute_price`, `uom.ensure_one()` is used. Which leads to the above traceback. https://github.com/odoo/odoo/blob/d83bd4f8970e5495205cf2fa583d9343368b5d70/addons/product/models/product_pricelist_item.py#L362-L364 By applying this commit will resolve this issue by taking UOM from product, which is a required field in product. sentry-5537497781
This update resolves an issue where users experienced a type error when creating payroll pay slips with contracts that lacked an end date. The fix adds a necessary check to ensure the correct data types are used, preventing the error and allowing users to successfully generate pay slips. This improves the reliability of the payroll process.
Original PR description
Currently, a traceback occurs when the user tries to create a pay slip with a contract and without an end date. To reproduce this issue: 1) Install `hr_payroll` without demo data 2) Create a new record for `payroll/payslip/to pay` 3) Create a new contract then remove the `start date` and change the `end date` in the period. 4) An error will occur Error: - ``` TypeError: '<' not supported between instances of 'bool' and 'datetime.date' ``` Here in the below line, you can see that when the user only gives an end date and have a contract it leads to a type error. https://github.com/odoo/enterprise/blob/3f1c5535235646c0444acffe0bf4ecf756b6b73c/hr_payroll/models/hr_payslip.py#L1002-L1003 Note:- If the contract has an end date and the user gives the end date in the period, it also leads to Typeerror from different lines. After applying this commit, it will resolve this issue by doing an additional check. sentry-5635149758, 5405887212
This update fixes an error in the Timesheet/Planning Analysis report that incorrectly calculated hours for shifts starting or ending outside of regular workday times. The system now accurately determines the actual overlap between shifts and work schedules, ensuring more precise time tracking and reporting. This improves the reliability of time data used for payroll and analysis.
Original PR description
When a multi-day planning shift starts later than the workday start time or ends earlier than the workday end time, the Timesheet/Planning Analysis report was incorrectly calculating hours for those partial days. Before: - V17: Showed full working day hours (8h) for all days, resulting in incorrect totals - The system divided allocated_hours evenly across working_days_count, ignoring actual shift start/end times After: The report now calculates the actual time overlap between the shift and the working schedule for each specific day by: - Finding the intersection of shift times with work attendance periods - Excluding lunch breaks (day_period != 'lunch') - Computing actual hours worked per day instead of dividing evenly - Applied same logic to planned_hours, planned_costs, and difference fields - Added COALESCE to handle NULL values safely opw-5126359
This update resolves an issue where the Odoo system incorrectly warned users about links to Google Shared Drive files, even when accessible. The fix adds a setting to the Google Drive API request, allowing the system to properly access files within Shared Drives. This ensures users can seamlessly integrate content from Shared Drives into their courses.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Go to eLearning > Courses > select a course > Add Content 3. Paste a public link that belongs to a file located in a Google `Shared Drive` Issue: - The system shows a warning `Your file could not be found on Google Drive, please check the link and/or privacy settings` even if the link is accessible via a browser in incognito mode. Cause: - The Google Drive API restricts the search scope to the user's personal `My Drive` by default It filters out items located in Shared Drives unless the client explicitly signals Solution: - Add `params['supportsAllDrives'] = 'true'` to the API request opw-5424413
This update resolves a performance issue that caused the editor to slow down or freeze when editing large documents. The fix eliminates a redundant check, significantly reducing the time it takes for editor interactions and improving the overall user experience. This change enhances the usability of the editor for users working with complex content.
Original PR description
Problem: When editing heavy content, each interaction can take up to 600 ms, sometimes freezing the editor completely. Cause: The `_isDirty` check is computationally expensive and is executed on…
Problem: When editing heavy content, each interaction can take up to 600 ms, sometimes freezing the editor completely. Cause: The `_isDirty` check is computationally expensive and is executed on every history step. This is unnecessary and leads to poor performance when handling large documents. Solution: Instead of recomputing `_isDirty` on each history step, directly mark the field as dirty whenever a history step is triggered. This provides a simpler and more efficient approach. Before fix: Each keyboard interaction to next paint takes around 200ms. <img width="582" height="306" alt="image" src="https://github.com/user-attachments/assets/bb215a97-f651-4e39-8419-06953aba2b8d" /> After fix: Each keyboard interaction to next paint takes around 40ms. <img width="610" height="178" alt="image" src="https://github.com/user-attachments/assets/1ff9ca36-457b-4015-9f30-4fed990c2ba3" /> opw-5892291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the Knowledge HTML field continues to function as expected by maintaining the legacy dirty check mechanism. Previously, a change in the system's logic caused workflow inconsistencies. The fix involves adjusting the associated test to accurately reflect the Knowledge field's behavior.
Original PR description
Knowledge relies on the previous dirty check mechanism, and switching to the new simplified logic introduced inconsistencies in its workflow. To preserve the expected behavior, the Knowledge HTML field continues to use the legacy `_isDirty` mechanism. Additionally, the related test was using the standard `html_field` widget for convenience, since `knowledge_html_field` includes WYSIWYG helpers and comment features that are irrelevant for the test. Now that `_isDirty` differs between the two widgets, the test must explicitly patch `_isDirty` to align with the Knowledge behavior and properly validate the intended scenario. opw-5892291
This update corrects a bug in the Hungarian tax audit export process. Previously, changes to invoice data were unintentionally saved to the database, causing potential data inconsistencies. By ensuring data is flushed to the database before and after savepoints, this fix prevents these errors and maintains data accuracy.
Original PR description
At the moment, the Hungarian tax audit export wizard's `action_export` creates a savepoint with `flush=False`. The intention of this savepoint is to roll back the changes to `l10n_hu_edi_invoice_chain` once the savepoint exits. But because the changes to `l10n_hu_edi_invoice_chain` stay in cache, and the cache is not flushed before the savepoint is created nor cleared afterwards, those changes end up being committed to DB. Which is precisely what the savepoint was there to prevent. Solution: we use `flush=True` to make sure the cache is flushed before and cleared after the savepoint. task-none
This update resolves an issue where invoices sent to accounting partners (APs) were being rejected due to incorrect Electronic Address System (EAS) and Endpoint data. The fix prevents automatic recalculation of these values when VAT information is updated, ensuring invoices are correctly formatted and accepted by AP systems. This improves invoice processing and avoids the need for users to un-register and re-register their companies.
Original PR description
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice…
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice will be refused by the AP. The issue is that the EAS and Endpoint are automatically re-computed when you write on the VAT. It causes issues as the UBL will be filled with the values on the partner, resulting in a non-synchronised SBD and UBL, which will result in all new invoices to be in error. Their only solution would be to revert back the EAS/Endpoint on the partner, which will sometimes be blocked meaning they have to un-register->re-register Also adapt the query count, as we need to do a search in each compute. opw-5923552 opw-5924552 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#249017
This update resolves an issue preventing non-administrator users with 'Editor and Designer' access from adding images from Unsplash. Previously, access restrictions blocked image uploads, now these users can successfully add and save images through the web editor. This improves usability for a wider range of users.
Original PR description
Non admin users with either "restricted" or "editor and designers" access are not allowed to add images using unsplash because they require permission to make changes in the url field in attachment. Steps to reproduce: 1. Login via non admin user with "Editor and Designer" access. 2. Try to edit it via editor and add an image with unsplash. 3. Try saving it. You won't be able to save it due to the access right issue. opw-5221162