Tuesday, July 29, 2025
30 changes · saas-18.3
Enhancements to existing features
Point of Sale payments in Argentina, Peru, and Uruguay now request an invoice by default. This helps ensure sales generate the required electronic documents for local compliance.
Original PR description
[IMP] l10n_*: set default invoice true in pos modules: l10n_pe_pos, l10n_ar_pos, l10n_uy_pos In the POS, in the payment screen, the button to request an invoice is set to true by default. This is done because a sale in these countries must generate an electronic document. task-4612192 Forward-Port-Of: odoo/odoo#216003
Point of Sale reversal accounting entries for Indian companies now retain the product HSN code. This helps keep tax reports accurate for GSTR filing even when POS orders are reversed after a session is closed.
Original PR description
This commit ensures that the `l10n_in_hsn_code` is also included in the accounting move lines are generated for reversal entries of POS orders when the The company’s fiscal country is India. Key changes: * Introduced the method `_prepare_product_aml_dict` in `point_of_sale` to centralize journal line creation logic. * Overridden the method in `l10n_in_pos` to append the `l10n_in_hsn_code` from the base values for Indian companies. * Ensured this applies consistently for both regular and reversal entries. This enhancement is essential for maintaining accurate HSN-wise reporting in GSTR filings, even when entries are reversed after session closure. OPW: 4931360 Forward-Port-Of: odoo/odoo#219038
Task searches by name no longer include task IDs in the search criteria, avoiding a slow database query pattern. This makes searching in large project task lists dramatically faster during day-to-day use and busy periods.
Original PR description
### Issue Slowness when searching for tasks in a database containing ~430K `project.task` records. ### Analysis When searching for tasks by name, the `id` field is passed to the filter domain. This results in a suboptimal query plan, as the `id` field is cast as `text` in an `OR` leaf: ` [...] AND ((unaccent((name)::text) ~~* '%test%'::text) OR ((id)::text ~~* '%test%'::text)) [...]` Furthermore, since refactoring the web routes, the necessity of searching for an `id` in the search form has greatly diminished. ### Benchmarks Benchmarking the generated query using `\timing` in `psql`: | Number of records | Before | After | | -- | -- | -- | | 430K | 2.3s | 3ms | During high-usage periods, the query took up to ~10.8 seconds. #### References opw-4845258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219959 Forward-Port-Of: odoo/odoo#219901
When users choose an account while reconciling a bank statement line, any default tax configured on that account is now applied automatically. This reduces manual entry and helps keep accounting data consistent during bank reconciliation.
Original PR description
In this PR: - When setting the account from the bank reconciliation widget (using 'Set Account'), the default tax set on that account will now be automatically applied to the bank statement line. task-4930945
The Knowledge editor now keeps extra space at the bottom of long documents, making it easier to scroll and position text comfortably while writing. This restores a helpful editing behavior that was lost during the editor migration.
Original PR description
With version 18.1, we migrated from legacy HTML editor to the new one. As part of this upgrade, we revised the templates and reworked the wysiwyg helper. During the migration, several CSS classes were altered or removed. One issue that emerged is that the CSS rules intended to add bottom padding to the editor area are still present in the stylesheet but no longer apply to any element. These rules were especially helpful when working with long-form content, as they allowed users to scroll further and bring the end of the text closer to the center of the screen - improving readability and enhancing the editing experience. To fix this, we'll update the relevant CSS selector to ensure the padding is correctly applied to the editable area. See: odoo/enterprise#67083 Task-4636494 Forward-Port-Of: odoo/enterprise#90770 Forward-Port-Of: odoo/enterprise#86223
The database expiration message now better reflects the payment timeline by accounting for the grace period after the next invoice date. This helps customers understand when action is needed and encourages earlier payment before access is at risk.
Original PR description
Previously, the database expiration date was set to the same date as the expiration field, which is now defined as 15 days after the next invoice date. Issue: Users tend to wait until the last minute to pay. This improvement aims to better handle expiration timing and encourage timely payments. TaskID: 4384877 Forward-Port-Of: odoo/enterprise#90931 Forward-Port-Of: odoo/enterprise#90664
When users choose an account while reconciling bank statement lines, any default tax configured on that account is now applied automatically. This reduces manual entry, improves consistency, and helps avoid missed taxes during bank reconciliation.
Original PR description
In this PR: - When setting the account from the bank reconciliation widget (using 'set_account'), the default tax set on that account will now be automatically applied to the bank statement line. task-4930945
Resolved issues and error corrections
This fixes an issue where Point of Sale users could not add products using already existing serial or lot numbers when the operation was configured to reuse them rather than create new ones. Businesses can now process tracked products at checkout as intended, reducing sales interruptions and inventory handling errors.
Original PR description
After commit https://github.com/odoo/odoo/commit/cb31a37508d32110731ad61b04d5d05dc7b31825, when the PoS picking type was configured to use existing lot numbers and not creating new ones, it was not possible to correctly add products with existing lot numbers. opw-4974345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale loyalty rules now treat a combo product as a single item instead of counting each combo component separately. This prevents customers from receiving extra discounts or rewards when buying combo products, keeping promotions accurate and predictable.
Original PR description
Combo lines where counted as products in the loyalty program rules, but they are part of only one product, the combo product. So when you add a combo product to the cart, it should count as one product no matter how many items are in the combo. Steps to reproduce: ------------------- * Create a combo product with 3 products options in it * Create a loyalty program that give 1 point with a minimum quantity of 2. And 100% discount on the cheapest product in exchange of 1 point * Open PoS session * Add the combo product to the cart > Observation: You get 2 discount of 100%. Why the fix: ------------ We ignore combo lines in the loyalty program rules. This way, no matter how many products are in the combo, it will only count as one product for the loyalty program rules. opw-4783013 Forward-Port-Of: odoo/odoo#220828 Forward-Port-Of: odoo/odoo#213002
Customers ordering from a table-specific QR code are no longer asked to choose a table again at payment. This removes an unnecessary step in the self-order flow and helps restaurant orders stay linked to the correct table.
Original PR description
Before this commit, when you made a self order at Table, the table selector was trigger and you had to pick one, even if the tableIndicator was there. In practice, the `selectedTable` in `selfOrder`…
Before this commit, when you made a self order at Table, the table selector was trigger and you had to pick one, even if the tableIndicator was there.
In practice, the `selectedTable` in `selfOrder` was removed by the `selectPreset()` function of `EatingLocationPage`
```js
selectPreset(preset) {
this.selfOrder.currentOrder.setPreset(preset);
this.selfOrder.currentTable = null;
this.router.navigate("product_list");
}
```
That was fixed in 18.2 by this commit : https://github.com/odoo/odoo/commit/5e01d444cfd0594dd88a420129375ae1a6fdfc62
The test `self_mobile_auto_table_selection_takeaway_in` as been added.
Steps to reproduce (in runbot 18.1) :
- Go in Point of Sale > Configuration > Settings
- Select the Restaurant
- Set the Self Ordering Method to QR menu + Ordering
- Save
- Get the code using Print QR Codes
- Open the Table: 1 URL in incognito window
- Make sure the Restaurant is Open and the table 1 have no remaining order
- Select Eat In as eating location and make an order
- When you click pay, the table selection displayed
opw-4641352
Forward-Port-Of: odoo/odoo#219907
Forward-Port-Of: odoo/odoo#214300This update brings the spreadsheet component to its latest version and fixes several issues affecting everyday spreadsheet use. Users should see more reliable row sizing, formula behavior, editing position, pasted content handling, and pivot spreadsheet results.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d30327ce0 [REL] 18.3.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d30327ce0 [REL] 18.3.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/270b64f5a [FIX] header_sizes_ui: preserve row sizes on insert and move ops [Task: 4885579](https://www.odoo.com/odoo/2328/tasks/4885579) https://github.com/odoo/o-spreadsheet/commit/65a3252b4 [FIX] evaluation: test array formula invalidation [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710) https://github.com/odoo/o-spreadsheet/commit/056ce29b9 [FIX] GridComposer: Recompute composer position if we change edited cell [Task: 4879186](https://www.odoo.com/odoo/2328/tasks/4879186) https://github.com/odoo/o-spreadsheet/commit/994301a64 [FIX] auto_complete: remove toggle button for data validation [Task: 4854464](https://www.odoo.com/odoo/2328/tasks/4854464) https://github.com/odoo/o-spreadsheet/commit/bcf0f3ebe [FIX] Composer: Remove formatting when pasting external content [Task: 4910559](https://www.odoo.com/odoo/2328/tasks/4910559) https://github.com/odoo/o-spreadsheet/commit/b9c2fe323 [FIX] Formulas: `COLUMN/ROW` spread with range [Task: 4916369](https://www.odoo.com/odoo/2328/tasks/4916369) https://github.com/odoo/o-spreadsheet/commit/5626d48fe [FIX] spreadsheet_pivot: empty row when number added to char field [Task: 4878778](https://www.odoo.com/odoo/2328/tasks/4878778) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes an error that prevented accounting users without administrator rights from printing Saudi ZATCA invoices. The change ensures the invoice QR code can still be generated safely, so invoice printing works for regular authorized users.
Original PR description
**Steps to reproduce:** 1. Install Accounting and l10n_sa_edi 2. Switch to a SA company 3. Go to Accounting > Configuration > Journals > Sales > ZATCA > Re-onboard 4. Create or duplicate a customer…
**Steps to reproduce:** 1. Install Accounting and l10n_sa_edi 2. Switch to a SA company 3. Go to Accounting > Configuration > Journals > Sales > ZATCA > Re-onboard 4. Create or duplicate a customer invoice > Confirm 5. Click on blue banner "Process Now" 6. Log in as a non-admin user (e.g., Marc Demo) and Switch to a SA company 7. Go to invoice > Open Same invoice > Click to "PRINT" **Issue:** - A traceback is raised when trying to access the attachment linked to the ZATCA document. **Cause:** - Since commit https://github.com/odoo/odoo/commit/44a4cdb3944a4b722dcfbca5e2947a4372b8501d, access to EDI document's attachment (`attachment_id`) is restricted to users belonging to "Role > Administrator" group (`group_system`). - This was introduced as part of changes from Task [#4341594](https://www.odoo.com/odoo/project/49/tasks/4341594) As a result, non-admin users (even with accounting rights) are unable to access the attachment causing a traceback. **Solution:** - Apply `compute_sudo`to field `l10n_sa_qr_code_str` to bypass the restrictive access rights. So even if for any case any other field causes issues in the future, compute_sudo will take care of it **opw-4923399**
Pivot tables in spreadsheets now display the proper names when data is grouped by an ID field, instead of showing blank row or column headers. This makes spreadsheet reports easier to read and ensures test data reflects the same behavior users see in Odoo.
Original PR description
**Description of the issue/feature this PR addresses:** When inserting a pivot table in a spreadsheet and grouping by an `id` field, the pivot column or row headers appear blank instead of showing…
**Description of the issue/feature this PR addresses:** When inserting a pivot table in a spreadsheet and grouping by an `id` field, the pivot column or row headers appear blank instead of showing the expected label. This issue stems from two inconsistencies: 1. The `_sanitizeLabel` logic used to normalize pivot headers did not properly handle groupby values for `id` fields that are returned as `[id, label]` arrays. It treated them as truthy values but didn't extract the label. 2. The mock `read_group` implementation did not follow backend logic for `id` fields. It returned raw integers instead of `[id, display_name]`, breaking the label extraction expected by the pivot UI. **Current behavior before PR:** - Pivot headers for grouped `id` fields are blank in spreadsheets - Mock data returns raw IDs, causing the display logic to fail **Desired behavior after PR is merged:** - The pivot UI correctly extracts and displays labels for `id` groupings - The mock `read_group` aligns with backend by returning `[id, label]` for `id` fields, matching the behavior of relational fields Task: 4878685 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219206
On mobile, selecting a subtask from a task now opens it in the main screen instead of a pop-up. This makes the discussion area visible, so users can communicate with customers directly from the subtask.
Original PR description
Before this commit, when the user is in mobile view and go to a task with subtasks and selects a subtask, the form view of that subtask is opened inside a dialog form view instead of opening the…
Before this commit, when the user is in mobile view and go to a task with subtasks and selects a subtask, the form view of that subtask is opened inside a dialog form view instead of opening the record in the main view. Because of that, the chatter for that subtask is not displayed. This commit opens the form view in the main view instead of opening it inside a form view dialog to be able to display the chatter of the subtask selected. Steps to reproduce the issue: ---------------------------- 1. Install project and go to project app. 2. Create a project A. 3. Add a task inside the project A 4. Add a subtask inside the new task created in step 3 5. Open the form view of the task created in step 3 in mobile 6. Click on the kanban record contained the subtask created in step 4 Expected behavior: ----------------- The chatter should be displayed in the form view of that subtask to be able to communicate with the customer. Current behavior: ---------------- Since the form view of the subtask selected is opened inside a form view dialog the chatter for that subtask is not displayed. task-4278273 Forward-Port-Of: odoo/odoo#220569 Forward-Port-Of: odoo/odoo#200178
The Send & Print wizard now correctly shows relevant e-invoice warnings for Indian localization. This helps users catch and address invoice issues before sending, reducing missed compliance or processing problems.
Original PR description
Before this PR, warnings that should be displayed while sending e-invoices through the Send & Print wizard was not shown because the `_group_by_error_code` method always returned False. With this PR, the method has been corrected to return the appropriate key based on the warning, ensuring that relevant messages are now properly displayed Forward-Port-Of: odoo/odoo#220036
Invoices can now be confirmed when a journal sequence prefix contains Greek letters. This prevents an error in Accounting for businesses using European communication standards with localized prefixes.
Original PR description
**Issue** Using a Greek letter in the journal's sequence prefix causes a traceback error when confirming an invoice **Steps to Reproduce** 1. Install the Accounting module 2. Navigate to Accounting >…
**Issue** Using a Greek letter in the journal's sequence prefix causes a traceback error when confirming an invoice **Steps to Reproduce** 1. Install the Accounting module 2. Navigate to Accounting > Configuration > Journals 3. Open the Sales journal 4. Under the Advanced Settings tab, set the communication standard to "European" 5. Set the sequence prefix to include Greek letters (e.g., "TΠY") 6. Create and confirm a new invoice 7. Observe the traceback error **Root Cause** The prefix is used in calculating the `check_digits` via a base-36 to base-10 conversion. This conversion fails for Greek characters, which are not valid in base-36, leading to an exception **Fix** Greek letters in the prefix are transliterated to their Latin equivalents before performing the checksum calculation, ensuring compatibility with the base-36 conversion logic Opw-4813790 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212169
Malaysia electronic invoices now place prepaid amounts in the format expected by the MyInvois platform. This helps prevent invoice submission issues when prepayments are included.
Original PR description
Before: Prepaid Amount was submitted under LegalMonetaryTotal node, which follows UBL format but not supported for MyInvois. After: Introduced separate PrepaidAmount node used specific to Malaysia to support MyInvois. taskID-4947994 Forward-Port-Of: odoo/odoo#220612 Forward-Port-Of: odoo/odoo#219419
This fix improves Turkish Nilvera e-invoice XML generation so invoices include required exchange-rate and discount information. It also adjusts the invoice amount layout to match Nilvera validation rules, reducing the risk of rejected e-invoices.
Original PR description
This commit does following fixes for e-invoice XML generated for Nilvera. - adds currency exchange rate as note in XML if invoice currency is other than TRY. - adds total discount amount at the Invoice document level. - creates a new XML template for TR e-invoice inherited from the UBL Invoice Template. - removes the `<cac:PrepaidAmount>` node as it is not a valid node in Nilvera and adds the node value to `<cac:PayableAmount>` so that actual invoice amount is preserved while sending e-invoice. TaskID:4815875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220513 Forward-Port-Of: odoo/odoo#216594
Invoices and sales orders now correctly recognize foreign customers whose countries do not define states. This prevents them from being treated as Indian domestic customers, helping ensure accurate GST calculations and compliance for overseas transactions.
Original PR description
Before this PR: When creating invoices/orders for foreign customers that don't have states defined in their country, both **account.move** and **sale.order** models would incorrectly assign the…
Before this PR: When creating invoices/orders for foreign customers that don't have states defined in their country, both **account.move** and **sale.order** models would incorrectly assign the company's Indian state as the place of supply. This happened because the fallback logic would always use **move.company_id.state_id** without checking if the partner was actually Indian. As a result, foreign customers would be treated as Indian customers in GST calculations, leading to incorrect tax treatment and compliance issues. After this PR: Both models now correctly identify foreign customers by checking the partner's country first, before falling back to state-based logic. Foreign customers without states are now properly assigned the foreign state reference (**l10n_in.state_in_oc**) instead of the Indian company's state. This ensures accurate GST treatment where foreign customers are correctly identified as overseas transactions. Task-4900697 Forward-Port-Of: odoo/odoo#220717 Forward-Port-Of: odoo/odoo#216220
Users will now see a clear, friendly warning dialog when certain server actions need to show warnings, instead of a technical traceback. This reduces confusion and makes the issue easier to understand and act on.
Original PR description
### Description of the issue/feature this PR addresses: https://github.com/odoo/odoo/commit/ef4c1350df10c186efec79b1414306e325707549 introduced a new exception `ServerActionWithWarningsError`:…
### Description of the issue/feature this PR addresses: https://github.com/odoo/odoo/commit/ef4c1350df10c186efec79b1414306e325707549 introduced a new exception `ServerActionWithWarningsError`: https://github.com/odoo/odoo/blob/851c46923332aa13c56fbce3a5ed3c5d37a70c92/odoo/addons/base/models/ir_actions.py#L486-L488 This was not registered as an error_dialog. This led to the frontend displaying the entire traceback instead of an error dialog similar to `UserError` when a `ServerActionWithWarningsError` is raised. This commit fixes it by correctly registering the error in `error_dialog` registry category so a more user friendly dialog is displayed with the error contents. Thanks @brboi for helping with the fix ### Current behavior before PR: A traceback error is thrown when a `ServerActionWithWarningsError` is raised. Example: <img width="1896" height="904" alt="image" src="https://github.com/user-attachments/assets/0bfee329-e6c5-4652-a2ac-d41b763e2bdb" /> Video reproducing it: https://drive.google.com/file/d/1C_aE0d_9bP27f388dB1NJLeWHBpsM7AW/view?usp=drive_link (credits: gavb-odoo) ### Desired behavior after PR is merged: An error dialog similar to UserError which is easier to understand is displayed <img width="1906" height="799" alt="image" src="https://github.com/user-attachments/assets/d57c5cab-14f2-4f39-9f0c-b8099e8b0089" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr opw-4885670 Forward-Port-Of: odoo/odoo#219977
Sales commission achievement reports now include down payments and other invoice lines that do not have a product assigned. This fixes discrepancies where commission totals could be lower than invoice analysis totals, even when the commission plan rate was set to 100%.
Original PR description
In the sale achievement report, down payments and other account move lines that have no product attached to them would not be accounted for in the sale commission achievement report. This was due to the fact that the table was being inner joined on product_id which would get rid of records that had no product. Because of this behavior there would be a mismatch between the invoice analysis of a user and their commission even if the rate was 100% on the commission plan. Left joining the products onto the account move line keeps the lines with no products and fixes the discrepancy between the report and the invoice analysis. opw-4625340 Forward-Port-Of: odoo/enterprise#91010 Forward-Port-Of: odoo/enterprise#83477
Users working in multiple companies can now send signature requests from templates they created in the company they are currently using. This prevents an access error caused by the system using the creator's default company instead of the active company for the request.
Original PR description
Problem: In a multi-company environment, users are unable to send templates in non-default companies despite them creating the template. A traceback gets thrown because the template is using the…
Problem: In a multi-company environment,
users are unable to send templates in non-default
companies despite them creating the template.
A traceback gets thrown because the template
is using the default company on the create user,
instead of the current environment's company.
Purpose: The user should be able to send templates they created in any allowed companies.
Steps to Reproduce on Runbot:
[ADMIN]
1. Install Sign
2. Navigate to Settings > Sign > Enable "Sign Default Terms & Conditions"
3. Create another company and allow Marc Demo access
[Marc Demo]
1. Change to a non-default company
2. Try to send a signature request (e.g. upload pdf to sign > send)
3. Traceback gets thrown
```
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/mylynahy/src/odoo/odoo/fields.py", line 1161, in __get__
value = env.cache.get(record, self)
File "/home/mylynahy/src/odoo/odoo/api.py", line 1020, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'res.company(2,).sign_terms_type'
During handling of the above exception, another exception occurred:
...
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
AccessError: Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.
Records: BE Company CoA (id=2)
User: Marc Demo (id=6)
This restriction is due to the following rules:
- company rule employee
Note: this might be a multi-company issue.
Contact your administrator to request access if necessary.
Template: sign.sign_template_mail_request
Path: /t/table/tr[5]/t[1]/td/a
Node: <a t-att-href="\'%s/sign/terms\' % record.get_base_url()" class="text-dark"/>
```
opw-4706828
Forward-Port-Of: odoo/enterprise#85402Bank statement imports started from the accounting dashboard now process every batch in the uploaded file instead of stopping after the first batch. The import page also shows the correct uploaded file name, making the process more reliable and clearer for users.
Original PR description
**PROBLEM** When importing bank statements from the dashboard, it only imports the first batch (by default the first 2000 lines) instead of importing the whole file. This is inconsistent with the…
**PROBLEM** When importing bank statements from the dashboard, it only imports the first batch (by default the first 2000 lines) instead of importing the whole file. This is inconsistent with the behavior of the import done from the reconcilation page. Also, on the import page, the file name is incorrect (it's always `bank_statement_import.csv`) **STEP TO REPRODUCE** file to reproduce the issue : [MP 2280260435_movements_-2025-04-01-191536.xlsx](https://github.com/user-attachments/files/20880784/MP.2280260435_movements_-2025-04-01-191536.xlsx) 1. install the accounting module 2. goes on the dashboard, click on the 3-dot button on the kanban for the bank account, and import a file. 3. make sure the file will be imported in multiple batches (reduced the batch size to 200) and click on import. 4. notice how only the first batch was imported. **CAUSE** In python, The `AccountBankStmtImportCSV` class override the execute_import method of the `base_import.import`. In this override, we add a entry in the `messages` list. (see `enterprise/account_bank_statement_import_csv/models/account_bank_statement_import_csv.py`) In JS, all entry in messages are treated as errors, and the import is interrupted. (see `odoo/addons/base_import/static/src/import_model.js`) https://github.com/odoo/odoo/blob/389b355e7ec761fe8dc2908ac5aec540b0345c48/addons/base_import/static/src/import_model.js#L410-L417 The message entry added in the python was used in the past to automatically open the reconcillation page with the statement lines added. This feature was removed, but not the message. **FIX** - Remove the problematic message entry. - Fix the name of the file in the import action. opw-4823808 Forward-Port-Of: odoo/enterprise#88343
Spreadsheet pivots grouped by ID now display the correct record names instead of blank or numeric headers. This makes pivot reports easier to read and keeps spreadsheet behavior aligned with the main Odoo server results.
Original PR description
Steps to reproduce: - Insert a pivot in a spreadsheet - Add a groupby on id - Insert the spilled formula - Headers are empty Before this commit: - _sanitizeLabel treated integer id values as raw, skipping the label in [id, label] - The mock read_group returned plain numbers for id, unlike the server - Enterprise tests still expected FALSE/ids in PIVOT.HEADER and tooltips After this commit: - _sanitizeLabel returns the label for [id, label] without numbering id - The mock read_group now returns [id, display_name] for id - Enterprise pivot tests updated to expect labels and adjusted ranges Task: 4878685 Forward-Port-Of: odoo/enterprise#90656
Indian GSTR-1 HSN reports now include point-of-sale orders that were reversed after session closure. This prevents missing product and tax details in compliance reports, improving reporting accuracy for affected businesses.
Original PR description
Before this change, HSN summary generation skipped POS reversal journal entries, which could lead to missing product and tax data for reversed orders made After the session closure. This commit improves the `_get_gstr1_hsn_json` method by: * Including reversed POS orders (`reversed_pos_order_id`) in the POS order list. * Ensuring their corresponding order lines are considered during HSN data aggregation. This ensures accurate HSN reporting even for POS reversals processed as standalone entries. OPW: 4931360 Forward-Port-Of: odoo/enterprise#90248
Credit card payments in the Italian point of sale are now assigned the correct default payment index. This prevents Italian fiscal printers from incorrectly treating these card payments as unpaid.
Original PR description
In Italy if a payment method is of type 'Credit card' (type 2), and it's index is 0 the payment made with it is considered as 'Not paid' by the italian fiscal printer. Why the fix: ------------ We change the default index of the payment method to 1, so that it is considered as 'Paid' by the fiscal printer. opw-4963421 Forward-Port-Of: odoo/enterprise#90919
Creating a helpdesk ticket from the timesheet timer now correctly uses the selected support project, preventing validation errors about missing analytic accounts. The timer also recognizes helpdesk projects even before any tickets exist, so users see the proper ticket option instead of being prompted to create a task.
Original PR description
Steps to reproduce: ------------------- - Install 'helpdesk_timesheet' module - Go to Timesheets and click on `Start` to launch the timer - Select `VIP Support` as Project - Create a new ticket…
Steps to reproduce: ------------------- - Install 'helpdesk_timesheet' module - Go to Timesheets and click on `Start` to launch the timer - Select `VIP Support` as Project - Create a new ticket Issue: ------ 1. Validation error raised: `At least one analytic account must be set.` 2. When we select a helpdesk project that does not have any ticket linked to it already, the field next to it is set to `Task` (task_id) instead of `Ticket` (helpdesk_ticket_id). Cause: ------ 1. When creating the ticket, we don't provide the default project who got the analytic account linked to it. 2. The field `helpdesk_ticket_id` is hidden because we consider that we the project is not linked to any helpdesk team; this is because we retrieve the projects based on tickets already created only. Solution: --------- 1. Set the default project in the context when creating the ticket (like for a task). In the create method, if no team is provided and we have a default project (from `list_value` or the `env.context`), we set the team based on the project if the project is linked to a helpdesk team. 2. Fetch all projects that have `helpdesk_team` field set. opw-4404097 Forward-Port-Of: odoo/enterprise#90998 Forward-Port-Of: odoo/enterprise#76779
Sales orders created from field service with zero-priced products now correctly show as ready to invoice when Anglo-Saxon accounting is enabled. This allows businesses to issue invoices for these items instead of having them incorrectly marked as having nothing to invoice.
Original PR description
Before this commit: When Anglo-Saxon accounting is enabled and a product with sale price of zero is added to SO through field service, the invoice_status show 'Nothing to Invoice'. After this commit: With Anglo-Saxon accounting enabled, adding product with a zero sale price to an SO through field service will display the invoice_status as 'To Invoice' instead of 'Nothing to Invoice'. task-3957962 Forward-Port-Of: odoo/enterprise#70132
This update fixes errors that could interrupt appointment booking when customers use invitation links with multiple assigned resources or users. Customers can now move back through the booking progress bar without seeing server or access errors, making the appointment flow more reliable.
Original PR description
Fixes two issues regarding the buttons on the front-end progress bar in the appointment flow, when using an invitation link. Commit messages give steps to reproduce.
1. Fix 500 error when clicking 'Date & time' with more than one resource / user configured on the invitation link.
2. Fix 403 error when using the operator ('meeting' actually) step button with more than one specific resource in the invitation link.
Task-4897098
Forward-Port-Of: odoo/enterprise#90335
Forward-Port-Of: odoo/enterprise#88521Rental orders with multiple lines for the same planned service now avoid assigning overlapping shifts to the same resource. If no suitable resource is available, the system creates an unassigned open shift instead, helping planners avoid double-booking and scheduling conflicts.
Original PR description
Steps to Reproduce: ---------------------- - Install the sale_renting_planning module. - Create a rental service product with `Plan Services` enabled. - Create a rental order with multiple lines for the same product. - Confirm the rental order Issue: --------------------------- - You'll see that some generated shifts are assigned to same resource causing conflict. Cause: --------------------------- - Shifts are being generated at the same time for all the SOL which cause them to be assigned to the same resource and make conflict. Fix: ----------------------------- - In this commit when the shift values are generated we will check if the resources are available or not. If no resource is available then it will create open shift for that SOL. task-4829807 Forward-Port-Of: odoo/enterprise#88767