Daily updates from Odoo
Wednesday, January 21, 2026
28 changes · saas-18.2
Resolved issues and error corrections
This update fixes an issue where the 'Import Bank Statement' feature incorrectly selected a journal in multi-company Odoo setups. The change ensures the feature now filters by the currently chosen company, preventing errors and ensuring accurate bank statement encoding. A new test has been added to verify this fix.
Original PR description
Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685 Forward-Port-Of: odoo/enterprise#104326
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable output. The change adds a space to separate the name and description, ensuring invoices comply with API specifications and maintain clear formatting for the Vietnam VAT reporting process. This improves data accuracy and readability.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
This update fixes an issue where VAT import taxes were incorrectly generating journal entries due to a change in account settings. The fix updates the default account used for taxes tax_purchase_import_10, tax_purchase_import_8, and tax_purchase_import_5, ensuring accurate financial reporting.
Original PR description
Due to the change of account 33312 from liability to payable, the journal entries generated when creating bills with VAT import taxes were incorrect. This fix updates the default account on the following taxes: - tax_purchase_import_10 - tax_purchase_import_8 - tax_purchase_import_5 task-5695253 Forward-Port-Of: odoo/odoo#244434
This update strengthens the file upload process by ensuring the service correctly handles various error responses from Odoo controllers. Previously, the system struggled to interpret different API formats (JSON, JSONRPC, HTML), leading to upload failures. Now, the file upload service is more robust and reliable in handling these diverse responses.
Original PR description
Odoo controllers often don't use coherent API they respond with either json, jsonrpc or html. On the client side, we have no reliable way to know this, and sometimes it is not possible to make a guess (rpc.js makes the guess that controllers are of json type -- actually meaning jsonrpc) The file upload service suffered from this and did not handle those error cases well. After this commit, the file upload service handles much of the errors. 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#244704
This update fixes an issue where Odoo was creating duplicate vendor contacts when receiving invoices with slightly different VAT number formats (with or without dots). Now, invoices with the same VAT number, even with variations in formatting, will always be linked to the same contact, streamlining our accounting processes.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update allows store managers to directly create new products within the Point of Sale (POS) interface. Previously, this functionality was restricted to system administrators, limiting store managers' ability to quickly add new items to their inventory. This change improves operational efficiency and responsiveness for retail locations.
Original PR description
Before this commit, only system users could create products from the POS interface. This limited the ability of store managers. opw-5418727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240520
This update optimizes how Odoo's Point of Sale system synchronizes data using IndexedDB. Previously, large datasets like loyalty cards could cause slow synchronization, leading to delays when adding items to a customer's cart. This change significantly improves the speed and responsiveness of the POS experience.
Original PR description
Before this commit, if a model had a large number of records, for example, loyalty card, the synchronization of IndexedDB could be slow, leading to performance issues when adding products to the cart. opw-5232087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241373
This update resolves an issue where accessing settings was blocked when the l10n_ro_edi_stock module was used with the Romanian language selected. The fix corrects a mismatch in the system's text search, ensuring settings are accessible for Romanian users. This improves usability for Romanian-speaking customers.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update prevents excessive email notifications to managers when employees submit expenses. Previously, every state change triggered an email, leading to potential spam. Now, a weekly email is still sent to managers if they have pending expenses, streamlining the approval process and improving user experience.
Original PR description
When an employee submits an expense and assigns a manager, an approval activity is scheduled. However, email notifications are now disabled to avoid spamming the assigned managers. * Prevent notifying the expense manager when expense state changes. * Email 'Next expense is waiting your approval' is scheduled to be sent to the manager once a week if the manager has any expenses left to approve. task-4676396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update automatically adjusts the start and end dates for salary certificate reporting in Odoo's Swiss accounting module (l10n_ch_hr_payroll). Previously, these dates were static, now they dynamically pull from the configured data, ensuring accurate and up-to-date reporting for Swiss businesses.
Original PR description
make Period until and from dynamic from data Forward-Port-Of: odoo/enterprise#104903
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed a redundant email layout setting, ensuring consistent and correct email formatting for attendees. This improves the overall user experience and email deliverability.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update removes a previous fix for the website slides module, which was no longer needed due to recent changes. This streamlines the code and prevents duplication, ensuring a more efficient and stable user experience for customers.
Original PR description
Following the changes in PR #236475, the fix in PR #232696 is no longer required. This commit reverts commit 4c02c970ed824e2b1ade90b905365519044abc69, ensuring that the fix remains within the portal_rating module and preventing duplicate code for the same issue. This change should be forward ported up to saas-18.2. For later versions, the revert is already handled in PR #243783. Forward-Port-Of: odoo/odoo#244057
This update resolves a visual glitch on mobile websites where the header would briefly scroll off-screen when returning to the top. The fix ensures the header's styling is correctly synchronized, preventing a momentary horizontal scrollbar. This improves the user experience and ensures consistent appearance across languages.
Original PR description
There was an horizontal scrollbar that would appear for a short time after scrolling back to the top of the page. This would occur because the header would still have the "transform" property but the class "o_header_affixed" was already removed. To fix the issue, the header transform is now applied using dynamicContent, to synchronize the style and class correctly. This requires the standard header to have "transition: none" applied after it is scrolled since "translate(0, -100%)" would trigger an animation when hiding the header. task-5155878
This update resolves an issue where archived journals were still appearing as selectable payment methods when creating company expenses. The fix ensures that only active journals are displayed, preventing users from selecting inactive or archived options. This improves data accuracy and simplifies the expense creation process.
Original PR description
Steps to Reproduce: 1. Go to Accounting > Configuration > Journals 2. Archive a Journal with outgoing payment method 3. Go to Expenses > Create an Expense paid by company 4. Note that payment methods…
Steps to Reproduce:
1. Go to Accounting > Configuration > Journals
2. Archive a Journal with outgoing payment method
3. Go to Expenses > Create an Expense paid by company
4. Note that payment methods from archived journal are still visible and can be selected.
Issue:
- Archived journals with outbound payment methods were still selectable when creating company-paid expenses.
- Due to this [commit](https://github.com/odoo/odoo/commit/5c9a6704dd54bbbde1703850619ddcc1a3552547) The journals can be archived without system prevention as the action_archived method has been removed.
Solution:
- This occurred because selectable_payment_method_line_ids did not filter out inactive journals when falling back to a generic search. -Aligning the search domain with
[company_expense_allowed_payment_method_line_ids]
(https://github.com/odoo/odoo/blob/19.0/addons/hr_expense/models/res_company.py#L20) by excluding payment method lines linked to inactive journals.
Before Fix:
```py
In [1]: expense = self.env['hr.expense'].browse(1639)
In [2]: expense.selectable_payment_method_line_ids
Out[2]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [3]: archived_journal_ids = []
In [4]: payment_method_lines = self.env['account.payment.method.line'].search([
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ])
In [5]: payment_method_lines
Out[5]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [6]: for payment_method_line in payment_method_lines:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids.append(payment_method_line.journal_id.id)
...:
In [7]: archived_journal_ids
Out[7]: [7, 8]
```
After Fix:
```py
In [8]: payment_method_lines_with_fix = self.env['account.payment.method.line'].search([
...: # The journal is the source of the payment method line company
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ('journal_id.active', '=', True),
...: ])
In [9]: payment_method_lines_with_fix
Out[9]: account.payment.method.line(153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [10]: archived_journal_ids_with_fix = []
In [11]: for payment_method_line in payment_method_lines_with_fix:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids_with_fix.append(payment_method_line.journal_id.id)
In [12]: archived_journal_ids_with_fix
Out[12]: []
```
OPW-5461359
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-prThis update resolves an issue where invoices sent to Peppol failed validation due to an incorrect UNECE code. The fix removes a specific code ('HD') that was causing the error, ensuring invoices comply with Peppol standards and preventing delivery failures.
Original PR description
**Steps to reproduce:** - Use a Belgian company - Create a Belgian contact with "EU Standard (Peppol Bis 3.0)" as eInvoice format - Create an invoice for that customer with a product using "Pack of 6" as unit of measure - Confirm the invoice - Send it to Peppol **Issue:** The validation of the invoice fails with the following error: "[BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21 extension" **Cause:** The UNECE code used for "Pack of 6" UoM is "HD". "HD" is a correct UNECE code for "Half Dozen". However, it is not part of the subset of codes accepted by Peppol. opw-5463212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where invoices couldn't be processed correctly when multiple payment methods shared the same code. The fix ensures payment method codes are read-only to prevent conflicts and adds a database constraint to enforce unique codes, ensuring accurate CFDI invoice generation for Mexican businesses.
Original PR description
Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method. Steps to replicate: - Install `l10n_mx_edi` and…
Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method.
Steps to replicate:
- Install `l10n_mx_edi` and `accountant` with demo and switch to `ZAPATERIA URTADO ÑERI` (Mexican company).
- Go to `Accounting > Configuration > Payment Way Codes (MX)`.
- Open `Efectivo` and change its code to `02`.
- Create a new Invoice, select `Efectivo` in the Payment Way.
- Add a customer and a move line, then confirm the invoice and send it (make sure CFDI is checked).
Error:
```
File '/home/odoo/src/enterprise/19.0/l10n_mx_edi/models/account_move.py', line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
File '/home/odoo/src/odoo/19.0/odoo/orm/fields.py', line 1659, in __get__
record.ensure_one()
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(1, 22)
```
Cause:
- Issue originated through this [PR] that gave access to write on the model.
- As the user made the codes of two payment methods same, the [search] returned two records and while accessing `payment_method.name` on two records it results into this error.
Solution:
- Made the fields read-only via XML to prevent users from changing the payment method codes established by the Mexican government.
- Added limit to the search query to prevent multiple records. (for existing DBs that might have changed payment method codes).
- Removed unlink rights on the `l10n_mx_edi.payment.method` model.
- Added a SQL constraint to allow only unique values for the code.
[PR]: https://github.com/odoo/enterprise/pull/38046
[search]: https://github.com/odoo/enterprise/blob/18117c6a9fbf270ace1c551616828a85713d5225/l10n_mx_edi/models/account_move.py#L423
sentry-7171030995
Forward-Port-Of: odoo/enterprise#103944This update corrects a technical issue where a function was being called in the wrong module, causing a potential error during payroll document creation. The fix involves redirecting the call to the correct module, ensuring documents are generated reliably. This resolves a minor operational issue.
Original PR description
Issue: `_check_create_documents` is called in 'hr_payroll' but only defined in 'documents_hr_payroll' Solution: Create a new method that will be redefined in 'documents_hr_payroll' to call `_check_create_documents` opw-5213979
This pull request updates the core spreadsheet library used in Odoo. It includes several bug fixes and improvements related to exporting, calculations, and chart rendering, ensuring data accuracy and stability within Odoo's spreadsheet functionality. These changes enhance the overall performance and reliability of the spreadsheet module.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2d9316bb99 [REL] 18.2.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2d9316bb99 [REL] 18.2.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/606cc9dbbc [FIX] Actions: ensure the sequence is applied on action children [Task: 5452669](https://www.odoo.com/odoo/2328/tasks/5452669) https://github.com/odoo/o-spreadsheet/commit/919525efb7 [PERF] evaluation: don't spread single element matrix [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138) https://github.com/odoo/o-spreadsheet/commit/63f1622dfe [FIX] evaluation: remove spread relation [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138) https://github.com/odoo/o-spreadsheet/commit/c17f9142b8 [FIX] vectorization: fix error message on size mismatch [Task: 5331324](https://www.odoo.com/odoo/2328/tasks/5331324) https://github.com/odoo/o-spreadsheet/commit/907fd22491 [FIX] chart: ignore NoChanges in gauge/scorecard side panel errors [Task: 5478288](https://www.odoo.com/odoo/2328/tasks/5478288) https://github.com/odoo/o-spreadsheet/commit/bad09a586f [IMP] xlsx: export clip [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) https://github.com/odoo/o-spreadsheet/commit/e89a1d3959 [IMP] export: export align left when the cell content is a number; [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) https://github.com/odoo/o-spreadsheet/commit/2312e15a4b [FIX] header_size: wrong row size from wrapped number [Task: 4878338](https://www.odoo.com/odoo/2328/tasks/4878338) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where invoices sent to Viettel's SInvoice system were being rejected due to incorrect decimal formatting. The fix ensures invoices accurately reflect tax amounts by using the currency's standard rounding method, preventing API errors and improving invoice processing.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845) Forward-Port-Of: odoo/odoo#244647
This update ensures that delivery carriers are consistently applied across all picking steps, regardless of how they're initially set (sale order or manually). This change addresses a previous limitation where carriers weren't propagated when set on a picking, now enabling logistics teams to manage carrier selection effectively.
Original PR description
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set…
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set on a picking (e.g., during the packing step in a multi-step delivery flow), it was not propagated to the consequent pickings, even when the stock rules had `Propagation of carrier` enabled. Steps to reproduce: ================================ 1. Activate Multi-Step Routes and Delivery Methods. 2. Configure a 3-step delivery route in the warehouse and enable Propagate Carrier on all rules. 3. Create a sale order with a product but without setting a delivery carrier. 4. Confirm the sale order to generate picking. 5. On the first picking (i.e., pick), manually set a delivery carrier (e.g., Local Delivery) and validate. 6. On the next transfer (i.e., pack), observe that the delivery carrier is not propagated. After this commit: ================================ The delivery carrier set on any picking is propagated to subsequent transfers when the corresponding stock rule has `Propagation of carrier` enabled and no carrier is already configured on the next picking. This ensures consistent carrier propagation across all routing configurations (all pull rules, all push rules, and mixed push/pull flows), even when the carrier is configured at the picking level rather than on the sale order. This behavior is required because, in many business scenarios, carrier selection is managed by the logistics team rather than the sales team. task-4454313 Forward-Port-Of: odoo/odoo#202700
This update resolves an issue where the 'Pending' button in the manufacturing order process incorrectly stopped productivity records for all employees involved, instead of just the current one. The fix ensures that only the productivity record associated with the currently logged-in employee is stopped, improving workflow efficiency.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Create a new operation OP1
- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending
Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to
The `button_pending` method was stopping productivity records for all employees linked to the work order.
opw-5453752
Forward-Port-Of: odoo/enterprise#103553This update resolves a problem where FedEx labels incorrectly displayed addresses containing special characters (like accented letters). The code has been updated to ensure all address components are converted to standard ASCII characters before being sent to FedEx, preventing display errors on labels. This ensures accurate and consistent address formatting for all shipments.
Original PR description
Issue ----- Fedex does not handle special characters in addresses, so passing an address such as "Rue de Libération 15" will show as "Rue de Lib...ration 15" on labels. ----- Ticket: opw-5419724 Forward-Port-Of: odoo/enterprise#104265
This update fixes an issue where deleting recurring calendar events caused the application to reset filters and lose context-specific settings, disrupting new record creation. The change prevents full page reloads during deletion, ensuring that filters and relevant fields are preserved for a smoother user experience.
Original PR description
Deleting a recurring calendar event triggers a full page reload, which resets the view to default, clearing active filters and causing context-dependent fields (like "Resources") to disappear during subsequent record creation. ### Steps to reproduce 1. Filter the Calendar view (e.g., "Everybody"). 2. Delete a recurring event. 3. Observe the page reload and filter reset. 4. Try to create a new record; context-specific fields are missing. The issue occurs because the deletion action forces a browser refresh (location.reload()), wiping the web client's in-memory state. This state holds the active filters and context keys necessary for rendering specific fields. When cleared, the application reverts to its default configuration. opw-5433604 Forward-Port-Of: odoo/odoo#243487
This update resolves an issue where Mexican CFDI invoices generated with Solution Factible were being rejected due to incorrect exchange rate precision. The fix applies a rounding rule previously implemented for other PACs, ensuring invoices with larger payment values are now processed correctly. This prevents invoice rejection and ensures compliance with Mexican tax regulations.
Original PR description
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line. Forward-Port-Of: odoo/enterprise#104195 Forward-Port-Of: odoo/enterprise#102557
This update fixes a potential issue where Microsoft calendar synchronization could fail due to a short timeout when communicating with Microsoft's services. Now, administrators can adjust a system setting to increase the timeout, allowing for smoother synchronization and preventing duplicate event creation. This improves the overall reliability of calendar syncing.
Original PR description
**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls…
**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time. Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events. **Current behavior before PR:** Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer: • the synchronization fails, • and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo. **Desired behavior after PR is merged:** The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`. If the parameter is not set, the behavior remains unchanged (default 3 seconds). Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244461 Forward-Port-Of: odoo/odoo#241921
This update resolves a potential issue where Microsoft calendar synchronization could fail in slower environments. The change adjusts a timeout setting for Graph requests, allowing the system to handle slower connections without interruption. This improves the reliability of calendar syncing for users.
Original PR description
Microsoft calendar sync can fail in slower environments due to a fixed 3s timeout for Graph requests triggered after commit. See community changes for details. Forward-Port-Of: odoo/enterprise#104916
This update corrects a flaw in the l10n_mx_edi module that prevented timely updates to order documents. By forcing a write-date update, the system now accurately reflects the document's status, ensuring compliance and accurate reporting. This resolves an issue impacting Mexican tax reporting.
Original PR description
Before the commit 8b118a7, the search of the documents to update has been limited and ordered. With the actual domain the records to update will be most of the time the same because is not being updated. To fix this issue we force to update it. OPW-5368047 Forward-Port-Of: odoo/enterprise#103272
This update resolves an issue preventing non-admin website editors from saving images they upload from Unsplash. The fix ensures the user creating the image has the necessary permissions, eliminating a security warning and improving the editor's functionality. It addresses a restriction in how attachments were handled, allowing for smoother image integration within website designs.
Original PR description
Scenario: - Setup Unsplash and install website - Set a user as "Website: Editor and Designer" - Login as that user and go to any website page with a qweb view - Go to edit mode and drop Text-Image in…
Scenario: - Setup Unsplash and install website - Set a user as "Website: Editor and Designer" - Login as that user and go to any website page with a qweb view - Go to edit mode and drop Text-Image in a view - Replace the image with an unsplash image and then save Result: the save fails without any message shown, and there is a security access WARNING in the logs. Note: a similar scenario can be done for a restricted editor that is editing a HTML field it has write access to. Issue: to save a model with res_id 0, we need to either be admin (base.group_system) or the record creator. Since 9c9c58a5a10101532cbf046d21d4a63c2b7d2838 to bypass the mimetype neutering of happening, we create the attachment as SUPERUSER. Then when we modify the attachment url (for unsplash images), we have no access right to the attachment since we are not the creator. Fix: create the attachment with the current user, and only use SUPERUSER to set the mimetype if it was neutered (ie. the user doesn't have write access right to ir.ui.view, which in normal use case should only happen for "Restricted Editor"). This way the image is created by the user that uploaded it and not SUPERUSER. opw-4850611 opw-5387258 opw-5489219 Forward-Port-Of: odoo/odoo#244831 Forward-Port-Of: odoo/odoo#219472