Daily updates from Odoo
Wednesday, September 3, 2025
33 changes · saas-18.3
Enhancements to existing features
The sample invoice shown when fetching incoming bills in Peppol demo mode has been replaced with a better example. This makes demonstrations and testing clearer for users evaluating Peppol bill processing.
Original PR description
Replace Peppol demo bill that you get when fetching incoming bills in demo peppol mode. Forward-Port-Of: odoo/odoo#225086
Payment memos are now shorter and focus on the transaction reference, with the payment provider transaction ID added when relevant. This removes extra customer details from the memo, making bank reconciliation easier and more reliable.
Original PR description
WIP no-task
Accounting reports grouped by account code now also show the matching account name for the current company. This makes consolidated multi-company reporting easier to understand when several accounts are mapped to the same code.
Original PR description
In the current consolidation, you can make multi-company accounts and assign a code for each company. But a code must be unique inside each company. So it is not designed to map multiple accounts from a second company into one account of a first company. It is actually possible to achieve that effect by not making the accounts of the second company belong to the first company, and still make the code mapping. So you can make several accounts from the second company, map to the same code for the first company. Thus grouping by account codes become interesting for the accounting reports, in order to get a view of that consolidation. In order to make this reporting more clear, the name of the account corresponding to the account code (in the current company) is now shown when grouping by account code. task-4801891 Forward-Port-Of: odoo/enterprise#86403
The Peruvian electronic invoicing settings now show Estela as the provider name, reflecting Digiflow's recent rebrand. This keeps labels, help text, and translations consistent for users without changing how invoicing works.
Original PR description
This PR updates the Peruvian electronic invoicing configuration to reflect the recent brand change from Digiflow to Estela (formerly Digiflow). Changes: - Updated help texts and string labels in `res_company.py` - Adjusted references in `account_edi_format.py` - Updated translations in `es.po` This change is purely textual and does not affect logic or behavior. It ensures users see the correct branding across the Peruvian EDI settings. Forward-Port-Of: odoo/enterprise#93649 Forward-Port-Of: odoo/enterprise#85934
Resolved issues and error corrections
The leave management app now calculates mandatory leave days correctly when one or more employees have one or more leave requests. This helps ensure employee time off balances and mandatory day impacts are accurate for HR teams.
Original PR description
- Fixed the calculation of leave mandatory leaves to account for one or multiple leaves for one or multiple employees Task-4804618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223349
When a user is archived, their pending activities are now found even if they belong to a company that is not currently selected. This prevents old tasks from being left behind and keeps activity lists accurate after user deactivation.
Original PR description
**Steps to reproduce:**
- Set up one user with a new company
- With this user :
- Create sale order
- Create activity on the new sale order
- Go back to the admin user
- Disable the new company in the top right menu
- Archive the user
- Activities of the user are still present
**Issue:**
In `activities_to_delete = self.env['mail.activity'].search([('user_id', 'in', self.ids)])`, the access rights of the records used in the activities are checked, which means that the sale order domains are applied. If the given domain doesn't match (for example `('company_id', 'in', company_ids)` when the company_id is manually disabled), the search can miss the activity to unlink.
**Fix:**
Added `.sudo()` to ensure all of the user's activities of any company
are considered, overwriting the current company context.
opw-4716031
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206813This fix prevents a timing issue where newly uploaded attachments could be deleted by background cleanup before their database record was fully created. It improves reliability for users downloading files such as documents, PDFs, and payslips.
Original PR description
Should ideally land in 13.0... Let's merge it in 18.3 where we need it first... Then backport it to 16.0 if deemed useful/necessary. --- There is a race condition between `ir.attachment.create` and…
Should ideally land in 13.0... Let's merge it in 18.3 where we need it first... Then backport it to 16.0 if deemed useful/necessary.
---
There is a race condition between `ir.attachment.create` and `ir.attachment._gc_file_store` that can lead to the creation of an attachment with no related file in the file store.
Race
----
The race runs as follow:
1) `_gc_file_store` acquires a write exlusif lock on the ir_attachment table, but is interrupted by the OS before it can load the file gc checklist.
2) `create` kicks in, write a new file on file-system, adds an entry in the checklist, but can't create the ir.attachment record yet as the table is locked.
3) `_gc_file_store` resumes, load the checklist, see that `create`'s file as no attachment and removes it. It then releases the write exclusif table lock.
4) `create` resumes, it creates the `ir.attachment` record.
Subsequent access on the ir.attachment created record `raw` or `datas` fields fails because the file doesn't exist on disk.
Test
----
https://gist.github.com/Julien00859/512cfbad47c15febbfd667a017df7c8b
The `test_attachment_concurrency_create_gc` test reproduces the above steps to reproduce the bug. It does so by mocking the appropriate functions and using `threading.Event` to synchronize the execution plan between the two threads. Run it using the following command:
--test-tags database_breaking.test_attachment_concurrency_create_gc
It is database breaking because the ir.attachment file created during the test may not cleaned after the test run (in case the power goes down at the wrong moment).
Description
-----------
The bug was introduced by commit afdfdbfa5b36b in 13.0. Before that commit the create override in ir.attachment would first create the record, and only then write the file on disk. This way the `create` function acquired first a row exclusif lock and only then wrote the file and the checklist.
That the error went undercover for several years can be explained as follow:
1. The ir.autovacuum model and its cron has been unreliable for many years, it was often reported that the `_gc_file_store` (being the last in the list) did not run.
2. That the cron did not run made for a huge checklist that couldn't be processed all at once.
3. The cron usually only run once per night, when there are less people connected on the database to create attachments.
4. Finally, embarassing, we did discard some "missing file" reports and instead blamed the customers who reported them.
That we discover the error now is another chain of events:
1. The ir.autovacuum model now makes an advanced usage of the cron progress API. The cron is now automatically scheduled to run again "as soon as possible" when an exception occured in one of the `@api.autovacuum` methods.
2. The documents autovacuum is failing in 18.3 100% of the time (this is being addressed in another PR). This forces the "run again as soon as possible" condition permanent. The cron is basically always running.
3. The Odoo employees are all paid at the same time, and we all receive a PDF payslip as attachment. As many attachments as there are employees are created at a same time.
Some of us couldn't download our August payslip :-(Point of Sale now sends validated invoiced orders to the preparation display even when automatic receipt printing skips the receipt screen. This prevents kitchen or preparation teams from missing orders in that specific checkout flow.
Original PR description
Steps to reproduce: ------------------- - Enable "Automatic Receipt Printing" - Make a PoS order, with "Invoiced" checked, and validate it -> Observe that the command is not sent to the preparation display. Reason: ------- When skipping the receipt screen, we don't call `checkPreparationStateAndSentOrderInPreparation`, which then doesn't send the new command to the preparation display. The fix: -------- Backporting 26425ab712a3269beec98722 but without any refactoring. opw-5000406 Forward-Port-Of: odoo/odoo#225241 Forward-Port-Of: odoo/odoo#224641
Fixes an issue where linking an employee to an internal user could fail if the employee's bank account was marked for sending money and the user lacked bank permissions. This helps HR or administration users complete employee setup without needing unrelated banking access.
Original PR description
Steps to reproduce: - Let's consider an employee E with a bank account BA - Let's consider that BA has the option "Send Money" enabled - Let's log to an internal user U without any access right in Bank - Try to link E to any internal user Bug: A user error was raised: You do not have the rights to trust or untrust accounts. opw:4553238 Forward-Port-Of: odoo/odoo#211081 Forward-Port-Of: odoo/odoo#198974
Users can now try deleting a row again after cancelling a confirmation dialog in editable list fields. The delete button is briefly disabled only to prevent accidental double-clicks, then becomes available again so work is not blocked.
Original PR description
PR [1] aimed at fixing a double-click issue with the delete button in x2many lists. In standard views, it works fine. However, there are customizations (e.g. project sub tasks, product attributes...) that add a confirmation step before actually removing the row. If the user cancelled the deletion, clicking on the delete icon of that row afterwards had no effect at all. This commit fixes the issue by re-enabling the button after 500ms, thus only preventing double clicks. [1] https://github.com/odoo/odoo/pull/173481 opw~5019621 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#225174 Forward-Port-Of: odoo/odoo#225072
Analytic plans are now processed in parent-first order when installing related apps, preventing setup failures when plans have parent-child relationships. This helps ensure the Project app can be installed smoothly for databases that already use hierarchical analytic plans.
Original PR description
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can…
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can be processed before its parent. In such a case, the code tries to create a related field pointing to a parent-level column that does not yet exist, leading to errors like: `Field name "x_plan26_id" unknown for related field "x_plan26_id.plan_id"` This happened because `self` was iterated without guaranteeing that parents are processed first. As a result, the related field chain (`.plan_id.parent_id...`) could reference missing intermediate fields. The fix is ordering the recordset by `parent_path`. Steps to reproduce: 1. In Odoo Inspector, search for model `account.analytic.plan`. and go to records. 2. Create a first plan. 3. Create a second plan and set the first plan as its parent. 4. Install the `project` app (triggers `_sync_plan_column`). 5. Observe the crash due to an unknown related field. OPW-5006494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224509
Event attendees can now download calendar invitation files for published event tracks without being blocked by access restrictions on the location name. This fixes reminder links so public users can add sessions to their calendars reliably.
Original PR description
[1] introduces email reminders for tracks which include an ics file url. The ics file generation includes the location name, which is not accessible by public users. It is safe to sudo the name by the point you already have access to the track (i.e. it is published and all ir rules were checked) [1]: b7efd90f23833dee85c69434f84f859056650e66 task-5061885
Fixed an issue where a Discuss channel could stay marked as unread in one browser even after it had already been read elsewhere. This keeps unread indicators accurate when users work across multiple browser sessions or recover from missed live notifications.
Original PR description
Before this commit, if you opened an unread channel that the server already considered “read,” the channel would remain marked as unread in your browser. This typically happens when one browser instance misses the bus notification that cleared the unread status. Steps to reproduce: 1. Open Discuss as the same user on two browsers (A and B) 2. Send a message to said user 3. Stop bus notifications on browser A 4. Read the message on browser B 5. Re-enable bus notification on browser A 6. Open the channel on browser A -> not being marked as read This happens because the method `_set_last_seen_message` skips sending the notification when the message seen is older than the current `seen_message_id` (previously set by the other browser). This commit fixes the issue by setting the `allow_order` parameter in the rpc call. task-4863058 Forward-Port-Of: odoo/odoo#224881 Forward-Port-Of: odoo/odoo#218623
Reducing a subcontracted receipt quantity no longer cancels the last related manufacturing order while the receipt is still in progress. This prevents purchasing and warehouse teams from getting stuck when they need to adjust quantities later.
Original PR description
Steps to reproduce:
- Unarchive subcontracting operation type
- Create a storable product P1 with a BoM:
- BoM type: Subcontracting
- Subcontractor: Azure Interior
- Component C1 (route: Resupply Subcontractor on Order)
- Create a purchase order:
- Vendor: Azure Interior
- 10 units of P1
- Confirm the PO → 2 pickings are created:
- Resupply of 10 units of C1
- Receipt of 10 units of P1
- Confirm and validate the resupply of C1
- Components are reserved in the subcontracting MO
- Validate the consumption of 10 units in the receipt
- The MO is updated to 10
- Update the quantity of P1 to 0 in the receipt
Issue:
The manufacturing order is cancelled. As a result, subsequent updates on the receipt cannot recreate MOs.
Fix:
When reducing the receipt quantity, cancel only the extra MOs, but always keep at least one open MO if a subcontracting move is still ongoing.
opw-4792379
Forward-Port-Of: odoo/odoo#223858This update fixes an internal test issue so standalone tests correctly verify faketime behavior. It helps ensure automated testing catches timing-related problems consistently, reducing the risk of unnoticed regressions.
Original PR description
Standalone tests don't enter faketime mode. Forward-Port-Of: odoo/odoo#224077
Invoices sent by email to a purchase journal alias are no longer rejected when the sender is an existing user without access to the target company. This ensures valid supplier invoice emails are processed consistently, reducing manual follow-up and missed documents.
Original PR description
To reproduce the bug: 1- Create a DB with two companies and accounting app 2- Create a user and allow it to access company 2 3- Send a email using the user email to alias from purchase journal alias of company 2 4- The email will be rejected 5- Send a email using a random email address to alias. 6- The email will be accepted and an account.move is created. In a normal flow, when a user associated to the email not exists, the user_id is set to odoobot, otherwise, the user accosiated to the email. In the buggy flow the bug happens because `_compute_company_id` in account_move model, will set `company_id` to empty when user has no access to the company, as a result the `account_move` will fail. opw-4853027 Forward-Port-Of: odoo/odoo#225021 Forward-Port-Of: odoo/odoo#217322
This update prevents a confusing system error when someone saves a view with an unsupported XML tag. Users now receive a proper validation message, making the issue easier to understand and avoiding unnecessary error reports.
Original PR description
When a user tries to save a view with an invalid tag, an error occurs. **Steps to produce:-** 1. Go to Settings > Technical > User Interface > Views. 2. Click on New. 3. Add the view name. In architecture -> add `<template></template>`. 4. Try to save the changes. **Error:-** `ValueError:Wrong value for ir.ui.view.type: 'template'`. **Root cause:-** - The view type in `ir.ui.view` is automatically inferred from the `root tag` of the XML defined in the `arch` field. - In this case, `<template>` becomes the inferred view type, which is not part of the valid selections for the type field in the model `ir.ui.view`. **Solution:-** - Before calling `super().create(vals_list)`, add a validation check to ensure `values['type']` is in the allowed types. If not, raise a ValidationError. sentry-6561028171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207219
This update fixes several issues when editing icons in the HTML editor. Users can now undo icon spin effects, see the toolbar state correctly, and apply colors consistently to selected icons and text.
Original PR description
**Current behavior before PR:** - Applying a spin effect to an icon doesn't not create a history step, which causes the undo functionality to fail. - The spin icon in the toolbar was not highlighted…
**Current behavior before PR:** - Applying a spin effect to an icon doesn't not create a history step, which causes the undo functionality to fail. - The spin icon in the toolbar was not highlighted after applying the effect. - When some text is selected along with icon, trying to apply color only affects the icon, the text remains uncolored. **Desired behavior after PR:** Now, - History step is created after adding spin effect to an icon, allowing undo to work properly. - The spin icon in the toolbar is properly highlighted to reflect the applied effect. - This PR removes `color_apply_overrides` from icon_plugin to let color_plugin handle coloring the icons ensuring that the selected text is also colored along with icon. - This PR also makes sure that default 60% opacity is applied when applying solid background color on icons or table cells. task-4794673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224702 Forward-Port-Of: odoo/odoo#210341
This change prevents missing website links from being turned into empty links when a CDN is active. It helps avoid a checkout address form issue where the Submit button could trigger an unexpected page refresh and interrupt form submission.
Original PR description
In QWeb, when using `t-att-href='None'`, the attribute is omitted from the DOM. However, when a CDN is used, `None` is converted to an empty string (`''`) by `get_cdn_url`. This is a follow-up to commit 3e9c953. This fix addresses an issue on the `/shop/address` page where the "Submit" button had `href=''`, causing JavaScript event handling to break due to a race condition triggered by a page refresh during form submission (POST). Forward-Port-Of: odoo/odoo#223252 Forward-Port-Of: odoo/odoo#220166
The organization chart now correctly identifies employees and managers when viewed from user, employee, or public employee forms. This prevents incorrect or missing links in employee profile views, improving reliability for HR users.
Original PR description
This update ensures that the correct employee and parent IDs are fetched depending on whether the widget is displayed in a `res.users`, `hr.employee` or `hr.employee.public` form. The `onWillStart` was removed since `useRecordObserver` is triggered in `onWillStart`, and both used to have the same logic. task-5039701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225193 Forward-Port-Of: odoo/odoo#224456
This fix restores custom website editing permission behavior that some Odoo.com pages rely on. It avoids blocking editors who should only have rights to modify specific website pages, while keeping a related test in place but disabled until a fuller solution is found.
Original PR description
*: test_website This reverts commit [1]. Indeed, while it fixed the bug as intended while keeping the `_check_user_can_modify` feature, it apparently did not keep that one working in all cases: having partial view edition rights for some website.page (see uses in our Odoo.com customizations). While searching for a solution allowing to keep the fix of [1] and the whole purpose of `_check_user_can_modify`, the logic part of [1] is reverted, keeping the test but disabled. [1]: https://github.com/odoo/odoo/commit/8c41c147a4c6a415e7c5bfdde9297edbf40b4239 Forward-Port-Of: odoo/odoo#225160
Fixed an issue where opening an Employee form on a mobile device and tapping the gear menu could cause the app to crash. This improves reliability for mobile users managing employee information.
Original PR description
Opening the Employee form on mobile and tapping the gear icon could crash because `PresenceActionItems` was undefined. Initialize it and guard the template. task-5055564 Forward-Port-Of: odoo/odoo#224942
Corrects Italian electronic invoice XML exports so self-invoices omit payment data and supplier invoice references are placed in the required section. This helps companies using Italian localization stay aligned with tax authority formatting rules and reduces rejected or inaccurate filings.
Original PR description
1- `<DatiPagamento>` shouldn't be included in autofatture. 2- The supplier's original invoice number and date must be placed in the `<DatiFattureCollegate>`, using `<IdDocumento>` and `<DataDocumento>` fields respectively. Currently `<IdDocumento>` is added to the `<DatiOrdineAcquisto>`. A fix is made to add `<IdDocumento>` and `<DataDocumento>` to `<DatiFattureCollegate>`. references: https://www.agenziaentrate.gov.it/portale/documents/d/guest/guida_compilazione-fe-esterometro-v1-10_aprile_2025 opw-4810326 Forward-Port-Of: odoo/odoo#212989
Refreshing the Thank You page in a survey live session no longer causes an error if a survey question was deleted in another tab. This improves reliability for presenters and participants by keeping completed live sessions accessible instead of showing a crash.
Original PR description
Currently, an error occurs when refreshing a live session's `Thank You` page after deleting a survey question. **Steps to reproduce:** - Install the `survey` module. - Create a `new survey`, `add a…
Currently, an error occurs when refreshing a live session's `Thank You` page after deleting a survey question. **Steps to reproduce:** - Install the `survey` module. - Create a `new survey`, `add a question` and click on `Create Live Session`. - Complete the survey and leave it on the `Thank You` page. - Switch back to the `first tab`, delete the question and `save` the survey. - Return to the `Thank You` tab and `refresh` the page. **Error:** `IndexError: list index out of range` **Root Cause:** At [1], the controller assumes the question exists and tries to access `index [0]`, but when the question has been deleted, the recordset is empty, causing an `error`. [1] https://github.com/odoo/odoo/blob/ffd9c0f96bda1bad1ad2059d9be2fae54b60eace/addons/survey/controllers/survey_session_manage.py#L236 This commit prevents a crash when refreshing a live session if the question was deleted. sentry-6736648824 Forward-Port-Of: odoo/odoo#225242 Forward-Port-Of: odoo/odoo#218312
Imported vendor bills created from consolidated inter-company invoices now correctly link to all related purchase orders. This helps teams keep purchasing and accounting records connected when multiple sales orders are billed together.
Original PR description
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated…
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated Invoice for both SO, and import it as Vendor Bill in the client Company, the bill isn't linked to the matching Purchase Order ## Cause: The `invoice_origin` is used to get the references, but it doesn't split causing the purchase's name to search in `_match_purchase_orders()` to be ["P00001, P00002"] instead of ["P00001", "P00002"] https://github.com/odoo/odoo/blob/2718aaa7397e38be0fcd64fe6b5ef5c0be66cfe2/addons/purchase/models/account_invoice.py#L373-L374 ## Steps to reproduce: - Enable Inter-Company Transactions for Sales Orders and Purchase Orders in two Companies - Create and Confirm two Sales Orders from one company to the other one - Create a Consolidated Bill for both S0 - Send the Invoice (Download) - Switch to the second Company - In Purchase, Confirm both RFQ - In Accounting > Vendor > Bills, Upload the downloaded bill - The Smart Button isn't linked to the PO Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4690707) opw-4690707 Forward-Port-Of: odoo/odoo#223398
This update fixes a failing mobile test in the Point of Sale app. It helps keep quality checks reliable so future Point of Sale changes can be validated with more confidence.
Original PR description
The mobile test was failing due to an issue. opw-5059482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225127
This fixes an error that occurred when a settings header was configured without a label or linked field. Businesses can now use optional header labels in settings screens without causing the page to fail.
Original PR description
Before this commit, an error would occur if a header setting did not contain an attribute string or field. This was because the code tried to infer the label. However, the label should be optional. 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#225119 Forward-Port-Of: odoo/odoo#225080
Saving the document layout wizard no longer tries to update a company's bank account when the account number has not changed. This prevents unnecessary errors for trusted bank accounts while keeping the displayed account number available for review or real edits.
Original PR description
Description of the issue/feature this PR addresses: The document layout wizard (base.document.layout) attempts to write the partner’s bank account number even if it has not been changed. If the first…
Description of the issue/feature this PR addresses: The document layout wizard (base.document.layout) attempts to write the partner’s bank account number even if it has not been changed. If the first bank account is marked as trusted, Odoo blocks the write and raises an error. This PR prevents that error by only writing the account number when it has actually changed. Current behavior before PR: - The wizard shows the account_number field. - On saving, _inverse_account_number always writes to the first partner bank account. - Trusted bank accounts trigger an error: “You cannot change the account number or partner of a trusted bank account.” Desired behavior after PR is merged: - The wizard still shows the account_number field. - On saving, _inverse_account_number only writes if the value changed. - Trusted bank accounts that are not modified do not cause an error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224905
The PLM dashboard now shows a more accurate count of Engineering Change Orders waiting for the current user's validation. This helps approvers focus on items that actually need their action, avoiding misleading totals caused by approvals assigned to others or already completed.
Original PR description
The dashboard of PLM displays for each ECO type the number of validations pending in general, and the validations waiting for me specifically. The latter has been incorrectly computed for quite some time, as it computes how many ECOs exists where I am an approver and an approval is waiting - but there is no guarantee that the waiting approval is one of mine; it might be that I am a past approver of the ECO and that another approval (waiting for somebody else than me) exists, or that two approval are required on the same stage (one by me, one by somebody else) and I already approved. This commit switches the computation around by looking for pending approvals waiting for me, and then get the number of (non-archived) ECOs bound to them. Forward-Port-Of: odoo/enterprise#93411 Forward-Port-Of: odoo/enterprise#92348
The signature dialog now avoids showing a drawn signature on top of the auto-generated signature. This prevents confusion when signing documents and gives users a clearer, cleaner signing experience.
Original PR description
Fixed an issue where both the auto-generated and drawn signatures overlapped in the signature dialog. This was caused by the system automatically setting the user's default signature to the drawn one when opening the dialog. Now, the dialog no longer defaults to the drawn signature, preventing visual overlap and ensuring a cleaner user experience. Forward-Port-Of: odoo/enterprise#93750
This fixes an error that blocked users from posting more than one invoice at a time when using Avalara Brazil automatic tax mapping. Businesses can now process batches of affected invoices without interruption, improving reliability for Brazilian tax workflows.
Original PR description
Issue:
When posting multiple invoices with Avalara Brazil tax mapping, a traceback is raised:
ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move
Only occurs when fiscal position is set to:
Automatic Tax Mapping (Avalara Brazil)
Affected versions:
- 17.0 and later
Steps to reproduce:
1. Set Avalara connection
2. Create an invoice with fiscal position: Automatic Tax Mapping (Avalara Brazil)
3. Duplicate that invoice
4. Select two or more invoices in draft
5. Try to post those entries
https://drive.google.com/file/d/1_CjX9vGhr-ZyUegP9QhOdQ--bfA8ylsH/view?usp=sharing
Current behavior:
- Error is raised: ValueError: Expected singleton
Expected behavior:
- Invoices should post correctly without errors
Forward-Port-Of: odoo/enterprise#93689
Forward-Port-Of: odoo/enterprise#93272The Malaysia Statement of Account report now applies the correct currency conversion when invoices are issued in a currency different from the company's main currency. This prevents balances from being shown with the right currency symbol but the wrong amount, improving accuracy for customer reporting and collections.
Original PR description
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for…
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for each line is displayed as the main currency, but the conversion isn't done. For instance, if we create an invoice line of 3.5$ but our main currency is the Euro, in the report, it will show 3.5€ instead of 2.99€ ## Reproduction Steps 1. In a db without demo data, Download the app l10n_my. 2. In the general settings, click on Currencies. Activate a second currency and set its currency rate (relative to the main currency of the company) different of 1. 3. In accounting > settings, click on -> Currencies. Activate this second currency. 4. Click on configuration > journals and activate the debug mode. In the Journal Entries tab, as Currency, select a different currency than your main one (set in the general settings). 5. Create an invoice. Set a customer and select the journal for which you set an additional currency. Select this additional currency. Finally, add a product and click confirm. 6. Click on Reporting > Aged Receivable. Then, click on the line corresponding to your partner on Statement of Account. A PDF should download. ### Expected behavior The lines under Balance should be displayed as the main currency of the company, with the correct currency rates applying. ### Unexpected behavior The lines under Balance are displayed as the main currency of the company but the currency rates are not applying. ## Origin of the issue In the code, the currency rate isn't used to generate this line of the report: https://github.com/odoo/enterprise/blob/79c1ba68d48e7e068104d867e186610dd5110cc4/l10n_my_reports/report/statement_account_templates.xml#L52 __ opw-4975540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#93096
This fix prevents the website generator from continuing background checks after its screen has been closed or cancelled. It reduces avoidable crashes and keeps the website creation experience more stable for users.
Original PR description
In a component lifecycle, it may happen that onWillStart is called but not onWillUnmount. Indeed, if the component is destroyed before being mounted (because the current rendering has been cancelled), onWillUnmount isn't called. As a consequence, in the WebsiteGenerator component, the setInverval might never been called, thus producing an orm call every 10 seconds, when the component is destroyed. These calls lead to crashes ("Component is destroyed").
The solution is to use the onWillDestroy hook instead, which is always called.
Forward-Port-Of: odoo/enterprise#93679