Wednesday, June 11, 2025
54 changes · saas-18.3
Enhancements to existing features
Point of Sale now has an internal option to keep pending order changes available after serialization, so they can be sent again when needed. This helps make order synchronization with the server more reliable without changing the cashier-facing workflow.
Original PR description
- Add an options `keepCommands` inside `serializeForORM` method in order to keep the record dirty, so the next call to `serializeForORM` will again return the commands to apply for the ORM. task-id: 4848882 enterprise PR: https://github.com/odoo/enterprise/pull/87193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The CRM lead list now has a database optimization aligned with its usual display order. This helps the sales pipeline board load searches more efficiently, especially where many leads are present.
Original PR description
This commit adds a default index on the order of `crm.lead`. It will support the `web_search_read` that are done in the kanban view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The VoIP softphone tabs have been visually refined for a cleaner, more modern appearance. This improves day-to-day usability by making the calling interface feel clearer and easier to navigate.
Original PR description
This commit refines the softphone tabs UI for a cleaner and more modern look. task-4768693 closes odoo/enterprise#85702
Resolved issues and error corrections
Fleet vehicle cards now show the assigned driver's name again in the kanban view. This restores important at-a-glance information for teams managing vehicles and drivers after a previous interface change hid it.
Original PR description
Since refactoring of avatar widget, the name of the dirver is not displayed anymore in the kanban view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The shot value chartJs plugin would show the same value for a waterfall chart than a bar chart (the value of the top of the bar), instead of the correct value for a waterfall chart (the difference between the top and the bottom of the bar). Also the odoo_pyramid_chart would show negative values for the values of the left of the pyramid, instead of the absolute value. Task: 4812692 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
The shot value chartJs plugin would show the same value for a waterfall chart than a bar chart (the value of the top of the bar), instead of the correct value for a waterfall chart (the difference between the top and the bottom of the bar). Also the odoo_pyramid_chart would show negative values for the values of the left of the pyramid, instead of the absolute value. Task: 4812692 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213299
This fixes an issue where migrated Luxembourg tax reports could fail to open because an outdated internal setting was left behind. The report now clears that unused setting explicitly, improving reliability for businesses using Luxembourg localization after upgrading.
Original PR description
This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula.
This fix prevents the messaging interface from crashing when someone hovers over an older or unrecognized reaction emoji. Users can continue reading and interacting with messages normally, even when legacy reaction data is present.
Original PR description
When an unknown reaction is hovered (old emojis not present in emoji data anymore for example), shortcode can not be found and a crash occur. This commit fixes the issue. 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
Opening a Discuss chat conversation no longer briefly shows the welcome message in the wrong moment. This removes a small visual flicker, making the chat experience feel more polished and less distracting for users.
Original PR description
Before this commit, when opening a conversation in chat window, it always show a small flicker at opening. This happens because there's a template part to show start message text `"Welcome to #channel"` at the very beginning of conversation. This must be shown only at the very beginning, but when opening a conversation in a chat window, there's a short period of time when the component is not fully loaded and mounted. This `"Welcome to #channel"` start message text was not conditionally awaiting mounted and loaded thread component. Before / After  
Vehicle cards in the Fleet app once again show the assigned driver's name. This restores useful at-a-glance information for teams managing vehicles and helps avoid opening each record just to confirm responsibility.
The CRM lead form now avoids showing or preparing the AI probability helper before a lead has been saved. This prevents users from hitting an error when creating a new lead and keeps the lead creation flow smooth.
Original PR description
Currently, an error occurs when clicking the AI icon to calculate the probability of CRM leads. Steps to Reproduce: - Install the `crm` module. - Go to `Leads` > `List View` > Click `"New"`. - Click on the `AI` (automated probability) icon. `ValueError: Expected singleton: crm.lead()` This error occurs when the user clicks on the `AI` icon to calculate the probability of `CRM leads`. Since the record does not exist [1], the system raises an error. [1] https://github.com/odoo/odoo/blob/d3b4d1e8d35eebbc015f5ead02f249e8ae5267d8/addons/crm/models/crm_lead.py#L2763 This commit ensures that the `AI icon` is `visible` when the record exists. sentry-6657175088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the VoIP keypad from reopening with the previous call's state after a user hangs up. It gives users a cleaner, more predictable calling experience when starting a new call.
Original PR description
In VoIP, the keypad state wasn't updated after the user hangs up with the other party. So, when making a new call, the keypad appears again with its last state in the previous call. This commit fixes this by resetting the keypad state everytime the user makes a call. Task-4848365
This fix restores the intended filtering of canceled entries in the bank reconciliation widget. It helps prevent irrelevant canceled items from appearing during reconciliation, making accounting workflows clearer and less error-prone.
Original PR description
During this commit: https://github.com/odoo/enterprise/commit/0931f83a37a66fbc523fa40cc97f1cc52443bd2f we removed the domain on cancel entries to add tags on the statement itself and a filter. But when doing the refactor of the bank rec widget, we decided to remove the tags for now but didn't put back the domain. This commit will add it back no task id
This fix prevents an error when a signature request does not have a communication company set. Users can continue opening and processing signature requests instead of encountering a crash caused by missing language formatting details.
Original PR description
Before this commit, if the communication compay was not set on a sign_request, the lang value would be falsy. As a result posix_to_ldml(lang.date_format, locale=locale) would crash.
This fixes an issue that could prevent the appointment booking form's anti-bot check from loading properly. It helps ensure visitors can complete appointment requests reliably while keeping the form protected from automated abuse.
Original PR description
Fix wrong variable rename in `Interaction` refactoring of odoo/enterprise@fba0ad8a693e4d8a9089fa0c1e680beb0ee19a23 opw-4861452
In our [previous commit][1], there were still a few missing bits: - We forgot to check for the `reconcile` option on the accounts set on a tax group. - The Bolivian localization had its receivable and payable accounts mixed for the tax groups. We reversed them and created a new one. - The 0% tax group for Spain had its receivable and payable accounts reversed. We changed them as well. [1]: https://github.com/odoo/odoo/commit/925f8cbe6aebad20de5423814b43e4c07644e9e1 [task-3763030](https:
Original PR description
In our [previous commit][1], there were still a few missing bits: - We forgot to check for the `reconcile` option on the accounts set on a tax group. - The Bolivian localization had its receivable and payable accounts mixed for the tax groups. We reversed them and created a new one. - The 0% tax group for Spain had its receivable and payable accounts reversed. We changed them as well. [1]: https://github.com/odoo/odoo/commit/925f8cbe6aebad20de5423814b43e4c07644e9e1 [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Issues noticed in https://github.com/odoo/upgrade/pull/7787 Forward-Port-Of: odoo/odoo#212785
Because the `location.assign` method also triggers a `beforeunload` event, the `error_service` doesn't handle errors when downloading a file with the action target `download` (for example download vCard). See [1] for more details about the original fix. task-4457865 [1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213563 Forward-Port-Of:
Original PR description
Because the `location.assign` method also triggers a `beforeunload` event, the `error_service` doesn't handle errors when downloading a file with the action target `download` (for example download vCard). See [1] for more details about the original fix. task-4457865 [1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213563 Forward-Port-Of: odoo/odoo#212432
Versions -------- - 17.0+ Steps ----- 1. Create a Stripe transaction; 2. check server logs. Issue ----- The `client_secret` value gets logged, Stripe documentation says this value should not be stored or logged[^1]. [^1]: https://docs.stripe.com/api/payment_intents/object#payment_intent_object-client_secret Cause ----- Currently we're just raw-logging the processing values. Solution -------- Add a `_get_specific_secret_keys` method to `payment.transaction`, to be used w
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a Stripe transaction; 2. check server logs. Issue ----- The `client_secret` value gets logged, Stripe documentation says this value should not be stored or logged[^1]. [^1]: https://docs.stripe.com/api/payment_intents/object#payment_intent_object-client_secret Cause ----- Currently we're just raw-logging the processing values. Solution -------- Add a `_get_specific_secret_keys` method to `payment.transaction`, to be used when logging processing values that may contain secret information. Also mute the logger when redirecting to `/payment/status` from Stripe, as the `client_secret` would otherwise be logged by `werkzeug`. opw-4818301 Forward-Port-Of: odoo/odoo#211979
Before this commit, LED status was managed from within Odoo. This could lead to issues: for example, when we stopped Odoo on the iot box, the leds stay in constant green (last used) colour despite odoo not running. We now use a systemd service, separated from the Odoo service, that continues running even if Odoo stops. Task: 4813935 Forward-Port-Of: odoo/odoo#212133
Original PR description
Before this commit, LED status was managed from within Odoo. This could lead to issues: for example, when we stopped Odoo on the iot box, the leds stay in constant green (last used) colour despite odoo not running. We now use a systemd service, separated from the Odoo service, that continues running even if Odoo stops. Task: 4813935 Forward-Port-Of: odoo/odoo#212133
**Steps to reproduce 1:** - Install l10n_tz_account - Switch to a Tanzanian company (e.g. TZ Company) - Check the taxes **Issue 1:** Each tax has the same tax grids (i.e. same number and same sign) for the invoice section and the refund section, which leads to have the amount of the credit notes being added (instead of subtracted) in the Tax report. **Solution 1:** Invert the sign of the tax grids in the refund section. **Steps to reproduce 2:** - Create an invoice for a Tanzanian
Original PR description
**Steps to reproduce 1:** - Install l10n_tz_account - Switch to a Tanzanian company (e.g. TZ Company) - Check the taxes **Issue 1:** Each tax has the same tax grids (i.e. same number and same sign)…
**Steps to reproduce 1:** - Install l10n_tz_account - Switch to a Tanzanian company (e.g. TZ Company) - Check the taxes **Issue 1:** Each tax has the same tax grids (i.e. same number and same sign) for the invoice section and the refund section, which leads to have the amount of the credit notes being added (instead of subtracted) in the Tax report. **Solution 1:** Invert the sign of the tax grids in the refund section. **Steps to reproduce 2:** - Create an invoice for a Tanzanian customer without VAT **Issue 2:** The default fiscal position will be "International", instead of "Domestic". A domestic fiscal position for customer without VAT is missing. **Solution 2:** Add a "Domestic individual" fiscal position that is the same as the "Domestic" one except for the VAT that is not required. opw-4840609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213416 Forward-Port-Of: odoo/odoo#213107
When a loyalty program is already applied in a sale order, the same loyalty program could also be triggered in the POS. Steps to reproduce: ------------------- * Create a simple loyalty program with a discount of 10% on order that is applied automatically if the total of the order is more than 1$ * Create a sale order with a product of 10$ and apply the loyalty program * You will have a disount of 1$ in the sale order * Open the PoS and settle the order * A new discount will appear in t
Original PR description
When a loyalty program is already applied in a sale order, the same loyalty program could also be triggered in the POS. Steps to reproduce: ------------------- * Create a simple loyalty program with a discount of 10% on order that is applied automatically if the total of the order is more than 1$ * Create a sale order with a product of 10$ and apply the loyalty program * You will have a disount of 1$ in the sale order * Open the PoS and settle the order * A new discount will appear in the PoS with a discount of 0.9$. > Observation: You now have 2 discounts coming from the same program Why the fix: ------------ We now adapt the `_programIsApplicable` function to check if the program was already used in the sale order. If it was, we ignore the program in the PoS. opw-4381890 Forward-Port-Of: odoo/odoo#213246 Forward-Port-Of: odoo/odoo#209877
In some localizations, the same accounts were used on tax groups (for tax closings), on tax repartition lines, and/or as default payable or receivable account. Having the same account on two of these types causes issues with the tax closing amounts being incorrect. This commit makes sure all accounts are distinct for the different types and creates new ones if necessary. It also adapts the tax closing accounts in all localizations to be reconcilable accounts, either payable or receivable,
Original PR description
In some localizations, the same accounts were used on tax groups (for tax closings), on tax repartition lines, and/or as default payable or receivable account. Having the same account on two of these types causes issues with the tax closing amounts being incorrect. This commit makes sure all accounts are distinct for the different types and creates new ones if necessary. It also adapts the tax closing accounts in all localizations to be reconcilable accounts, either payable or receivable, but non-trade. That way users can easily reconcile bank transactions with the tax authorities. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/enterprise/pull/85693 Forward-Port-Of: odoo/odoo#212009 Forward-Port-Of: odoo/odoo#201249
Consider this situation: - Customer invoice. - All invoice lines use a tax type with l10n_es_type=no_sujeto_loc. - The sum of the invoice is 0€. - Sent to SII. Before this patch, the process would raise a wrong `UserError`. If the process was being executed by the cron, **no invoice would be sent**, even if there was only one failing. After this patch, the invoice will be notified nevertheless. If there's any kind of real validation problem, the SII servers will return an error that wi
Original PR description
Consider this situation: - Customer invoice. - All invoice lines use a tax type with l10n_es_type=no_sujeto_loc. - The sum of the invoice is 0€. - Sent to SII. Before this patch, the process would raise a wrong `UserError`. If the process was being executed by the cron, **no invoice would be sent**, even if there was only one failing. After this patch, the invoice will be notified nevertheless. If there's any kind of real validation problem, the SII servers will return an error that will get logged in the invoice. No exceptions raised in Odoo. The process can continue. Faulty invoices are marked; others work. Apart from that, there's also the fix to support the specific case outlined above. @moduon MT-7949 OPW-4344661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189667 Forward-Port-Of: odoo/odoo#189529
Steps to reproduce the bug: - Create a storable product “P1”: - Update the quantity to 1 in "WH/Stock" - Create a putaway rule: - From "WH/Stock" to "WH/Stock/Shelf1" - Create a manufacturing order: - Select any product to produce - Add a component: - 1 unit of P1 - Confirm and validate the MO - Unbuild the order Problem: A stock move for P1 is created from "Virtual Location/Production" to "WH/Stock/Shelf1" instead of "WH/Stock". This happens be
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Update the quantity to 1 in "WH/Stock" - Create a putaway rule: - From "WH/Stock" to "WH/Stock/Shelf1" - Create a manufacturing order:…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Update the quantity to 1 in "WH/Stock"
- Create a putaway rule:
- From "WH/Stock" to "WH/Stock/Shelf1"
- Create a manufacturing order:
- Select any product to produce
- Add a component:
- 1 unit of P1
- Confirm and validate the MO
- Unbuild the order
Problem:
A stock move for P1 is created from "Virtual Location/Production" to "WH/Stock/Shelf1" instead of "WH/Stock".
This happens because the `_apply_putaway_strategy` method is not called on the `stock.move.line` linked to the move.
In previous versions (e.g., v17), this issue didn't occur because the quantity was directly set on the move. This triggered a write on the `stock.move` model, which in turn called `_set_quantity`. Since no `stock.move.line` was linked at that point, a new one was created, and its quantity was set via `_set_quantity_done`, which itself called `_apply_putaway_strategy`:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L202
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L399
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L384
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L2133
This scenario used to work only when the product was untracked:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L186
However, starting from v18, some code was refactored to clean up unnecessary conditions. The `else` block was removed, and now, regardless of the product type, the quantity is not set directly on the move anymore. Instead, a `stock.move.line` is created using `_prepare_move_line_vals`:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L197
But `_apply_putaway_strategy` is not called in this flow.
Bug introduced in v18.0, commit:
https://github.com/odoo/odoo/commit/79d9dd7f15371aa7293a4af0b0ebd193aa80e2be
opw-4830952
Forward-Port-Of: odoo/odoo#212604Commit 88473425583e31269ec892fbc3a491050b9b8e80 changed `sortedColumn.measure` that was the field name `'expected_revenue'` to the fully qualified measure id `'expected_revenue:sum'` However, the spreadsheet client-side upgrade forgot to change that. As a consequence, the sorting was just ignored. Task: 4818107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211412
Original PR description
Commit 88473425583e31269ec892fbc3a491050b9b8e80 changed `sortedColumn.measure` that was the field name `'expected_revenue'` to the fully qualified measure id `'expected_revenue:sum'` However, the spreadsheet client-side upgrade forgot to change that. As a consequence, the sorting was just ignored. Task: 4818107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211412
This error occurs when attempting to create a submenu item under a menu item. Steps to reproduce: - Go to `menu items`. - Click `New` > In `Submenus` click `Add a line` `TypeError: unsupported operand type(s) for +: 'bool' and 'str'` This error occurs when attempting to create a submenu item under a menu item that does not have a name. Since the menu item record has not been saved yet, the system assigns a new ID to the menu item and sets its name to False. When computing the comp
Original PR description
This error occurs when attempting to create a submenu item under a menu item. Steps to reproduce: - Go to `menu items`. - Click `New` > In `Submenus` click `Add a line` `TypeError: unsupported…
This error occurs when attempting to create a submenu item under a menu item. Steps to reproduce: - Go to `menu items`. - Click `New` > In `Submenus` click `Add a line` `TypeError: unsupported operand type(s) for +: 'bool' and 'str'` This error occurs when attempting to create a submenu item under a menu item that does not have a name. Since the menu item record has not been saved yet, the system assigns a new ID to the menu item and sets its name to False. When computing the complete name for the submenu item, the menu(parent menu) item's name is False, which causes the error. https://github.com/odoo/odoo/blob/d2ea23f252f0f8f329e2b0ff96de6ee2a14b922f/odoo/addons/base/models/ir_ui_menu.py#L56 This commit ensures that if the parent menu item record has not been saved and its name is False, an empty string is used in its place. sentry-6368548342 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210291
Exported the SignatureForm class to allow overriding from other modules. Forward-Port-Of: odoo/odoo#213510
Original PR description
Exported the SignatureForm class to allow overriding from other modules. Forward-Port-Of: odoo/odoo#213510
Description of the issue/feature this PR addresses: The system enforced a strict check that the delivery carrier partner must be located in Romania. This was limiting for companies that work with international carriers or operate across borders. Current behavior before PR: Delivery carriers not based in Romania triggered an error and could not be used in the delivery process. Desired behavior after PR is merged: Delivery carriers can now be located in any country. This provides greater
Original PR description
Description of the issue/feature this PR addresses: The system enforced a strict check that the delivery carrier partner must be located in Romania. This was limiting for companies that work with international carriers or operate across borders. Current behavior before PR: Delivery carriers not based in Romania triggered an error and could not be used in the delivery process. Desired behavior after PR is merged: Delivery carriers can now be located in any country. This provides greater flexibility in managing logistics and integrating international shipping partners. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212476
Problem: When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner Full Description" field. Cause: The class `o-position-absolute` sets `left: auto` which was evaluated as `50%`, and`margin-left: -50%` was added to center absolutely positioned elements. However, this causes issues when rendered in `html_field` context, where `left: auto` evaluates to `0px`. As
Original PR description
Problem: When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner…
Problem: When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner Full Description" field. Cause: The class `o-position-absolute` sets `left: auto` which was evaluated as `50%`, and`margin-left: -50%` was added to center absolutely positioned elements. However, this causes issues when rendered in `html_field` context, where `left: auto` evaluates to `0px`. As a result, the `-50%` margin shifts the video offscreen. Solution: Set both `left` and `right` to `0` in `.o-position-absolute` to ensure proper centering. Remove `margin-left: -50%` to prevent misalignment in non-editor contexts. **Before**: In website editor:  In contacts (html_field):  **After** In website editor:  In contacts (html_field):  Steps to reproduce: - Go to Contacts > "Gemini Furniture". - Add a video in the "Website Partner Full Description" field. - Save and open the partner on the website (`partners/gemini-furniture-11`). - Return to the Contacts page. → The video appears shifted 50% to the left. opw-4752567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212344
- Install l10n_it_edi. - Install l10n_it_edi_withholding - Uninstall l10n_it_edi_withholding - Attempt an install of l10n_it_edi_withholding The following error appears: Invoice and credit note distribution should each contain exactly one line for the base. When uninstalling l10n_it_edi_withholding, the account.tax data are not unlinked which causes issues when _l10n_it_edi_withholding_post_init tries to _load_data with them. This commit prevents already existing account tax from bei
Original PR description
- Install l10n_it_edi. - Install l10n_it_edi_withholding - Uninstall l10n_it_edi_withholding - Attempt an install of l10n_it_edi_withholding The following error appears: Invoice and credit note distribution should each contain exactly one line for the base. When uninstalling l10n_it_edi_withholding, the account.tax data are not unlinked which causes issues when _l10n_it_edi_withholding_post_init tries to _load_data with them. This commit prevents already existing account tax from being loaded from data during the installation. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4798659) opw-4798659 Forward-Port-Of: odoo/odoo#211910
### Description of the issue/feature this PR addresses: Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over. ### Current behavior before PR: Event updates/ new syncs with google_calendar might trigger email notifications, even for past events, causing useless invitations/ updated invitations to users. ### Desired behavior after PR is merged: Email notifications are only sent for active or future
Original PR description
### Description of the issue/feature this PR addresses: Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over. ### Current behavior before PR: Event updates/ new syncs with google_calendar might trigger email notifications, even for past events, causing useless invitations/ updated invitations to users. ### Desired behavior after PR is merged: Email notifications are only sent for active or future events. Creation-from-sync / Updates to past events that have already ended are no longer triggering emails. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr task-4684432 Forward-Port-Of: odoo/odoo#213227 Forward-Port-Of: odoo/odoo#208302
Forward-Port-Of: odoo/odoo#213514
Original PR description
Forward-Port-Of: odoo/odoo#213514
Improve the error message when the response is HTTP 403. Currently, the content is empty for such errors, making it difficult to identify the source of the problem for users. Step to reproduce: - Try to send an invoice with wrong credentials. - The error message is empty, making it hard to understand what went wrong. Error message before this commit:  After:  After:  Also added the missing .pot file. opw-4823950 opw-4628908 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#212379
- Vendor bills with taxes of l10n_es_type == 'sujeto_agricultura' (REAGYP) must be reported with regime code '19', as per TicketBAI specifications. - This fix ensures that such invoices include '19' in `regime_key`, avoiding schema validation errors and ensuring legal compliance. https://www.batuz.eus/fitxategiak/batuz/ticketbai/ticketbaiv1-2-2.xsd OPW-4532600 Forward-Port-Of: odoo/odoo#212926 Forward-Port-Of: odoo/odoo#211229
Original PR description
- Vendor bills with taxes of l10n_es_type == 'sujeto_agricultura' (REAGYP) must be reported with regime code '19', as per TicketBAI specifications. - This fix ensures that such invoices include '19' in `regime_key`, avoiding schema validation errors and ensuring legal compliance. https://www.batuz.eus/fitxategiak/batuz/ticketbai/ticketbaiv1-2-2.xsd OPW-4532600 Forward-Port-Of: odoo/odoo#212926 Forward-Port-Of: odoo/odoo#211229
Currently the signature of function `_notify_by_email_prepare_rendering_context` in `account_peppol` is not compatible with all ways to call the super function. This can lead to code breaking when `account_peppol` is installed (although it works fine without). This is fixed in this commit. Detail: In module `mail` the (super) function has signature ```python def _notify_by_email_prepare_rendering_context(self, message, msg_vals=False,
Original PR description
Currently the signature of function `_notify_by_email_prepare_rendering_context` in `account_peppol` is not compatible with all ways to call the super function. This can lead to code breaking when…
Currently the signature of function `_notify_by_email_prepare_rendering_context` in `account_peppol` is not compatible with all ways to call the super function. This can lead to code breaking when `account_peppol` is installed (although it works fine without).
This is fixed in this commit.
Detail:
In module `mail` the (super) function has signature
```python
def _notify_by_email_prepare_rendering_context(self, message, msg_vals=False,
model_description=False,
force_email_company=False,
force_email_lang=False):
```
Currently in `acccount_peppol` the signature is
```python
def _notify_by_email_prepare_rendering_context(self, message, **kwargs):
```
The super function can be called as follows while the function in `account_peppol` can not.
```python
_notify_by_email_prepare_rendering_context(self, message, msg_vals)
```
opw-4846106
Forward-Port-Of: odoo/odoo#213516**Problem:** When setting a customer for an order in the restaurant, it wasn't recorded unless a product was ordered with it. If all we it is add a client in an already existing order, the client won't be recorded and will not be set after we leave the page. **Steps to reproduce:** - Choose a table, create a new order and put a product in it, ordering it is not required. - Go to another table, or just quit the command. - Go back in the initial order, set a client and go to the *orders* ta
Original PR description
**Problem:** When setting a customer for an order in the restaurant, it wasn't recorded unless a product was ordered with it. If all we it is add a client in an already existing order, the client won't be recorded and will not be set after we leave the page. **Steps to reproduce:** - Choose a table, create a new order and put a product in it, ordering it is not required. - Go to another table, or just quit the command. - Go back in the initial order, set a client and go to the *orders* tab without doing anything else. - The order won't have a client, and going back to the order itself, the client is not set. **Why the fix:** The order wasn't read as having changed, so no data was saved. When we set it at first or with a product, it was concidered changed enough for it to be saved. But when changing the customer and only the customer, it wasn't reported to the pending orders. opw-4818110 Forward-Port-Of: odoo/odoo#211942
This commit fixes an action service concurrency test that fails randomly. The way the test was written was prone to errors as we didn't wait for the router to be updated before doing browser back. As a matter of fact, we even asserted that we went 2 actions back in the breadcrumbs, whereas it should be only one as we did one browser.history.back(). runbot error~163078 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
This commit fixes an action service concurrency test that fails randomly. The way the test was written was prone to errors as we didn't wait for the router to be updated before doing browser back. As a matter of fact, we even asserted that we went 2 actions back in the breadcrumbs, whereas it should be only one as we did one browser.history.back(). runbot error~163078 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#213377
Issue: The BuyerReference field in Xrechnung is only mandatory to be filled with the appropriate company reference for DE B2G invoices, but not having the company reference resuts in the field being absent entirely from the document for B2C and B2B invoices, which results in the document being rejected. Solution: If the BuyerReference is not filled, it is set to 'N/A' instead of being left absent from the document. Addresses ticket-4715709 task-4756812 --- I confirm I have signed the CL
Original PR description
Issue: The BuyerReference field in Xrechnung is only mandatory to be filled with the appropriate company reference for DE B2G invoices, but not having the company reference resuts in the field being absent entirely from the document for B2C and B2B invoices, which results in the document being rejected. Solution: If the BuyerReference is not filled, it is set to 'N/A' instead of being left absent from the document. Addresses ticket-4715709 task-4756812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213152 Forward-Port-Of: odoo/odoo#212535
Fix crash when a retention tax is applied on an invoice that includes a down payment line. Steps to reproduce: 1. Create a retention tax (negative, with retention checked) 2. Create a sale order with product A 3. Create and validate a down payment invoice 4. Create the full invoice and add the retention tax to the line of product A 5. Try to submit to ZATCA This raises: `IndexError: list index out of range → tax_category_vals = self._get_tax_category_list(...)[0]` The issue occur
Original PR description
Fix crash when a retention tax is applied on an invoice that includes a down payment line. Steps to reproduce: 1. Create a retention tax (negative, with retention checked) 2. Create a sale order with product A 3. Create and validate a down payment invoice 4. Create the full invoice and add the retention tax to the line of product A 5. Try to submit to ZATCA This raises: `IndexError: list index out of range → tax_category_vals = self._get_tax_category_list(...)[0]` The issue occurs because the retention tax is not filtered due to a missing `filter_to_apply` parameter. opw-4771567 Forward-Port-Of: odoo/odoo#213352 Forward-Port-Of: odoo/odoo#208946
After this PR - transporter gst number is not required while submitting ewaybill if vehicle number is present and mode of transportation is by road - vehicle number can be left empty if transportation document no is set however transporter gst is required for that case task-4807693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213368 Forward-Port-Of: odoo/odoo#211088
Original PR description
After this PR - transporter gst number is not required while submitting ewaybill if vehicle number is present and mode of transportation is by road - vehicle number can be left empty if transportation document no is set however transporter gst is required for that case task-4807693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213368 Forward-Port-Of: odoo/odoo#211088
Current behaviour: --- When displaying a malaysian address on an invoice, the state code is shown. Street 12 Cityname KTN 12345 Malaysia In 17.0 and after, KTN is replaced by MY-03 (and other state codes) per ISO standards KUL -> MY-14, PHG -> MY-06, etc. https://github.com/odoo/odoo/commit/a8204fcf6f919cfa85411f96c11c247e1d0a6f35 Expected behaviour: --- The state name should be displayed instead. Street 12 Cityname Kelantan 12345 Malaysia Steps to reproduce: --- 1. G
Original PR description
Current behaviour: --- When displaying a malaysian address on an invoice, the state code is shown. Street 12 Cityname KTN 12345 Malaysia In 17.0 and after, KTN is replaced by MY-03 (and other state codes) per ISO standards KUL -> MY-14, PHG -> MY-06, etc. https://github.com/odoo/odoo/commit/a8204fcf6f919cfa85411f96c11c247e1d0a6f35 Expected behaviour: --- The state name should be displayed instead. Street 12 Cityname Kelantan 12345 Malaysia Steps to reproduce: --- 1. Go to Contacts 2. Create a new contact 3. Set country as Malaysia, and choose a state 4. Go to Invoice, create one 5. Select new malaysian contact 6. State code in address instead of name Fix: --- Added a custom address_format in res_country_data.xml opw-4762300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212316
This has been allowed since saas-12.5, 6b8acd025758b042cca39508bc8994a1307d1ccd, and is still currently allowed when making a new reconciliation: you can indeed select 2 aml with different partners. But for some reason, in 1b30777ab63998d1c0b64b655e717d74b3648bcf, we added a restriction to disallow changing that afterwards. This took yet another turn with 404fbaeeeb16a65900c60f47967d6d79373c6213, that was allowing the reconciliation on draft entries, but where we explicitly break the reconciliat
Original PR description
This has been allowed since saas-12.5, 6b8acd025758b042cca39508bc8994a1307d1ccd, and is still currently allowed when making a new reconciliation: you can indeed select 2 aml with different partners. But for some reason, in 1b30777ab63998d1c0b64b655e717d74b3648bcf, we added a restriction to disallow changing that afterwards. This took yet another turn with 404fbaeeeb16a65900c60f47967d6d79373c6213, that was allowing the reconciliation on draft entries, but where we explicitly break the reconciliation in case the partner would change... All things considered, the change of partner on draft entries shouldn't break the reconcilation since it's a non-relevant point when reconciling items together. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213561
commit https://github.com/odoo/enterprise/commit/dd38791632c949a682e6ba8ebe4883ba10f713ac caused issues with the nightly builds, with many reports tests failing. see runbot-226477 runbot-226474 runbot-226472 Forward-Port-Of: odoo/enterprise#87215
Original PR description
commit https://github.com/odoo/enterprise/commit/dd38791632c949a682e6ba8ebe4883ba10f713ac caused issues with the nightly builds, with many reports tests failing. see runbot-226477 runbot-226474 runbot-226472 Forward-Port-Of: odoo/enterprise#87215
In the related community commit, we added a constraint that requires the Tax Receivable and Tax Payable accounts on tax groups to be a Receivable or Payable account, be reconcilable and set to Non Trade. In this commit we adapt the current tests that use accounts on tax groups to have their accounts comply to the new constraint. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/odoo/pull/201249 Forward-Port-Of: odoo/enterprise#86571 Forwa
Original PR description
In the related community commit, we added a constraint that requires the Tax Receivable and Tax Payable accounts on tax groups to be a Receivable or Payable account, be reconcilable and set to Non Trade. In this commit we adapt the current tests that use accounts on tax groups to have their accounts comply to the new constraint. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/odoo/pull/201249 Forward-Port-Of: odoo/enterprise#86571 Forward-Port-Of: odoo/enterprise#85693
Before this commit a traceback was occurring when opening an app using palette and then immediately passing a value in palette search input. After this commit the traceback will not occur anymore. task-4735048 Forward-Port-Of: odoo/enterprise#86066
Original PR description
Before this commit a traceback was occurring when opening an app using palette and then immediately passing a value in palette search input. After this commit the traceback will not occur anymore. task-4735048 Forward-Port-Of: odoo/enterprise#86066
Context: The Belgian localisation has two Intrastat report handlers: - Goods: `l10n_be_intrastat.models.account_intrastat_report` - Services: `l10n_be_intrastat_services.models.account_intrastat_services_report` `account_intrastat_report.be_intrastat_export_to_xml()` is the single export entry-point for both. It always calls an internal helper named `_be_intrastat_get_xml_file_content(options, results, company)` and then serialises the returned string. Why it failed: 1. Signature dri
Original PR description
Context: The Belgian localisation has two Intrastat report handlers: - Goods: `l10n_be_intrastat.models.account_intrastat_report` - Services:…
Context: The Belgian localisation has two Intrastat report handlers: - Goods: `l10n_be_intrastat.models.account_intrastat_report` - Services: `l10n_be_intrastat_services.models.account_intrastat_services_report` `account_intrastat_report.be_intrastat_export_to_xml()` is the single export entry-point for both. It always calls an internal helper named `_be_intrastat_get_xml_file_content(options, results, company)` and then serialises the returned string. Why it failed: 1. Signature drift The services override expected a fourth positional argument (`date`), so the shared entry-point raised a `TypeError`. 2. Wrong template prefix The helper tried to render `l10n_be_intrastat.intrastat_services_report_export_xml`, but the template is stored under `l10n_be_intrastat_services`, leading to a `ValueError`. This commit drop the unused `date` parameter and compute the period from options the same way we do in the other function. opw-4834279 Forward-Port-Of: odoo/enterprise#86759
Description ----------- When copying a document, a new attachment is created and linked to the copied document. Since `documents.document.is_multipage` depends on `documents.document.datas`, which is related to `attachment_id.datas`, and `attachment_id` was just written to, `_compute_is_multipage` will be recomputed during flushing before commit, as it's a compute stored field. This is problematic when copying multiple large documents, since this compute reads the entire binary data to dete
Original PR description
Description ----------- When copying a document, a new attachment is created and linked to the copied document. Since `documents.document.is_multipage` depends on `documents.document.datas`, which is related to `attachment_id.datas`, and `attachment_id` was just written to, `_compute_is_multipage` will be recomputed during flushing before commit, as it's a compute stored field. This is problematic when copying multiple large documents, since this compute reads the entire binary data to determine if it's more than one page. This commits explictly writes on `is_multipage` to implicitly add it to the protected fields, which will prevent its' recomputation when flushing. Benchmark --------- Copying 5 documents (PDF) of 50MB each takes in total: | Before | After | Diff | |--------|--------|--------| | 1.61GB | 1.17GB | -27.3% | Reference --------- opw-4829372 Forward-Port-Of: odoo/enterprise#87235 Forward-Port-Of: odoo/enterprise#86885
The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the certificate body: "Durante el año gravable de 2025..." This caused a mismatch when generating certificates for the previous fiscal period (e.g., 2024), especially when the user filtered movements from a prior year. This change ensures that the "año gravable" corresponds to the selected period ye
Original PR description
The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the…
The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the certificate body: "Durante el año gravable de 2025..." This caused a mismatch when generating certificates for the previous fiscal period (e.g., 2024), especially when the user filtered movements from a prior year. This change ensures that the "año gravable" corresponds to the selected period year, taken from the date_from filter in the report wizard, which reflects the actual accounting or fiscal period being certified. Justification According to Colombian tax practices and DIAN guidelines, the "año gravable" mentioned in retention certificates must match the period in which the income or payment was made and the tax was withheld. Using the current date instead of the actual reporting period could lead to confusion or even legal inconsistencies during audits. Reference: Estatuto Tributario Art. 378: Certificates must include the fiscal year in which the withholding was applied. Common practice requires companies to issue certificates reflecting the year of the transactions, not the year of report generation. Forward-Port-Of: odoo/enterprise#86838
**Steps to Reproduce :** 1. Install l10n_cl_edi. 2. Navigate to Contacts create an invoice for CL Company 3. Choose the document type: (33) Electronic Invoice. 4. Confirm the invoice. 5. Ensure the partner has only the street value set (e.g., "Name"), and street2 is empty. **Issue:** When generating the DTE, if street2 is empty, a trailing space appears in the <DirOrigen> tag ex: `DirOrigen>Name </DirOrigen>` **Solution:** Applied strip() to remove the extra space when stre
Original PR description
**Steps to Reproduce :** 1. Install l10n_cl_edi. 2. Navigate to Contacts create an invoice for CL Company 3. Choose the document type: (33) Electronic Invoice. 4. Confirm the invoice. 5. Ensure the partner has only the street value set (e.g., "Name"), and street2 is empty. **Issue:** When generating the DTE, if street2 is empty, a trailing space appears in the <DirOrigen> tag ex: `DirOrigen>Name </DirOrigen>` **Solution:** Applied strip() to remove the extra space when street2 is empty. This ensures no trailing space when street2 is empty and proper spacing when both street and street2 is present. opw-4765451 Forward-Port-Of: odoo/enterprise#85110
Previously, the link used by the “test_winbooks_import” test to download sample data (PARFILUX) from Winbooks was unavailable. This commit changes the url to use directly Winbooks server instead of Amazon, which will allow the test to run without any problem. Forward-Port-Of: odoo/enterprise#87220 Forward-Port-Of: odoo/enterprise#87090
Original PR description
Previously, the link used by the “test_winbooks_import” test to download sample data (PARFILUX) from Winbooks was unavailable. This commit changes the url to use directly Winbooks server instead of Amazon, which will allow the test to run without any problem. Forward-Port-Of: odoo/enterprise#87220 Forward-Port-Of: odoo/enterprise#87090
### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state - Click "Follow-up", select "By post" and send - Settings > technical > Email > Snailmail Letters find the letter corresponding to the report - Check the PDF, it is using the mail template of the first followup level ### Cause: When sending a followup report, the followup level of the repo
Original PR description
### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state…
### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state - Click "Follow-up", select "By post" and send - Settings > technical > Email > Snailmail Letters find the letter corresponding to the report - Check the PDF, it is using the mail template of the first followup level ### Cause: When sending a followup report, the followup level of the report is recomputed for it to have the correct value. Then the report is generated. But the option to send a letter uses methods from the module `snailmail` for example `` which don't have options. The options are then recomputed to generate the report, reading [`partner.followup_line_id`](https://github.com/odoo/enterprise/blob/c8dac822cf3df23922488f33c07a114bbea05198/account_followup/models/account_followup_report.py#L42) so getting the wrong value. ### Solution: Add a context key to pass the value of `followup_line` to the report generation after snailmail. opw-4766804 Forward-Port-Of: odoo/enterprise#86706 Forward-Port-Of: odoo/enterprise#85717
When the post_invoice_hook failed, and sale_subscription_stock was installed, all subscription invoiced would have a "Delivery creation failed" activity created, even if no delivery needed to be created. This commit filter out the subscriptions without any stock lines that needs the stock rule to be run. OPW-4618930 Forward-Port-Of: odoo/enterprise#86190 Forward-Port-Of: odoo/enterprise#85604
Original PR description
When the post_invoice_hook failed, and sale_subscription_stock was installed, all subscription invoiced would have a "Delivery creation failed" activity created, even if no delivery needed to be created. This commit filter out the subscriptions without any stock lines that needs the stock rule to be run. OPW-4618930 Forward-Port-Of: odoo/enterprise#86190 Forward-Port-Of: odoo/enterprise#85604
Before this commit: === - The delivery status buttons (New, Ongoing, Done) and the toggle Switches were misaligned on smaller screens due to the use of grid layout, After this commit: === - The layout uses a flex-based structure, which ensures better alignment and spacing across screen sizes. Task: 4844890 Forward-Port-Of: odoo/enterprise#86904
Original PR description
Before this commit: === - The delivery status buttons (New, Ongoing, Done) and the toggle Switches were misaligned on smaller screens due to the use of grid layout, After this commit: === - The layout uses a flex-based structure, which ensures better alignment and spacing across screen sizes. Task: 4844890 Forward-Port-Of: odoo/enterprise#86904
In Gstr-3B section 3.1(a) credit note/debit note should be calculated. This PR adds credit note/debit note into section 3.1(a). **Older Version PR:** https://github.com/odoo/enterprise/pull/87160 **opw**-https://www.odoo.com/odoo/project/49/tasks/4845457 **Task**-4852947 Forward-Port-Of: odoo/enterprise#87171
Original PR description
In Gstr-3B section 3.1(a) credit note/debit note should be calculated. This PR adds credit note/debit note into section 3.1(a). **Older Version PR:** https://github.com/odoo/enterprise/pull/87160 **opw**-https://www.odoo.com/odoo/project/49/tasks/4845457 **Task**-4852947 Forward-Port-Of: odoo/enterprise#87171
Fixed the computation of `is_vat_duplicated` to avoid false positive in case of partners having both invoices and refunds in the selected period. Forward-Port-Of: odoo/enterprise#87247
Original PR description
Fixed the computation of `is_vat_duplicated` to avoid false positive in case of partners having both invoices and refunds in the selected period. Forward-Port-Of: odoo/enterprise#87247