Friday, December 12, 2025
34 changes · 19.0
Enhancements to existing features
Website test setup now reuses already-processed snippet data instead of repeating the same image-cleaning step. This reduces unnecessary work during automated tests, helping the website test suite run faster without changing customer-facing behavior.
Original PR description
__Behavior before commit:__ `getWebsiteSnippets` is called *at least* twice per website Hoot test. - [When opening the sidebar][1] - [When `render_public_asset` is called][2] Although the orm result is cached using `websiteSnippetsPromise`, it still calls `removeImageSrc` everytime. But inside `removeImageSrc`, this line takes around 50 ms to execute: ```js new DOMParser().parseFromString(xmlString, "text/html") ``` Therefore wasting at least 100 ms per test. __Fix:__ Make the promise encompass the result of `removeImageSrc` so that it is called only once at the beginning of the test suite. [1]: https://github.com/odoo/odoo/blob/2dc9529af127ed4b2d451059b6ab9c83778c7814/addons/website/static/tests/builder/website_helpers.js#L281 [2]: https://github.com/odoo/odoo/blob/2dc9529af127ed4b2d451059b6ab9c83778c7814/addons/website/static/tests/builder/website_helpers.js#L51 task-5269391 Forward-Port-Of: odoo/odoo#239591
Resolved issues and error corrections
This fix makes Odoo's web test tools handle browser-managed internal links, such as blob and data URLs, without extra setup. It reduces false test failures and improves confidence in web-related changes without affecting day-to-day user workflows.
Original PR description
Before this commit, internal URLs (i.e. "blob:" and "data:") required 'fetch' to be mocked to work. This is wierd because these requests are handled directly by the browser and shouldn't require any…
Before this commit, internal URLs (i.e. "blob:" and "data:") required
'fetch' to be mocked to work. This is wierd because these requests are
handled directly by the browser and shouldn't require any particular
manipulation from the (mocked) server.
This commit ensures that internal URLs still work without fetch being
mocked.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239443
Forward-Port-Of: odoo/odoo#239011Fixes an issue where editing a combo product after its name was removed could trigger an error in sales orders. The edit option is now only shown when the required product information is available, helping users avoid a broken configuration flow.
Original PR description
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management`…
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management` with demo and create a new SO. - Add a combo product and remove the combo name and click Edit Configuration (pencil icon). Error: `TypeError: SaleProductConfiguratorController.sale_combo_configurator_get_data() missing 1 required positional argument: 'product_template_id'` Cause: - When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_combo_configurator_get_data()` which expects `product_template_id` at [1] and since it is removed from order line the error is encountered. Solution: - Changed the content of method `isCombo()` to use the product_template_id to make sure the Edit Configuration is only visible when product template is present. Similar PR for reference: https://github.com/odoo/odoo/pull/217464 [1]: https://github.com/odoo/odoo/blob/fa4307b9758800f26c9ee87cf3698fd60bfd1ab5/addons/sale/controllers/combo_configurator.py#L12-L14 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238536
The product snippet preview now displays correctly again in the website editor. The fix limits a visibility rule to product pages only, preventing it from unintentionally hiding the snippet preview elsewhere.
Original PR description
This PR fixes an issue introduced in Commit[^1] while trying to fix an issue with the alternative products section being displayed even with no alternative products. In Commit[^1], the rule was set in the snippet file, which worked but was affecting all the places where this snippet is displayed, which made the snippet preview empty. To ensure this does not happen, we scope the rule to the product page only, ensuring the snippet remains untouched. [^1]: https://github.com/odoo/odoo/commit/0dfc5a6cfbae808f2dc5c7042bc07180eaa49e9a task-5404601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239238
The media dialog now clears the video selection when a user removes the video URL, preventing broken embedded videos from being saved. This avoids 404 errors and makes the website editing experience more reliable.
Original PR description
*=website **Steps to reproduce:** 1. Drop a video 2. Reopen the media dialog 3. Remove the URL 4. Confirm **Issue:** When the URL was removed and confirmed, an iframe without a valid source was saved, leading to a 404 error. **Fix:** When the video URL is cleared, VideoSelector component calls selectMedia with an empty object. MediaDialog did not previously handle this case, so the media selection was not cleared. Now we Update MediaDialog to treat an empty object as a clear-selection signal and disable the Add button accordingly. task-5190485 Forward-Port-Of: odoo/odoo#239068 Forward-Port-Of: odoo/odoo#234085
This update corrects how list indentation is calculated in the HTML editor when lists have many items. It helps keep numbered or bulleted lists aligned properly, improving document readability for users editing content.
Original PR description
Since commit [1], the padding inline start value is wrong whenever the number of items in the list is greater than the largest marker width in the list. This is because calling `.reduce(Math.max)` on the list of widths means `Math.max` receives one plus the index of the item as third argument instead of just the widths it means to compare. As an interesting side note, this would have returned `NaN` if `reduce` had been called on an actual array rather than an iterator, because then `Math.max` would have received the array itself as fourth argument. Here, there is no array so there is no fourth argument, and `Math.max` receives only numbers as it expects, and returns a wrong value. [1]: https://github.com/odoo/odoo/commit/9b0c411f94ed1e090d4adbaf785cd852bbe5469e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal logging issue that could break error reporting when log messages used named values. It helps ensure diagnostic logs are formatted correctly, making production issues easier to investigate without changing user-facing behavior.
Original PR description
When `lower_logging` encounters a `LogRecord.args: Mapping`, it fucks up and strips out all the values keeping only the mapping keys (as a tuple), which then breaks when trying to format it in `LogRecord.msg`. Fix the issue by moving the entire message munging into, appropriately, the formatter: `getMessage` will do the `str.__mod__` call at which point we don't need to deal with the args at all, then `formatMessage` generates the full message line (not including the stack traces from `exc_info` and `stack_info`, those are added in the second half of `Formatter.format`). https://runbot.odoo.com/odoo/error/234669 Forward-Port-Of: odoo/odoo#239560 Forward-Port-Of: odoo/odoo#239410
Sale Order PDFs using the DIN 5008 layout now avoid showing the same customer address twice when customer address display is disabled. This keeps printed quotations and orders cleaner and prevents confusion for customers receiving these documents.
Original PR description
## Issue: When DIN5008 is selected as the document layout, printing a Sale Order may show the customer address twice ## Cause: The address is first added by `external_layout_din5008`, then again by `report_saleorder_document` This duplication only makes sense when the partner address differs from the invoice or delivery address If the Customer Addresses setting is disabled, displaying it multiple times is unnecessary ## Steps to reproduce: - Install a company using DIN 5008 (e.g., l10n_de) - Select the DE company and go to Settings - Disable `Customer addresses` and ensure the document layout is set to DIN 5008 - Create a Quotation with any customer and product - Print the PDF → the address appears twice before the fix opw-5176593 Forward-Port-Of: odoo/odoo#235441
This fixes a CRM issue where leads created directly in a won stage could later fail when moved to another won stage. Sales teams can now update these opportunities normally without encountering an error, including cases with expected revenue already set.
Original PR description
Currently, if a lead is created in a won stage and later moved to another won stage, an error can occur. Steps to Reproduce: 1) Install CRM without Demo. 2) Create 3 leads. 3) Navigate to…
Currently, if a lead is created in a won stage and later moved to another won stage, an error can occur. Steps to Reproduce: 1) Install CRM without Demo. 2) Create 3 leads. 3) Navigate to CRM>Configuration>Stages and make **new** and **Qualified** stage to won stage. 4) Now generate a new lead. and then change the system time and increase 1 hour. 5) Now move the lead to the Qualified stage. Error: `TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.datetime'` Root Cause: When a lead is created in a stage marked as won, its `date_closed` will be `False`. Updating that lead to another won stage triggers the condtion at [1] which performs check that performs `self.date_closed - self.create_date`. Because `date_closed` value is `False`, the subtraction raises an error. FIX: This fix makes sure below cases are handled: - Make sure that `date_closed` value exists before comparing it with `create_date` - Make sure that cases at [2] doesn't fails when lead is created in the won stage with some `expected revenue`. [1]- https://github.com/odoo/odoo/blob/fad692777e90f3c91f91d2a91e706f8bdb64a08a/addons/crm/models/crm_lead.py#L1241-L1243 [2]- https://github.com/odoo/odoo/blob/25ec485082545f3bd8a92606b2cf4d9bcaf0185c/addons/crm/models/crm_lead.py#L1228-L1235 Note: This commit handles cases mentioned in [this commit](https://github.com/odoo/odoo/commit/d1b71f9bf04a9e1cc09941c34e444451ebdddb85) sentry-6993496031,7026119584 Note: I tried to add a test case, but was unable to do so since it is a small use case. I feel it will be bit overkill to add a test here. [test branch](https://runbot.odoo.com/runbot/bundle/190-sentry-6993496031-crm-typeerror-test-path-413099)
The Argentine delivery guide report now shows the CAI expiration date in the proper format. This prevents confusing or incorrectly formatted document dates for businesses using Argentine stock documents.
Original PR description
The CAI expiration date is not well formated in the delivery guide report. opw-5004345 Forward-Port-Of: odoo/odoo#239694
Coupon expiration dates now appear in the customer’s own language and regional date format in both the email and its attachment. This avoids confusing technical date formats and makes coupon communications clearer for international customers.
Original PR description
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount…
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount & loyalty 5. Create a record with program type coupons 6. Generate a coupon for that AU contact with an expiration date Issue: The coupon email received by the customer shows the expiration date using the yyyy-MM-dd format, and the attachment shows the same technical format instead of the customer’s localized date format. Cause: We are not using a formatted date according to the customer before: Customer with English AU language <img width="601" height="563" alt="image" src="https://github.com/user-attachments/assets/faea2840-aca6-4850-bfc9-b0d24da65a3b" /> <img width="1510" height="883" alt="image" src="https://github.com/user-attachments/assets/b0ebc0cc-6243-450d-ad12-cecda4858e26" /> After: <img width="603" height="543" alt="image" src="https://github.com/user-attachments/assets/5be2332b-3237-4ce5-8122-0766cd274650" /> <img width="1482" height="886" alt="image" src="https://github.com/user-attachments/assets/99d31b4c-33fa-4f92-9970-56720181911e" /> opw-5247621 Forward-Port-Of: odoo/odoo#237880
This fix prevents an error when a CRM lead with expected revenue is created in a won stage and later moved to another won stage. Sales teams can now update these opportunities without the system failing, improving reliability in CRM workflows.
Original PR description
Currently, if a lead is created in a won stage and later moved to another won stage, an error is occurred. Step to Reproduce: 1) Install CRM without Demo. 2) Navigate to CRM>Configuration>Stages and…
Currently, if a lead is created in a won stage and later moved to another won stage, an error is occurred. Step to Reproduce: 1) Install CRM without Demo. 2) Navigate to CRM>Configuration>Stages and make **new** and **Qualified** stage to won stage. 3) Now generate a new lead with some `Expected Revenue` and move this lead to **Qualified** stage. Error 2: `TypeError: '<' not supported between instances of 'NoneType' and 'float'` Root Cause for Error 2: When a lead is created in a stage marked as won, the value of, `query_result['max_team_31']`, `query_result['max_team_7']`, `query_result['max_user_31']`, `query_result['max_user_7']` are `None`. So when the lead marked as WON moved to another WON stage, conditions at [1] got triggered. and will fail as the values mentioned above are `None` FIX: This fix makes sure that the values exist before comparing them with `expected_revenue` [1]- https://github.com/odoo/odoo/blob/25ec485082545f3bd8a92606b2cf4d9bcaf0185c/addons/crm/models/crm_lead.py#L1228-L1235 sentry-7026119584
POS receipts now avoid repeating the customer name when Indian localization or loyalty features are used. This keeps printed receipts clearer for customers and cashiers because the name already appears in the receipt header.
Original PR description
When printing receipts in POS with Indian localization, the customer's name was displayed twice if the customer was selected. Also, when using the loyalty module, the customer name was shown. As the customer name is already displayed in the receipt header, this commit removes the redundant occurrences to enhance clarity. opw-5386345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users who add an XML encoding declaration in the Studio XML editor will now receive a clear, handled error message instead of a confusing technical crash. This helps administrators understand what needs to be corrected when saving XML views.
Original PR description
Currently, an error occurs when a user includes an XML encoding declaration in the studio XML editor. **Steps to produce:** - Install the `web_studio` module and enable `developer mode` - Open `Apps`…
Currently, an error occurs when a user includes an XML encoding declaration in the studio XML editor. **Steps to produce:** - Install the `web_studio` module and enable `developer mode` - Open `Apps` > `studio` > `view` > `</> xml` - Declare encoding as: `<?xml version='1.0' encoding='utf-8'?>` and click `save` **Error:** `ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.` **Root cause:** At [1], an error is raised when the XML declaration contains an `encoding` attribute, as encoding declarations are invalid in Unicode strings. **Fix:** This commit ensures that a `UserError` is raised, improving the error message clarity. A similar fix was applied in https://github.com/odoo/odoo/pull/205324. [1]: https://github.com/odoo/odoo/blob/8a22b6ca09e1da3ccba3540bc4851a5174e035cc/odoo/tools/translate.py#L316 sentry-6981234548 Forward-Port-Of: odoo/odoo#239743 Forward-Port-Of: odoo/odoo#233571
Cashiers now see a notification if they try to close a POS session without being the selected logged-in employee. This helps avoid confusion and makes it clearer why access to the backend is blocked.
Original PR description
After this commit, when attempting to close a POS session, if the logged-in employee is not selected, a notification will inform the user. This prevents confusion. opw-5244818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234741
Portal users could encounter an error when changing the department filter on website job pages. This fix ensures department information is accessed safely so candidates can browse filtered job listings without interruptions.
Original PR description
**Steps to reproduce:** 1. Install `website_hr_recruitment` 2. Open the job website page and, through editor add a filter for department 3. Switch to a portal user and change the department filter **Issue:** - The controller passes department_id to the template, but unlike before this commit https://github.com/odoo/odoo/commit/0ab6e84c54f134c8744d8f94108a715e989b2815, where the code used sudo() to sort departents https://github.com/odoo/odoo/blob/6159c6527cfa38ea0c92e6f3fa6025ee534a1acb/addons/website_hr_recruitment/controllers/main.py#L81 it now just passes the department_id without actually returning a full record with accessible fields. In the template, the filter rendering uses selected_filter.name, which triggers an AccessError for portal users. **Solution:** - Apply `sudo()` when accessing `hr.department` to avoid access errors for portal users. opw-5103910 Forward-Port-Of: odoo/odoo#229040
This fixes stock valuation reporting so it keeps the full date and time instead of only the date. It helps ensure valuation data remains precise, avoiding potential ordering or cutoff mistakes in inventory accounting views.
Original PR description
Before #239595, dateAsString was a stringified version of a datetime. However the fix mistakenly used `serializeDate()` instead of `serializeDateTime()`, losing precision. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal JavaScript processing issue that could shift debugger line numbers when certain imports followed blank lines. Developers get more reliable debugging information, reducing time spent tracing issues in browser tools.
Original PR description
Steps to reproduce
==================
- Create a js file with a blank line followed by an unnamed import
```js
import { mailModels } from "@mail/../tests/mail_test_helpers";
import "@account_accountant/components/bank_reconciliation/list_view/list_view_many2one_multi_edit";
import "@account_accountant/components/bank_reconciliation/list_view/list";
debugger;
```
- Open the devtools
=> The debugger will be off by one line
Cause of the issue
==================
When remplacing unnamed imports by a require statement, the leading whitespace was not preserved.
Solution
========
We add back the captured space. This is done for every other replacement.
Forward-Port-Of: odoo/odoo#239531This update fixes an issue where subscription details weren't being displayed correctly within the project dashboard. The fix addresses a problem with how subscription data was being filtered and retrieved, ensuring subscription titles are now shown accurately when the subscription section is expanded. This improves the user experience for managing subscriptions.
Original PR description
Before this commit, when subscriptions were linked to the analytic account of a project, the sale order items appears in an unwanted section when the section is unfolded. Meanwhile, when the subscription section is unfolded the title of the subscriptions items are not correctly displayed. The first issue is due to the fact that we did not correctly exclude the subscriptions items from the domain. The second issue is due to the fact that we fetch the field 'name' from the subscription search instead of the field 'display_name' task-5159781 Forward-Port-Of: odoo/enterprise#97238
This update resolves a problem where tests were failing after a recent change that limited the use of 'mock' helpers. The fix ensures tests continue to run correctly, maintaining the stability of the Odoo Enterprise system. This change primarily impacts internal testing processes.
Original PR description
This commit adapts tests failing due to a recent fix preventing the use of 'mock...' helpers outside of tests. - Community: https://github.com/odoo/odoo/pull/239237 Forward-Port-Of: odoo/enterprise#101802 Forward-Port-Of: odoo/enterprise#101780
This update resolves an issue where users with access to multiple companies but only one employee were unable to schedule themselves for planning slots in those companies. The fix restores the previous behavior, ensuring all authorized users can participate in planning across their companies. This corrects a database inconsistency and improves usability.
Original PR description
Since #91616, if a user has access to multiple companies but only has an employee in one, they are unable to assign themselves to a planning slot from a company other than that of their employee. This was not the case in previous versions and is causing issues in our internal db. To restore the previous behavior, any user with access to a company but only 1 employee will be able to assign themselves to slots of said company. opw-5163200 Forward-Port-Of: odoo/enterprise#101659
This update fixes an issue where multiple quality checks were being created for the same picking when adding additional products. The change adds a validation step to ensure only one operation-based quality check is generated per picking, streamlining the quality control process and preventing redundant checks.
Original PR description
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations…
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations field). 3. Create a Receipt containing one product. 4. Click the Mark as To Do button. 5. Add another product to the same Receipt and save it. Observation: -------------------------- Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation. Issue: -------------------------- No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation. Solution: -------------------------- Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created. opw-5249233 Forward-Port-Of: odoo/enterprise#101788 Forward-Port-Of: odoo/enterprise#100118
This update fixes an issue where helpdesk return pickings incorrectly defaulted to a generic incoming operation type. The change ensures that returns are now automatically created using the specifically configured 'Delivery Orders' operation type, streamlining the return process and improving accuracy.
Original PR description
Steps to reproduce: - 1. Go to Inventory > Configuration > Operation Types. 2. Open the 'Delivery Orders' operation type. 3. In the 'Returns Type' field, select a specific 'Returns' operation and save. 4. Go to the Helpdesk app and create a new ticket. 5. Click the 'Return' button to create a return picking. Issue: - The 'Operation Type' on the newly created return defaults to the first available 'incoming' operation. It incorrectly ignores the specific 'Returns Type' that was configured on the 'Delivery Orders' operation type. Cause: - The _prepare_picking_default_values method on the stock.return.picking wizard contained logic to search for the first operation type with code='incoming'. Fix: - The logic now finds the 'outgoing' (Delivery) operation type and uses its configured 'Returns Type' as the default for the new return. task-5074911
This update fixes a bug where the 'Other Expenses' account type wasn't displayed in the Balance Sheet report. The change was made to align the report with a recent addition to the system for vendor bill tracking. This ensures all financial data is accurately reflected in the Balance Sheet.
Original PR description
In saas-18.3 a new account type was added: "Other Expenses" These accounts are excluded from the account many2one field to make it easier to find relevant expense accounts for vendor bills. Issue: This account type is not included in the Balance Sheet report. see comment in opw-5269456 related to opw-5191111 Forward-Port-Of: odoo/enterprise#101591
This update allows the 'Emissions stat' button to be displayed on a wider range of account moves, including Purchase Receipts, previously it was limited to specific invoice types. This expands the data available for ESG reporting and provides a more complete picture of emissions across the business.
Original PR description
Prior to this PR, we limited the display of the Emissions stat button of 'account.move' to Vendor Bills and Credit Vendor Bills ('in_invoice' and 'in_refund'). But emissions could be reported in other types of moves (e.g. Purchase Receipt), so we remove that condition.
task-5407761
Forward-Port-Of: odoo/enterprise#101906This update resolves a technical issue that prevented users from correctly setting accounting periods when configuring their tax returns journal. The fix ensures that a necessary installation step is triggered, preventing a traceback error and allowing users to complete this important setup process. This improves the stability and usability of the accountant module.
Original PR description
From **saas-18.3**, when installing the accountant module, after [this PR](https://github.com/odoo/enterprise/commit/49aca723c2422fedcc8bda963a6346a172825617#diff-c703c688dc3f80644a43c96657cb2db0122b83cee9bcfa417554b0c7f1e4f550L22) the `_initiate_account_onboardings()` was not called anymore for companies that already had a chart template. This caused a traceback while configuring the Accounting Period on the Tax Returns journal: `ValueError - Expected singleton: onboarding.progress()` We now fix this behavior by ensuring that `_initiate_account_onboardings()` is called when installing the chart_template, filling the gap that was introduced. **Steps to Reproduce:** 1. Install `accountant` module without demo data. 2. Accounting > Dashboard > _Tax Returns_ Journal, click on the **"Tax Returns"** button. 3. Set an **Opening Date** in the wizard and try to apply the **Accounting Periods**. sentry-7064593163 Forward-Port-Of: odoo/enterprise#101442
This update resolves a translation issue within the l10n_be_reports module. The system incorrectly attempted to use VAT communication logic for a company using the LU localization, resulting in a ValueError. The fix ensures the correct chart template is used during translation loading, preventing this error.
Original PR description
``` File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook self.env.registry._delayed_account_translator(self.env) File…
```
File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook
self.env.registry._delayed_account_translator(self.env)
File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 90, in load_account_translations
env['account.chart.template']._load_translations(langs=langs)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 1449, in _load_translations
._get_chart_template_data(chart_template)
File "/home/odoo/src/enterprise/19.0/account_accountant/models/account_chart_template.py", line 31, in _get_chart_template_data
data = super()._get_chart_template_data(chart_template)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 803, in _get_chart_template_data
data = func(self, template_code)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 59, in wrapper
return func(*args, **kwargs)
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py", line 52, in _get_be_account_reconcile_model
prepayment_communication = self.env['qr.code.payment.wizard']._be_company_vat_communication(self.env.company).replace('+++', '')
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/qr_code_payment_wizard.py", line 14, in _be_company_vat_communication
number = int(vat)
ValueError: invalid literal for int() with base 10: 'LU19038918'
```
```sql
kmod_3311837=> select id,name,chart_template,parent_id from res_company;
id | name | chart_template | parent_id
----+---------------------+----------------+-----------
3 | C.R.O.Qu.E.T. S.A. | be_comp |
2 | KG5380 | be_comp |
1 | KNOWLEDGE GATE S.A. | lu |
(3 rows)
kmod_3311837=> select id,model,module,res_id from ir_model_data where name = 'main_company';
id | model | module | res_id
----+-------------+--------+--------
2 | res.company | base | 1
(1 row)
```
```
> /home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py(52)_get_be_account_reconcile_model()
-> if template_code in ['be', 'be_comp', 'be_asso']:
(Pdb) template_code
'be_comp'
(Pdb) self.env.company
res.company(1,)
(Pdb) self.env.company.chart_template
'lu'
(Pdb)
```
- The traceback occurs because during the translation loading process, the system calls [_get_chart_template_data](https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/account/models/chart_template.py#L1465)
for all available template codes. In the customer’s database, there are three companies: Company 2 and Company 3 use the BE_COMP localization, while Company 1 uses the LU localization.
- When _get_chart_template_data is executed for the BE_COMP chart template, it eventually calls [_get_be_account_reconcile_mode](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/account_chart_template.py#L49) During this call, the function receives the correct template code (be_comp) as an argument. However, self.env.company returns Company 1, because Company 1 is set as the main_company.
- As a result, [_be_company_vat_communication](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/qr_code_payment_wizard.py#L14) is called with Company 1, even though this company uses the LU localization. Since LU localization does not support the BE VAT communication logic, an error is raised from this method.
- I have made a fix that uses the chart_template of self.env.company to avoid the blocking issue during the upgrade. However, I am not fully sure whether this is the correct solution. Since the load_translation method does not pass with_company when retrieving the chart template, this issue will always occur because the methods are executed in the context of the main company instead of the company that the chart template actually belongs to.
opw-5342498This update ensures that a 'partner ID' is always provided when processing SEPA payments. Previously, a missing partner ID could cause errors during batch payment creation, leading to payment processing failures. This change improves the reliability and stability of our payment processing system.
Original PR description
When doing a payment with SEPA as the payment method, and then create a batch payment out of it. It could happen that the partner_id of the payment was not set. That would cause a traceback because in the _get_CdtTrfTxInf we do a browse on the partner to use it later on. But since the partner is False, we have an empty record set. task-5213880 Forward-Port-Of: odoo/enterprise#98249
This update fixes a technical error that prevented some users from accessing the employee version history. The payroll module's access restrictions were not correctly applied to the user interface, causing a frontend error. The fix ensures that only authorized users can view this data.
Original PR description
Steps to reproduce: - Log in as a user with only Employee Administrator rights (no payroll access). - Open the Employees app and create a new employee. - Click the History smart button. - A traceback is raised. Cause: The payroll module restricts contract_date_start and contract_date_end to hr_payroll.group_hr_payroll_user, but the search view still referenced these fields. Since the view was not updated accordingly, non-payroll users triggered a frontend parsing error. Fix: Override the search view to update the filters and match the model's access restrictions. task-5401143 Forward-Port-Of: odoo/enterprise#101710
This update resolves a limitation preventing non-administrator users from utilizing the delivery_usps_rest module. By implementing sudo() calls, the module now grants necessary access to the USPS Rest API, expanding functionality without requiring elevated user permissions. This improves usability for a wider range of users.
Original PR description
Non-admin users are currently unable to use the delivery_usps_rest module because several fields are limited to the "base.group_system" group. It's obviously not feasible to give everyone the "Role / Administrator" role. This PR makes necessary sudo() calls the same way that delivery_ups_rest does. Forward-Port-Of: odoo/enterprise#101163
This update resolves a test failure related to user switching in the MRP work order module. The fix ensures the test waits for shop floor records to fully load after a user change, preventing false negatives. This improves the reliability of the test suite.
Original PR description
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:…
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps: https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed. #### Fix: Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks. #### runbot-226734 Forward-Port-Of: odoo/enterprise#101268 Forward-Port-Of: odoo/enterprise#100746
This update resolves an issue where long text inputs within the Odoo Web Studio editor would overflow, causing display problems. Now, long text is automatically truncated, ensuring a clean and usable interface for users creating and editing web pages.
Original PR description
**Before this commit:** Long input text overflowed and was not truncated. **After this commit:** Long input text is now properly truncated, preventing overflow. task-5240113 Forward-Port-Of: odoo/enterprise#99535
This update resolves an issue where Arabic date formats were causing errors when generating accounting reports. The fix ensures consistent date handling across different server environments, preventing report generation failures. This improves the reliability of financial reporting for all users.
Original PR description
Steps to reproduce: - Complete a purchase - Go to Accounting > Review > Bills to receive - Select the PO and click on `Create Accrual Entries` Issue: A traceback appears, showing an invalid date format. To keep date formats working properly with the server independantly from the locale, we must use `serializeDate` to avoid symbols that wouldn't be understood by the server.
This update addresses a missing dependency for the l10n_be_intervat module, which is essential for its functionality. The change adds a safety mechanism to handle cases where PyJWT isn't installed, logging a helpful message to the user. It also updates import statements for improved code stability.
Original PR description
The l10n_be_intervat module needs `PyJWT`, but it is not listed in external_dependencies. As we cannot change module dependencies in a stable version, this commit adds a try-except block regarding the import. In case the library is not installed, an error is logged to inform the user that they need to install the `PyJWT` module. Additionally, this commit updates the import of ImmatureSignatureError to come from jwt.exceptions instead of jwt. no-task