Thursday, April 10, 2025
10 changes · 17.0
Resolved issues and error corrections
This fixes an issue where incoming invoice attachments could store the same file data more than once. It helps avoid unnecessary duplicate attachment content and keeps accounting document processing cleaner.
Original PR description
The missing break was duplicating the file_data. For example, the PDF was there in PDF but also in binary. opw-4510745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how Indian vendor bills are completed after scanning a QR code. It now uses GST details correctly and ignores unnecessary fields, helping reduce incorrect or incomplete bill information.
Original PR description
In 120e0bb7b82a3628caa468af5a6fa3b6730d6485, we went a bit too fast regarding the QR code scan for bills in India. This commit fixes this by calling the `enrich_by_gst` on the right model and discarding useless fields. task-none
Swiss payroll ELM transmission now automatically fills in an employee number using the employee's record ID when no number is provided. This prevents missing employee numbers from disrupting payroll reporting and reduces manual data entry.
Original PR description
…ployee number We add a default value for the employee number based on the employee id
This update fixes a missing insurance code in the Swiss payroll ELM transmission process. It helps ensure payroll insurance data is correctly included in electronic submissions, reducing the risk of incomplete or rejected reporting.
Original PR description
… by making lambda selection
Documentation and clarification updates
This pull request updates the contributor license agreement record for etobella by adding a new email address. It helps keep legal contribution records accurate and up to date, with no impact on Odoo product features or users.
Original PR description
Description of the issue/feature this PR addresses: Added my new email on the CLA 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
Miscellaneous changes
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Vendors / Bills" - Upload a PDF having an embedded factur-x XML with no tax or a tax that doesn't exist in the database **Issue:** The bill generated from the embedded XML has the default purchase tax set on it. **Cause:** At the beginning of the process, an empty account move is created and then it is populated with the data retrieved from the XML. At the creation of the account move, the default tax is set. When the
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Vendors / Bills" - Upload a PDF having an embedded factur-x XML with no tax or a tax that doesn't exist in the database **Issue:** The bill generated from the embedded XML has the default purchase tax set on it. **Cause:** At the beginning of the process, an empty account move is created and then it is populated with the data retrieved from the XML. At the creation of the account move, the default tax is set. When the taxes are populated, if there is no tax or if it doesn't exist, "tax_ids" fields of the account move line is set to the empty list (i.e. []). However, if "tax_ids" has already a value (e.g. the default tax), setting it to `[]` will not remove it, unlike `False`. opw-4600822 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205498
Partial backport of #202835 Nicer strategy for stable to avoid braking all existing clients tests This should catch most case without introducing a lock and a mandatory allowance of the request. - If the cookie is present, check if it is valid (request opening cursor in next test) - Check if the test cursor was opened in the same test as the execute/rollback (request started in previous test executing in next) - custom expected cookie for browser js to avoid allowing a request after w
Original PR description
Partial backport of #202835 Nicer strategy for stable to avoid braking all existing clients tests This should catch most case without introducing a lock and a mandatory allowance of the request. - If…
Partial backport of #202835 Nicer strategy for stable to avoid braking all existing clients tests This should catch most case without introducing a lock and a mandatory allowance of the request. - If the cookie is present, check if it is valid (request opening cursor in next test) - Check if the test cursor was opened in the same test as the execute/rollback (request started in previous test executing in next) - custom expected cookie for browser js to avoid allowing a request after wait_remaining_requests All message could be silenced to kill the transaction without braking the test if it is a better strategy. Some design choices: - current_test is passed to Testcursor to avoid to add an import to odoo modules in sql_db, only impacts test logic. Parameter is optional. - test cursor checks current_test before each operation (execute, commit, rollback). - http_request_key is the test itself (between setup and cleanup), only exception is for browser js to avoid request executing during the end of the test (once browser is closed). It is the most common case. Forward-Port-Of: odoo/odoo#205190
Before this commit, in Odoo, it was not possible to change an all-day event to a timed event and have it synchronized in Google correctly. This is because were sending to Google both 'date' and 'datetime' info for a single event (since Google stores the previous date and dateTime), which lead to "ERROR 400 Invalid start time." After this commit, the user can successfuly update a timed event to all-day event and vice versa and get it successfully updated in Google, since we now send 'date' as
Original PR description
Before this commit, in Odoo, it was not possible to change an all-day event to a timed event and have it synchronized in Google correctly. This is because were sending to Google both 'date' and 'datetime' info for a single event (since Google stores the previous date and dateTime), which lead to "ERROR 400 Invalid start time." After this commit, the user can successfuly update a timed event to all-day event and vice versa and get it successfully updated in Google, since we now send 'date' as null when the event is timed and 'dateTime' as null when it is an all-day event. task-3965107 Forward-Port-Of: odoo/odoo#177549
Description of the issue/feature this PR addresses: As a result of the following commit 9a6b8fec280ccf63b14d3fdafdd39f534c54c646 normal users attempting to print invoices in SA company where the invocie has been ZATCA verified, are getting errors if they have insufficient access rights; for instance a normal user who has POS User access and Accounting/Billing is unable to generate PoS orders as they are forced to have the invoice checkbox set in the `l10n_sa_pos` and when the invoice is generat
Original PR description
Description of the issue/feature this PR addresses: As a result of the following commit 9a6b8fec280ccf63b14d3fdafdd39f534c54c646 normal users attempting to print invoices in SA company where the…
Description of the issue/feature this PR addresses:
As a result of the following commit 9a6b8fec280ccf63b14d3fdafdd39f534c54c646 normal users attempting to print invoices in SA company where the invocie has been ZATCA verified, are getting errors if they have insufficient access rights; for instance a normal user who has POS User access and Accounting/Billing is unable to generate PoS orders as they are forced to have the invoice checkbox set in the `l10n_sa_pos` and when the invoice is generated it is giving the following Traceback.
Current behavior before PR:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/api.py", line 1013, in get
cache_value = field_cache[record._ids[0]]
KeyError: 415613
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/fields.py", line 1161, in _get_
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/odoo/api.py", line 1020, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'account.edi.document(415613,).attachment_id'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/fields.py", line 1187, in _get_
recs._fetch_field(self)
File "/home/odoo/src/odoo/odoo/models.py", line 3230, in _fetch_field
self.check_field_access_rights('read', [field.name])
File "/home/odoo/src/odoo/odoo/models.py", line 2986, in check_field_access_rights
raise AccessError(_(
odoo.exceptions.AccessError: The requested operation can not be completed due to security restrictions.
Document type: Electronic Document for an account.move (account.edi.document)
Operation: read
User: 40
Fields:
• attachment_id (allowed for groups 'Administration / Settings')
```
Desired behavior after PR is merged:
To Fix the issue and sudo() the access to the edi attachment
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#204912Manual Backport from version 17.0 Original commit d4d06601f107777b843897de07e5be0890a326b3 Origianl PR odoo/enterprise#80169 Forward-Port-Of: odoo/enterprise#82840
Original PR description
Manual Backport from version 17.0 Original commit d4d06601f107777b843897de07e5be0890a326b3 Origianl PR odoo/enterprise#80169 Forward-Port-Of: odoo/enterprise#82840