Daily updates from Odoo
Saturday, June 27, 2026
29 changes · master
Resolved issues and error corrections
The bank reconciliation search dialog now displays full reference text instead of cutting it off. Date and balance information is aligned at the top, making entries easier to review and compare.
Original PR description
This commit will remove the text-truncate from the reference so that we have it full. Also removing the align item so that the date and balance are on top. no task id Forward-Port-Of: odoo/enterprise#121078 Forward-Port-Of: odoo/enterprise#120963
Automatic bank reconciliation rules now keep each statement line's original payment reference instead of replacing it with the account name. This makes reconciliation entries consistent with the manual Set Account flow and helps users identify transactions accurately.
Original PR description
### Issue: When creating an automatic reconciliation rule by assigning the same account to multiple bank statement lines, the rule incorrectly overrides the original payment reference of subsequent…
### Issue: When creating an automatic reconciliation rule by assigning the same account to multiple bank statement lines, the rule incorrectly overrides the original payment reference of subsequent lines with the account name This creates an inconsistent user experience Using the "Set Account" button directly keeps the statement line payment reference as the journal item label However, clicking the automatically generated reconciliation model button replaces that reference with the account name Before the fix, clicking the automated rule button on a third matching line overrides its label with the account name instead of keeping its unique reference ### Cause: In `_create_reconciliation_rule`, when an automatic model is generated, the dictionary used to create the counterpart line explicitly set `label` to `rule_data['account'].name` When a reconciliation model line has a specific label defined, Odoo uses it to replace the statement line `payment_ref` on the generated counterpart move lines Removing this default value allows the system to fall back on the original payment reference ### Steps to reproduce: - Install `account_accountant` - Go to the Bank Reconciliation widget from the Accounting Dashboard - Create 2 statement lines without partners (e.g., Ref: "Test Ref 1" and "Test Ref 2") - Set the same account on both lines using Set Account - This automatically creates a Reconciliation Rule named after the account - Create a 3rd statement line with a matching reference (e.g., "Test Ref 3") - Click the newly available automatic reconciliation button for this line Before the fix, checking the generated entry label shows the account name instead of "Test Ref 3" To check unfold the details, click on the pencil icon of a line opw-6246833 Forward-Port-Of: odoo/enterprise#121850 Forward-Port-Of: odoo/enterprise#119133
The German SKR03 accounting template now uses the correct default accounts for cash discounts. This helps German companies avoid incorrect account mappings in financial reports and exports.
Original PR description
The default cash discount accounts referenced in the German skr03 template used the wrong account codes. The template has been updated with the right ones. task-4915939 opw-4909059 Forward-Port-Of: odoo/enterprise#121692 Forward-Port-Of: odoo/enterprise#121180
Opening a billing time target could fail for users with timesheet access but without employee access. The update adds the missing leave information needed by the page, so users can view billing targets without interruption.
Original PR description
Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `leave_date_to` and `current_leave_id` field, change made from odoo/odoo@0496ed1 and https://github.com/odoo/odoo/commit/4b5089694436aa00254666e10cd2106b21adfe2b - Thus unavailability of field causing the traceback. Fix: - Add a related field for leave_date_to from which we get the value. Forward-Port-Of: odoo/enterprise#121888 Forward-Port-Of: odoo/enterprise#121571
This change ensures customer addresses in Field Service planning cards stay within the card instead of spilling past the edge when the address is long. It improves readability and keeps the kanban view visually consistent for users with customers that have detailed address lines.
Original PR description
Steps to reproduce: - 1. Open the Field Service planning view in kanban. 2. Make sure a shift's customer has a long address (long street lines). 3. Look at that shift's card in the kanban view. Issue: - The customer address overflows the card and is clipped at its right edge instead of staying within the card boundaries. Cause: - The customer is rendered with the `many2one` widget and `show_address`, which marks each address line `text-truncate`. Truncation only works inside a width-bounded container, but the field root `.o_field_many2one` is an inline-flex item with the default `min-width: auto`, so it grows to fit the longest address line instead of shrinking to the card. As a result, `text-truncate` never engages and the address spills past the card. Fix: - Add the `min-w-0` class to the partner field so the flex item shrinks to the available card width. task-6272209 Forward-Port-Of: odoo/enterprise#119248
The planning app no longer shows the shift role warning to users who cannot act on it. This reduces confusion for regular users while keeping the warning available to administrators who can assign roles and resolve the issue.
Original PR description
This commit hides the warning about a resource missing the shift's role from users without the "Planning > Administrator" access right, as only administrators can assign roles and act on the warning. task-6303545 Forward-Port-Of: odoo/enterprise#121447
Spanish companies can now open the Mod 349 tax return without the system crashing. The fix avoids a report check that assumed a different report layout, preventing an error when users access Tax Returns.
Original PR description
Steps to reproduce: - Install `Accounting` and `l10n_es` module - Switch to `Spain` company - Open `Tax Returns` Traceback: ```py File…
Steps to reproduce:
- Install `Accounting` and `l10n_es` module
- Switch to `Spain` company
- Open `Tax Returns`
Traceback:
```py
File "/data/build/enterprise/account_reports/models/account_return.py", line 2699, in _check_suite_common_ec_sales_list
engine_results = custom_handler._report_engine_ec_sales_report(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_sales_report.py", line 396, in _report_engine_ec_sales_report
return {next(iter(formulas_dict.values())): results}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
StopIteration
```
Cause:
In the method `_check_suite_common_ec_sales_list`, `formulas_dict` is built by taking `line_ids[0].expression_ids.grouped('formula')`. This assumes the first report line always has expressions defined, which holds true for standard EC Sales List reports.
However, Mod 349 has a different report structure where the first line is a "Summary" line with no expressions, resulting in `formulas_dict` being an empty dict. When `_report_engine_ec_sales_report` then calls
`next(iter(formulas_dict.values()))` to retrieve the formula key, it raises a `StopIteration` error, causing a crash whenever a Spanish company opens the tax return report.
Solution:
Override `_check_suite_common_ec_sales_list` for Mod 349 to only run the basic checks, bypassing the engine call that caused the crash. All other return types still go through the generic suite via `super()`.
opw-6222938
sentry-7513259974
Forward-Port-Of: odoo/enterprise#117850This change fixes an issue in Mexican electronic invoicing where invoices with many related document links could fail to save or search correctly. It improves reliability for complex cancellation cases while keeping lookups fast.
Original PR description
The field `l10n_mx_edi_cfdi_origin` can contain a large number of associated UUIDs, especially in complex cancellation scenarios. The default B-tree index fails when this field exceeds 2704 bytes, which occurs after approximately 20 UUIDs. By switching to a trigram index, we avoid the entry size limit of PostgreSQL's B-tree nodes. This ensures that invoices with many related documents can be processed while maintaining efficient search performance for partial matches on this field. **Video before the fix:** https://youtu.be/24u0HbxwIH8 **Video after the fix:** https://youtu.be/sUelv1HZMvI Forward-Port-Of: odoo/enterprise#118868
This fix ensures the Tickets Closed number matches the tickets that should be counted, excluding tickets closed today. It makes the helpdesk dashboard and related filters more accurate for users reviewing recent activity.
Original PR description
Before: The Tickets Closed number matches the actual tickets when clicking on it. It shows the tickets closed today, which should be excluded. After: Change the domain of the `ticket_closed` to be able to exclude tickets that are closed today --- task-6234330 Forward-Port-Of: odoo/enterprise#120454
This update prevents Italian fiscal printers from failing when product, payment method, or POS names include unsupported space-like characters. It replaces those characters with standard spaces before sending the print command, helping receipts print correctly and avoiding interrupted sales.
Original PR description
Steps to reproduce: - Setup an Italian fiscal printer - Modify the name of a product to use the non-blocking space character "\ "; - In the POS, create an order with the product. Error: the fiscal device will stop midway in the printing process and return an incomplete response to the frontend. The issue can also be reproduce if the character is included in the payment method name or the POS config name. Solution: When formating the xml command, replace all non-supported character by a space character. The non-supported character list is provided by the official [EPSON fiscal printer documentation](https://support.epson.net/setupnavi/?PINF=bsmanual&OSC=WS&LG2=EN&MKN=FP-90III%20RT) in the document "ePOS Fiscal Print Solution Development Guide". Other: Rename the file "dispaly_text.xml" to "display_text.xml". [opw-6244089](https://www.odoo.com/odoo/project/49/tasks/6244089) Forward-Port-Of: odoo/enterprise#121538 Forward-Port-Of: odoo/enterprise#120169
Subscription reports now ignore non-recurring products when calculating monthly and yearly recurring revenue. This prevents inflated figures if users remove the built-in recurring filter in the report view.
Original PR description
While investigating a support ticket, we noticed that in subscription reports, recurring revenue values (MRR and YRR) are implicitly calculated for non-recurring products. This doesn't cause a direct problem when using the default search domains applied in Subscription > Reporting > Subscription > Pivot view, because a "Recurring" filter is pre-applied. But if the end user removes said filter, they might accidentally fudge the MRR and YRR numbers because the non-recurring products will contributed to the relevant grouping sums. We fix this by adding a CASE clause to explicitly ignore non-recurring products when calculating the report field for MRR and YRR , i.e. only consider `t.recurring_invoice = TRUE`. OPW-6315091 Forward-Port-Of: odoo/enterprise#121566
This fix ensures barcode scans can correctly find lots even when the lot number contains special characters or begins with the GS1 code used to identify lots. As a result, stock operations like internal transfers will no longer fail to recognize the lot and will validate properly after scanning.
Original PR description
When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db. **Steps to reproduce** * In settings activate: - Lots & Serial…
When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db. **Steps to reproduce** * In settings activate: - Lots & Serial Numbers - Units of Measure & Packagings - Storage Locations - Barcode Scanner : GS1 nomenclature * Create a Product tracked by lot with - barcode: 00001234567895 * Add on hand quantity: - 100 kg in lot : 10002002303-4 - 100 kg in lot : 11002002303-4 * Go to barcode>Operation>Internal Transfer>New * Scan 02000012345678951010002002303-4#3100000100 meaning: - 02 following 14 characters are the product barcode - 10 following characters are the lot number - "#" separator - 3100: means the units are kilograms, - 00100 means 100 units. -> if you check with the edit button the lot was not found (if you click on validate it will trigger an UserError for missing lot) **Observation** When scanning the GS1 barcode it will call onBarcodeSubmitted->onBarcodeScanned where we will execute processBarcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/components/main.js#L387 Where we will deconstruct the barcode into his component en retrieve from the db the relevant data: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/models/barcode_model.js#L709-L717 - First the barcode is parsed, identifiers are erased and each section is separated, the variable with our lot number only has the lot number in it, the identifier (10) is not included, BarcodeObject.forBarcode(bc) -> new BarcodeObject -> parser.parse_barcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/barcode_object.js#L14 - Check if the data is in the cache, if not, set it to retrieve after - Retrieve missing data getMissingRecords : https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/lazy_barcode_cache.js#L349 From here we will get a call to get_specific_barcode_data for each element: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L176 In the case of the stock.lot since it has a symbol and it's not only digit it will skip the gs1 nomenclature domain converter (it will not become 'ilike' and stay with 'in'): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L182-L197 We will do the search: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L205 during which we will retrieve specific query from the stock.lot module : https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/odoo/orm/models.py#L1408 Where, since it's a GS1 nomenclature, we will preprocess the agrs: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/models/stock_lot.py#L14 -> Since our barcode start with a 10, it will erase it, which lead to a miss in the search. It will also avoid further searches since we avoid multiple search on the same elements (added in missingBarcodeKeyCache in getMissingRecords). https://github.com/odoo/enterprise/blob/c6d18a7a92092ffdf96f4569a70e95bdc276441c/stock_barcode/static/src/lazy_barcode_cache.js#L294-L298 opw-6207120 Forward-Port-Of: odoo/enterprise#118828
This change fixes access rights for completed signed documents so they stay consistent after completion. It helps ensure the right people can view or handle finalized documents without unexpected permission issues.
Original PR description
Forward-Port-Of: odoo/enterprise#121576
This change fixes an issue where ticket status labels could appear differently depending on the view. After the update, list and form views now show the same renamed status labels as the kanban view, so users see consistent wording everywhere.
Original PR description
Steps to reproduce: ------------------------ 1. Install Helpdesk 2. Go to All Tickets and check the kanban state selection value 3. Go to Settings > Field Selection and search for kanban_state in…
Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views
Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").
Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.
Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.
Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999
opw-6238765
Forward-Port-Of: odoo/enterprise#119707This update corrects how rental prices are shown on the website product configurator. The price now appears in the expected format with a slash between the amount and the rental period, making it clearer for customers.
Original PR description
Steps to produce: --- - Install the `Rental and eCommerce `modules. - Create a rental product and configure a rental price for it. - Add an optional product from the Sales tab. - Publish the product…
Steps to produce: --- - Install the `Rental and eCommerce `modules. - Create a rental product and configure a rental price for it. - Add an optional product from the Sales tab. - Publish the product on the website. - Open the product page on the website and click` Add to Cart`. Issue: --- - In the product configurator, the rental price is displayed without the `/` separator between the price and the rental duration period. Cause: --- - The string used to generate the rental duration label does not include the `/` separator. Fix: --- - Add the missing `/` separator to the rental duration label so that rental prices are displayed correctly. Before: --- <img width="974" height="185" alt="image" src="https://github.com/user-attachments/assets/64a88a60-bcc0-4657-97fd-584da57d0aff" /> After: --- <img width="967" height="188" alt="image" src="https://github.com/user-attachments/assets/b4d50019-1db4-4817-a8ce-446cc3c55df4" /> opw-6293015 Forward-Port-Of: odoo/enterprise#121637 Forward-Port-Of: odoo/enterprise#120223
Tax unit members who are not part of the main company can now see tax return checks as well as tax returns. This helps them identify and correct issues that would otherwise block their tax filings.
Original PR description
Before this commit: Tax Unit Members other than main company have read access to tax returns but don't have read access to tax return checks. After this commit: Tax Unit members other than main company are given read access to tax return checks also, so they can fix checks failing because of them. task-5951364 Forward-Port-Of: odoo/enterprise#113118
This change fixes a test in the SEPA direct debit flow that could try to confirm a payment twice under certain module setups. It helps prevent test failures and keeps the payment process checks reliable across different configurations.
Original PR description
The `test_expiry` test creates a payment via the `pay_with_mandate` method. Depending on eg. the installed modules, the resulting payment ends up either `paid` or `reconciled`. Afterwards, the test tries to validate the payment, which requires that it not be in the `reconciled` state. This causes an error linked below. This PR adds a condition to ensure the payment is in the `paid` state before attempting to validate it. Error: https://runbot.odoo.com/odoo/error/240557 Forward-Port-Of: odoo/enterprise#112224
This change makes the French VAT submission use the correct form version based on the reporting period. It prevents reimbursement and VAT returns from being rejected by the tax authority when the campaign year changes.
Original PR description
The 3519 reimbursement form is rejected by the DGFiP with "Le millesime 25 du formulaire 3519 est inconnu dans la teleprocedure TVA". The 3310CA3 return is still accepted, because its layout is unchanged year-on-year, which hides the problem, but it is sent with a millesime that no longer matches the campaign. The millesime is the form-version year. The EDI-TVA 2026 campaign opened on 2026-02-09. last update: https://github.com/odoo/enterprise/pull/92542 opw-6275695 Forward-Port-Of: odoo/enterprise#120969 Forward-Port-Of: odoo/enterprise#120759
This update prevents overtime records from overlapping when an employee’s attendance spans multiple days. It fixes an error that could appear at day boundaries, making overtime processing more reliable for employees with cross-day shifts.
Original PR description
**Problem:** When an attendance has overtimes across multiple days, those overtimes can overlap when calculating their intervals. There will always be rounding errors since only the durations are…
**Problem:** When an attendance has overtimes across multiple days, those overtimes can overlap when calculating their intervals. There will always be rounding errors since only the durations are saved to 3 decimals, but this is normally fine since the durations are accumulated when calculating the next interval. However, on a day boundary in the employee timezone, the end of the interval is forced to the end of day, which incidentally removes the rounding error. This causes the overlap when calculating the next interval since its start will be based on the rounded duration, not the actual end of day. **Steps to Reproduce:** - Configure an overtime rule where >8 hours is considered overtime, and a second rule applies to non-working days - Set Overtime Rule on employee "Anita Oliver" - Set employee work entry source to "Attendances" - Create an attendance that exceeds 8 hours in a day and crosses into a non-working day and creates enough of a rounding error (see unit test) -> Traceback error: `ValueError: Expected singleton: hr.attendance.overtime.line(1, 2)` **Solution:** Add an additional check to ensure the overtime cannot start on the previous day. opw-6067969 Forward-Port-Of: odoo/enterprise#119672 Forward-Port-Of: odoo/enterprise#118570
This change prevents the Czech localization from taking over records it should not manage when the chart of accounts is reloaded. It helps keep existing accounting data stable during updates and avoids unintended changes during maintenance.
Original PR description
It is the burden of the CoA framework to check for that. See community commit for more information. Forward-Port-Of: odoo/enterprise#121783 Forward-Port-Of: odoo/enterprise#121643
The salary configurator no longer crashes when the company car option is enabled without a car model selected. This makes the Belgian contract salary setup work correctly even when no demo data is installed.
Original PR description
## Steps to Reproduce: 1. Install `l10n_be_hr_contract_salary` without demo data. 2. Create a Belgian company and switch to it. 3. Create an employee. 4. Create a contract for the employee. 5. Click Generate Offer and open the Salary Configurator. 6. Enable the 'Company Car (To order)' option. ## Error: `AttributeError: 'NoneType' object has no attribute 'split'` ## Cause: When the salary configurator is used without demo data, no car model is selected. The method assumes that select_wishlist_car_total_depreciated_cost always contains a value and directly calls split() on it, resulting in an error, when the field is None. ## Fix: This commit checks that both the company car option is enabled and a car model has been selected before trying to extract the model ID. sentry-7554712017 Forward-Port-Of: odoo/enterprise#121650 Forward-Port-Of: odoo/enterprise#121138
This change makes the POS tour wait until the order status update is fully processed before moving on. It also switches the screen to the Paid filter so the order is found in the correct list, preventing intermittent test failures.
Original PR description
The tour `test_product_level_discount` was failing intermittently because the order status update request was not fully processed before the nextstep executed. As a result, the tour searched for the order in the wrong ticket list. This commit adds a proper wait for the backend request after updating the order status and applies the Paid filter on the ticket screen to ensure the tour searches in the correct order list. Runbot Error: [241140](https://runbot.odoo.com/odoo/runbot.build.error/241140) Forward-Port-Of: odoo/enterprise#109371
This change prevents the system from creating duplicate draft transactions when the import cron runs. It restores the previous behavior for repeated files so businesses avoid seeing the same draft move created more than once.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/a0c9e9b5c0ed8135d77c343c819c1fa918356794 users are experiencing some duplicate draft move when the cron is running. It's because we don't skip the files when it already exist, we now add a number of imported count. This commit will revert this change to avoid the problem, and we will contact codabox to find a better way to deal with files imported the same month. task-6299508 Forward-Port-Of: odoo/enterprise#121472
The Spanish Mod 349 report was incorrectly dropping invoices that had been paid during the reporting period. This fix ensures only the intended credit note adjustments are excluded, so the report now stays accurate for businesses with paid invoices.
Original PR description
The mod349 report engine has been refactored to use tax tags (commit : 5f36778288a1b60245acec74677421666448351f). To avoid redundancies, the query used to get the invoice lines to include is designed to remove the amounts that have been reconciled with a credit note during the selected period. However, the current query removes the lines from any invoice that is reconciled with a move created in the period. As a result, invoices that have been paid in the period are also removed from the report. opw-6250491 Forward-Port-Of: odoo/enterprise#119551
A formatting issue prevented Mexico’s SW cancellation requests from sending the certificate in the expected encoded form. This fix restores the correct certificate format so cancellations can be processed reliably again.
Original PR description
Issue: https://drive.google.com/file/d/1-57iHrMoBo79EbUaWuwkJut_7FfyzeLY/view
`_sw_cancel` sent `pem_certificate.decode('UTF-8')` as `b64Cer`, which used to work because `fields.Binary` returned base64-encoded bytes. Since binary fields now return a `BinaryValue`, `.decode()` returns the raw PEM content instead of base64, breaking the SW cancel API call.
Use `.to_base64() " to properly base64-encode the certificate, matching the pattern already used for `b64Key " and in `_sw_sign ".
related change for binary fields: [41fe2eb](https://github.com/odoo/odoo/commit/41fe2ebdb9cc)
task-6319057
Forward-Port-Of: odoo/enterprise#121579This update corrects how Philippine tax reports identify invoice lines when taxes are grouped. It ensures lines are included under the right tax tag even when the relevant tag belongs to a child tax inside a group, so reports are more accurate and complete.
Original PR description
When using group taxes, the base invoice lines only store the parent tax in the `account_move_line_account_tax_rel` table. Because of this, if a child tax within the group contains a specific tax report tag, the generic report query would previously fail to pick up those base lines. This commit updates the SQL join conditions in `l10n_ph_generic_report.py` to also match `account_tax.id` against the child taxes of the linked parent tax using the `account_tax_filiation_rel` table. This ensures that base lines are correctly reported under the tags of their respective child taxes. Task-6278098 Forward-Port-Of: odoo/enterprise#121876 Forward-Port-Of: odoo/enterprise#121596
Currently, the sia_code field on res.company lacks length validation. For Italian Ri.Ba (CBI) exports, this field MUST be exactly 5 characters. If a user enters more (e.g., during initial setup), the Batch Payment validation (specifically the XML file generation) crashes with a traceback. Steps to Reproduce: - Set Company SIA Code to 6+ characters - Create multiple payments with Ri.Ba. method - Create a Ri.Ba Batch Payment - Click 'Validate' Ticket [link](https://www.odoo.com/odoo/proj
Original PR description
Currently, the sia_code field on res.company lacks length validation. For Italian Ri.Ba (CBI) exports, this field MUST be exactly 5 characters. If a user enters more (e.g., during initial setup), the Batch Payment validation (specifically the XML file generation) crashes with a traceback. Steps to Reproduce: - Set Company SIA Code to 6+ characters - Create multiple payments with Ri.Ba. method - Create a Ri.Ba Batch Payment - Click 'Validate' Ticket [link](https://www.odoo.com/odoo/project.task/6031062) opw-6031062 Forward-Port-Of: odoo/enterprise#121610
The aim of this commit is to allow the databases_user to synchronize their databases. Context: The commit https://github.com/odoo/odoo/commit/846eb51a02baaf2e4f6e6780f8d0ceb23322c38b introduced a change of behavior in stable that performs some more check on access rights. Before this commit: The checks introduced by the commit resulted in an access error. There wasn't any groups on the action itself resulting in a check of the access right "write" on the model. As the model is `project.
Original PR description
The aim of this commit is to allow the databases_user to synchronize their databases. Context: The commit https://github.com/odoo/odoo/commit/846eb51a02baaf2e4f6e6780f8d0ceb23322c38b introduced a change of behavior in stable that performs some more check on access rights. Before this commit: The checks introduced by the commit resulted in an access error. There wasn't any groups on the action itself resulting in a check of the access right "write" on the model. As the model is `project.project` and a databases_user might not be granted write access on the project itself, it resulted in an access error. After this commit: The flow continues smoothly. As the action has now a group set on it, this is checked first and match the proper access right. opw-6329058 Forward-Port-Of: odoo/enterprise#121589
Selecting a second model through the Action option's "More models" crashed because the current form model was dropped from the models cache while the new model was being applied. This commit keeps both the current form model and the model being applied in the cache. Steps to reproduce: - Add a form snippet - Click on the form - In the `Action` option, select `More models` - Select one model - Open `More models` again and select another model - Traceback appears: `TypeError: Cannot re
Original PR description
Selecting a second model through the Action option's "More models" crashed because the current form model was dropped from the models cache while the new model was being applied. This commit keeps both the current form model and the model being applied in the cache. Steps to reproduce: - Add a form snippet - Click on the form - In the `Action` option, select `More models` - Select one model - Open `More models` again and select another model - Traceback appears: `TypeError: Cannot read properties of undefined (reading 'website_form_key')` task-6321878 Forward-Port-Of: odoo/enterprise#121492