Friday, June 19, 2026
11 changes · saas-19.3
Resolved issues and error corrections
This update resolves an issue where the Saudi Arabia E-invoicing module installation would fail if certain tax settings were missing. The fix filters out missing taxes during installation, eliminating a previous workaround and ensuring smoother module deployment. This improves the reliability of the module for Saudi businesses.
Original PR description
**Issue:** Installing the l10_sa_edi E-invoicing module causes an error in versions 19.1 and above if any of the taxes in the account.tax-sa.csv are missing. This behavior was previously avoided via the post init function _l10n_sa_edi_post_init(), which no longer works due to the change made to ir_module.py fetching the template data during the module installation (made in commit 64f9dcb). **Reproduction Steps:** Install Accounting Configuration > Settings > Change "Fiscal Localization" to Saudi Arabia Configuration > Taxes > Delete 0% "Not Subject to VAT" tax Try to install l10n_sa_edi Saudi Arabia - E-invoicing **Fix:** Updated '_get_sa_edi_account_tax()to filter out taxes that don't already exist on the database. Removed the_l10n_sa_edi_post_init()` function since it should now be obsolete. Related ticket: opw-6293740 Forward-Port-Of: odoo/odoo#270767 Forward-Port-Of: odoo/odoo#270336
This update resolves an issue that occurred during website theme upgrades. When a custom theme isn't fully supported, the system incorrectly identifies a missing theme manifest, leading to a critical error. This fix ensures the system gracefully handles missing theme manifests, preventing upgrade failures.
Original PR description
After commit 3cbaad4, the theme manifest is now looked up to find addon snippets for the configurator. However, during an upgrade, if a website is configured with a third-party/custom theme whose…
After commit 3cbaad4,
the theme manifest is now looked up to find addon snippets for the configurator. However, during an upgrade, if a website is configured with a third-party/custom theme whose code is not present in the addons path, `Manifest.for_addon()` returns `None` and `_generate_primary_snippet_templates` raises an `AttributeError`:
```py
2026-06-16 03:27:47,155 24126 INFO db_4367932 odoo.modules.loading: loading website/views/new_page_template_templates.xml
2026-06-16 03:27:47,803 24126 WARNING db_4367932 odoo.modules.module: module theme_prime: manifest not found
2026-06-16 03:27:47,845 24126 WARNING db_4367932 odoo.modules.loading: Transient module states were reset
2026-06-16 03:27:47,846 24126 ERROR db_4367932 odoo.registry: Failed to load registry
2026-06-16 03:27:47,846 24126 CRITICAL db_4367932 odoo.service.server: Failed to initialize database `db_4367932`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 605, in _tag_root
f(rec)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 273, in _tag_function
_eval_xml(self, rec, env)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 197, in _eval_xml
result = method(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/website/models/ir_module_module.py", line 704, in _generate_primary_snippet_templates
theme_addons = theme_manifest.get('configurator_snippets_addons', {})
AttributeError: 'NoneType' object has no attribute 'get'
```
We also get the missing manifest logs right before the error.
TBG-2781
[`_generate_primary_snippet_templates`]: https://github.com/odoo/odoo/blob/19.0/addons/website/models/ir_module_module.py#L700
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#270217This update fixes an issue preventing users from accessing payslip lists within the employee departure process. The changes include making fields read-only to prevent unintended modifications and relocating currency data for improved performance. This ensures accurate payslip access and data integrity.
Original PR description
Bug 1: In the departure tab of the Employee, you can't open the payslip list Fix: Added a check to get the correct departure id depending on the model we are in Bug 2: You can select payslips for other employees than the departing employee and the payslips list is not affected Fix: made fields `l10n_be_payslip_n_ids` and `l10n_be_payslip_n1_ids` readonly so they can't be modified in the UI without being saved Bug 3: You get an error because you can't read `currency_id` when opening n payslips (happens when the monetary fields are shown in the list) Fix: moved the `currency_id` to be inside the list instead of the parent form task-id: 6265648 Forward-Port-Of: odoo/enterprise#119402
This update resolves a problem where order signing with Fiskaly failed after the company's API key was updated. The system now correctly resets and recreates the necessary Fiskaly connection details, ensuring orders can be signed without interruption. This prevents disruptions to sales processes for businesses using the Fiskaly integration.
Original PR description
When the Fiskaly API key/secret is changed, the company is bound to a new Fiskaly organization (owner). The SCU and cash registers stored on the company and POS configs were created under the previous owner and no longer exist for the new one, so signing orders fails with E_CASH_REGISTER_NOT_FOUND. Clear l10n_at_pos_company_scuid and each config's l10n_at_cash_regid together with the access token so they are recreated under the new organization on the next authentication. opw-6297695 Forward-Port-Of: odoo/enterprise#120839
This update corrects a bug in how project task rescheduling respects time buffers, particularly when multiple tasks are dependent. The fix ensures that buffers are applied correctly between tasks, preventing scheduling conflicts and maintaining accurate timelines. This improves the reliability of project scheduling.
Original PR description
Steps to reproduce: ---------------------------------------- - Have the company calendar work from 9 to 17 on weekdays - In project gantt view, create tasks with dependencies like this: ``` - [Task…
Steps to reproduce:
----------------------------------------
- Have the company calendar work from 9 to 17 on weekdays
- In project gantt view, create tasks with dependencies like this:
```
- [Task 1] (June 08, 09:00 AM - 10:00 AM) ──┐
├─> [Task 3] (June 11, 09:00 AM - 10:00 AM)
- [Task 2] (June 10, 09:00 AM - 10:00 AM) ──┘
```
- Make sure the "Auto-Reschedule (Keep Buffer)" is selected
- Then reschedule task 1 to `(June 09, 09:00 AM - 10:00 AM)`
- Task 3 is rescheduled to `(June 15, 09:00 AM - 10:00 AM)`
**Expected behavior:**
To respect the buffers, task 3 should have been rescheduled to `(June 12, 09:00 AM - 10:00 AM)`:
- The buffer from task 1 is 23 working hours after `June 09, 10:00 AM` is `June 12, 09:00 AM`
- The buffer from task 2 doesn't affect the rescheduling.
Cause:
----------------------------------------
From `_web_gantt_update_next_candidates_dates()` we call `_get_new_dates()` with `seconds_between_tasks` being the duration of working hours between the end of task 1 and the start of task 3. We also call it with `first_possible_start_date_per_candidate` being the end of task 3 also depends on task 2.
Then `_get_new_dates()` counts the working hours from `first_possible_start_date_per_candidate` until it reaches `seconds_between_tasks`. Which means the buffer between task 1 and task 3 is actually applied between task 2 and task 3.
Solution:
----------------------------------------
The value contained in `first_possible_start_date_per_candidate` is irrelevant, the correct value to give to `_get_new_dates()` would be `compute_end_date` as we want to keep the buffer to be calculated from this datetime.
So we create a fake dictionary with only the task and `compute_end_date` and give it to `_get_new_dates()`.
The same logic applies when moving tasks backwards.
opw-5973597
Forward-Port-Of: odoo/enterprise#119161This update fixes an issue where stock replenishment wasn't updating existing purchase orders correctly, leading to duplicate order creation. Now, the system intelligently updates quantities in existing purchase orders when replenishing stock automatically, ensuring accurate stock levels and reducing unnecessary order placements. This improves the efficiency of our inventory management.
Original PR description
Replenishing the stock from an orderpoint will look for a purchase order line having the same orderpoint_id in order to update the quantity instead of creating a new one. The issue is manual orderpoint are deleted right after the replenishment. Replenishing two times the same product will always create a new purchase order line. This commit makes the orderpoint_id is pass in the procurement values only in case of `trigger == auto` orderpoint. 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#269937 Forward-Port-Of: odoo/odoo#269725
This update resolves a crash that occurred when users were manually correcting bank statement lines within the Odoo Enterprise system. The issue stemmed from a missing context key, preventing the correct journal from being assigned. This fix ensures accurate journal settings, preventing data inconsistencies and crashes during manual line adjustments.
Original PR description
When the manual correction tool was used to fill in the lines, we weren't passing the active context when creating the new records. In the case of bank statements, it could be an issue as the `default_journal_id` key is expected to be present to set the correct journal on the newly created bank statement line. Without this key in the context, it would default to the first journal with a valid type (see function `_search_default_journal`). If the journal found this way didn't match the current journal, a crash would occur when modifying the newly created lines. opw-[6294117](https://www.odoo.com/odoo/unassigned-tasks/6294117) Forward-Port-Of: odoo/enterprise#121032 Forward-Port-Of: odoo/enterprise#120745
This update ensures that combo pricing displayed in the configurator dialog accurately reflects the order's currency. Previously, extra prices were not converted, leading to mismatched totals. Now, prices are automatically converted to the order's currency, guaranteeing accurate pricing and order totals.
Original PR description
Description of the issue/feature this PR addresses: In the combo configurator dialog, a combo item's extra_price and the price_extra of no_variant attributes are stored in the company/product…
Description of the issue/feature this PR addresses: In the combo configurator dialog, a combo item's extra_price and the price_extra of no_variant attributes are stored in the company/product currency but were sent to the front-end without conversion. When the order uses a pricelist in a different currency, the popup shows these extras at face value (e.g. an extra of USD 1700 appears as ARS 1700 instead of being converted). The sale order line itself already converts these extras, so the popup price and the actual line price didn't match. Current behavior before PR: _get_combo_item_data and _get_selected_ptavs_data return extra_price / price_extra raw, in the company currency. With a foreign-currency pricelist the combo configurator popup adds them 1-to-1 to the already-converted base price, displaying an incorrect total that doesn't match the resulting sale order line. Desired behavior after PR is merged: The controller converts extra_price and price_extra to the configurator's currency (via currency._convert()) before serializing them, so the popup shows the correct amounts in the pricelist currency and matches the price computed on the sale order line. A test (test_sale_combo_multicurrency.py) covers combo extra-price conversion with a foreign-currency pricelist. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269905 Forward-Port-Of: odoo/odoo#269386
This update resolves an issue where timesheet settings (specifically, whether a project is billable) would reset after the timesheet systray was closed and reopened. Now, changes made to this setting are correctly saved and retained, ensuring accurate timesheet tracking. This improves data consistency and reporting.
Original PR description
## Behavior before PR 1. Open the timesheet systray. 2. Select a billable project. 3. Toggle the is_billable field. 4. Close and reopen the systray. 5. The is_billable value resets to its default instead of keeping the updated value. ## Expected Behavior After this PR The systray now correctly retains the is_billable value after being closed and reopened. ### Technical Notes The issue occurred because the systray view loads a sudo record that triggers compute methods, which overwrite the stored is_billable value. The fix ensures that after compute methods run, the saved is_billable value is preserved. Forward-Port-Of: odoo/enterprise#119681
This update resolves an issue where users with restricted accounting rights incorrectly marked invoices as fully paid, leading to inaccurate financial reporting. The fix ensures automatic bank reconciliation works correctly for these users by safely bypassing a group check during the reconciliation process, maintaining data auditability.
Original PR description
### Issue When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid If a user with only…
### Issue When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added ### Cause When a new Bank Statement is created, `_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()` This function creates a balancing line and triggers `move._compute_checked()` to update dependencies However, `move.checked` requires `_is_user_able_to_review()` to be True A user with "Invoicing & Banks" rights lacks the `account.group_account_user` group, meaning the move is not marked as checked, preventing dependencies from computing correctly Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids` Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)` Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it ### Steps to reproduce - Install `accountant` - Go to Accounting / Configuration / Accounting / Journals - Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts - Update the Demo user's accounting rights to Invoicing & Banks - Log in with the Demo user - Create and confirm an invoice for Acme Corporation (Amount: $1100) - Register a payment on the invoice (Amount: $500, Keep open) - Copy the invoice name - Open the Bank Reconciliation widget from the Accounting Dashboard - Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500) Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid ### Notes Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability opw-6077137 Forward-Port-Of: odoo/enterprise#120217 Forward-Port-Of: odoo/enterprise#118023
This update resolves an issue where users with limited accounting permissions incorrectly marked invoices as 'Fully Paid' after reconciling bank statements. The fix ensures accurate reconciliation by correctly handling user permissions and preventing the creation of unwanted Account Receivable lines, maintaining data integrity.
Original PR description
### Issue When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid If a user with only…
### Issue When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added ### Cause When a new Bank Statement is created, `_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()` In 19.0, this function creates a balancing line and triggers `move._compute_checked()` to update dependencies Especially `_compute_is_reconciled` But checked as been replaced by `review_state` This FW port will use an update on the `review_state` instead of the `checked` A user with "Invoicing & Banks" rights lacks the `account.group_account_user` group, meaning the move is not marked as `reviewed`, preventing dependencies from computing correctly Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids` Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)` Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it ### Steps to reproduce - Install `accountant` - Go to Accounting / Configuration / Accounting / Journals - Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts - Update the Demo user's accounting rights to Invoicing & Banks - Log in with the Demo user - Create and confirm an invoice for Acme Corporation (Amount: $1100) - Register a payment on the invoice (Amount: $500, Keep open) - Copy the invoice name - Open the Bank Reconciliation widget from the Accounting Dashboard - Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500) Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid ### Notes Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability opw-6077137 Forward-Port-Of: odoo/odoo#270080