Daily updates from Odoo
Tuesday, December 16, 2025
133 changes
23 changes
Resolved issues and error corrections
This change prevents unnecessary calculations when retrieving data for inherited fields. By avoiding redundant computations, the system now performs more efficiently, particularly when dealing with complex data relationships. This results in faster response times and a smoother user experience.
Original PR description
when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it…
when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it [here](https://github.com/odoo/odoo/blob/b48d41086d7ff8ef91c6c43d37d588686d6b921a/odoo/orm/fields.py#L923) and field is from inherited model it trying ``model._read_group_groupby(model._table, groupby, query)`` because those related and non store. As there is no meaning for computation for that because it going groupable because it parent_field is groupable. So, keeping check for that and reduce the computation.
```
File "/tmp/tmpmagm1mli/migrations/base/tests/test_mock_crawl.py", line 430, in mock_act_window
views = get_views(
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 463, in get_views
res = super().get_views(views, options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/models.py", line 10, in get_views
result = super().get_views(views, options=options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_ui_view.py", line 52, in get_views
return super().get_views(views, options)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 2935, in get_views
result['models'][model] = {"fields": self.env[model].fields_get(
File "/home/odoo/src/odoo/19.0/addons/stock/models/product.py", line 521, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_model.py", line 76, in fields_get
return super().fields_get(allfields, attributes=attributes)
File "/home/odoo/src/enterprise/19.0/ai_fields/models/models.py", line 47, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3360, in fields_get
description = field.get_description(self.env, attributes=attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 883, in get_description
value = value(env)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 930, in _description_groupable
model._read_group_groupby(model._table, groupby, query)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_activity_mixin.py", line 259, in _read_group_groupby
return super()._read_group_groupby(alias, groupby_spec, query)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 2064, in _read_group_groupby
coquery = comodel._search(codomain, bypass_access=field.bypass_search_access)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_attachment.py", line 659, in _search
records = self.sudo().with_context(active_test=False).search_fetch(
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1418, in search_fetch
return self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3914, in _fetch_query
rows = self.env.execute_query(query.select(*sql_terms))
File "/home/odoo/src/odoo/19.0/odoo/orm/environments.py", line 534, in execute_query
self.cr.execute(query)
File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 426, in execute
self._obj.execute(query, params)
psycopg2.DatabaseError: out of memory for query result
```
opw-5260147
upg-3444635
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239991
Forward-Port-Of: odoo/odoo#239400This update resolves an issue where loading demo data in a newly created company within the Appraisal module would trigger a permission error. The fix ensures demo employee data is created within the user's current company, eliminating the conflict with company-specific security rules. This allows users to easily load and test demo data in new business environments.
Original PR description
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module. **Steps to Reproduce:** 1. Install `hr_appraisal` without demo data. 2. Create a…
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module.
**Steps to Reproduce:**
1. Install `hr_appraisal` without demo data.
2. Create a new company and switch to it.
3. Appraisals > Click "Load sample data".
**Traceback:**
```
AccessError
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Sengsourigna Phonkaseumsouk (id=2) doesn't have 'read' access to:
- Employee, Emma Granger (hr.employee: 3, company=TPX Solutions)
Blame the following rules:
- Employee multi-company rule
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue; you might be able to access the record by switching to the company: TPX Solutions.
ParseError
while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside <function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref('hr_appraisal.hr_appraisal_2')]"/>
ValueError
ParseError('while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside\n<function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref(\'hr_appraisal.hr_appraisal_2\')]"/>') while evaluating 'action = model._load_demo_data()'
```
**Cause:**
The demo data loading process attempts to access employee records without the required permissions. Since the user belongs to a different company, the multi-company security rules prevent reading those employees.
**Fix:**
This commit removes the company assignment from the demo employee records so they are created in the current company instead of the base company.
sentry-7032880299
Forward-Port-Of: odoo/odoo#239415This fix resolves an issue where the system incorrectly used the main company during translation loading, leading to a ValueError when attempting to process VAT communication for the BE_COMP localization. The update corrects the context to ensure the translation loading process uses the appropriate company data, resolving the error and enabling correct translation functionality.
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.
- There is no context of the company passed when calling _get_chart_template_data from _load_translations, so I have applied with_company, so _get_chart_template_data is called in the context of a specific company.
opw-5342498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239887
Forward-Port-Of: odoo/odoo#239809This update addresses an issue where runbot reports were incomplete due to changes in how errors were handled during testing. The team is restoring logging to provide more detailed error information, improving the accuracy of runbot reports and streamlining debugging. This ensures more reliable automated testing.
Original PR description
One of the changes in #118332 was to let exceptions bubble up to the interpreter in case of error, to improve the experience while running the script locally. This turns out to have downgraded runbot reporting significantly as it doesn't account for stderr / log tracebacks if it got error-level (and possibly even warning-level) logs during the run. Hopefully get the best of both world (and shorten tracebacks slightly) by restoring `logging.exception` at the script level but triggering an abnormal exit for local CLI utility. Forward-Port-Of: odoo/odoo#239995
This update resolves a critical bug in the Odoo Report Editor where Google Translate was causing incorrect data saving and crashes. By disabling translation specifically within the report's iframe, the issue is now fixed, ensuring reports are saved accurately.
Original PR description
Before this commit, when google translate was active on the current ReportEditor, it produced wrong data to save, and ultimately crashes. After this commit, since we disable the translation on the whole HTML element inside the iframe (that is only for the edited report), there is no error any more opw-5122924 Forward-Port-Of: odoo/enterprise#97019
This update resolves an issue where review messages were incorrectly displayed for administrators. The fix ensures that administrators always edit their own review messages when using the 'Edit Review' button. This improves the user experience for administrators managing course reviews.
Original PR description
How to reproduce: - Log as Mitchell Admin - Edit Marc Demo review using the contextual edit button - Click on save to update the review - Click on the button "Edit Review" on the top The review modals opens with the message of Marc Demo instead of the message of Mitchell Admin. The fix ensures you always edit your review message when clicking on "Edit review" button. Note: this is only possible with admin user as other users cannot edit messages of other users. So unfortunately, we had to create a new tours as we can't add steps to test_course_reviews_elearning_officer (not running as admin). An alternative would have been to extend test_fullscreen_slide_text_highlights and rename it. Task-5170310 Forward-Port-Of: odoo/odoo#239554 Forward-Port-Of: odoo/odoo#232696
A minor bug causing test failures in the HTML editor has been resolved. The update refined a test selector to avoid unintended targeting of elements within the toolbar, ensuring consistent test results. This improves the reliability of the HTML editor functionality.
Original PR description
Because of the toolbar being sometimes opened, the test added in odoo#238735 would sometimes failed. This was due to the selector "span" also targetting the elements in the toolbar. To prevent this test from failing, the selector "span" was updated to be more specific. Forward-Port-Of: odoo/odoo#239174
This update fixes an issue where the XML reports were incorrectly including a slash ('/') when there was no comment in the comment section. This change ensures the reports are formatted correctly and consistently, preventing potential data discrepancies. The fix was implemented to align with the standard report structure.
Original PR description
Since 17.0, we added a / when there was no comment in the comment section of the xml. This is wrong and should be left empty. opw-5242381 Forward-Port-Of: odoo/enterprise#101339 Forward-Port-Of: odoo/enterprise#100033
This update ensures that group hierarchies displayed in user interfaces are always shown in the user's preferred language, regardless of language changes or new user creation. By making the cache language-dependent and removing unnecessary data, users will consistently see translated group names and field values, improving the overall user experience.
Original PR description
## Before this commit: When opening the user's form view, the group hierarchy is loaded using the context's language, and cached. However, switching language or creating a new user (which copies the portal template user) could result in the group hierarchy being displayed in the wrong language. This occurs because the cache does not account for the language changes. ## After this commit: Make the cache language-dependent to ensure group names and translated fields are always displayed in the user's current language. Also remove the unnecessary copy of the `view_group_hierarchy` field. Forward-Port-Of: odoo/odoo#236767
This update resolves an issue where work orders were occasionally in the wrong state due to how their status was being checked. By adjusting the timing of state evaluations, we ensure work orders are consistently and accurately updated, preventing potential disruptions in production tracking. This improves the reliability of our manufacturing processes.
Original PR description
Previous fix was not sufficient (https://github.com/odoo/odoo/pull/238832) In some cases, evaluating state and reservation_state within _post_inventory's override in mrp_account leads to incorrect workorders state. By evaluating them at end of button_mark_done, the workorders states are correct. task: 5247116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239941 Forward-Port-Of: odoo/odoo#239839
This update fixes an error that prevented HR Officers from generating offer documents. A recent change in the HR module's access controls restricted access to key contract data. The fix uses a temporary bypass to grant access, ensuring Officers can continue to fulfill their role in the application process.
Original PR description
Steps to reproduce: ------------------------- 1. Install Salary Configurator module. 2. Create a new user and assign Officer rights in Employees and Recruitment. 3. Login with that user. 4. Create a new application and move it to 'Contract proposal' stage. 5. Click on the 'Generate Offer' button. Observation: ------------------------- An Access Error occurs, denying Read access to the `final_yearly_costs` field. Issue: ------------------------- In earlier versions, users had an additional access right that allowed them to access contract fields. After the HR modules were refactored, only HR Administrators and Payroll Users retained access to those fields. As a result users with only Officer rights in HR encountered an access error when generating an offer. Solution: ------------------------- Use `sudo()` to bypass access restrictions for the `final_yearly_costs` field when generating the offer. opw-5243280
This update fixes a misleading warning message displayed to users when viewing subscription products without a defined plan. The change ensures users receive a clear and accurate message – 'This product has no valid combination' – preventing confusion and improving the eCommerce experience. This resolves a usability issue impacting all subscription products.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Install website_sale_subscription - Create a subscription product without a plan - Open product on eCommerce Issue: - When viewing a subscription product without a subscription plan in the eCommerce shop, the system incorrectly shows the warning "This subscription is not compatible with the one already in your cart. Please order them separately or empty your cart." - This happens even if the cart is completely empty. - The method _is_add_to_cart_possible doesn’t find any valid combination to add to the cart, and because the product is marked as recurring, it always triggers the wrong message. Solution: - Add a condition to check if current product have any recurring price set if not then it will show the correct warning that 'This product has no valid combination.' Impact: - Users see clear and correct warnings on products without a subscription plan. task-5255749
This update resolves an issue where invoices with journal items lacking labels would trigger a system error. The fix ensures that all labels are treated as strings, defaulting to an empty string if a label isn't present, preventing the traceback and allowing invoices to be successfully validated. This improves invoice processing reliability.
Original PR description
Creating an invoice containing journal items without a label triggers a traceback because the code unconditionally slices the 'name' field (line.name[:64]) without ensuring it is not False. Since 'name' is not a required field on account.move.line, it must be safely handled.
This commit ensures that the label is always a string by falling back to an empty string when the value is missing.
Steps to reproduce the bug:
- Create a storable product
- Create an invoice:
- Add the product to the invoice
- Set any customer
- Go to the journal items tab
- Remove the label of the journal item corresponding to the product
- Try to validate the invoice
- A traceback is raised
opw-5360602
Forward-Port-Of: odoo/odoo#239664
Forward-Port-Of: odoo/odoo#239188This update fixes an issue where subscription product tooltips and product cards incorrectly displayed pricing information. Now, subscription products show only the recurring price, and regular products show the list price, ensuring accurate product representation for our customers.
Original PR description
Version - 18.0 Steps to Reproduce: Issue 1: Incorrect tooltip text 1. Go to Products → Products in subscription app. 2. Open a product page and select goods product type 3. observe product_tooltip…
Version
- 18.0
Steps to Reproduce:
Issue 1: Incorrect tooltip text
1. Go to Products → Products in subscription app.
2. Open a product page and select goods product type
3. observe product_tooltip show incorrect wording:
* "Based on order" showed end of the period.
* "Based on delivered" showed beginning of the period.
Issue 2: Product card shows both recurring and sales price
1. Go to Products → Products in subscription app.
2. Observe that the product card displays both recurring price and sales price
After this PR:
- Tooltip now correctly states:
* for "based on order" invoice_policy -> beginning of period
* for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.
task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />
Forward-Port-Of: odoo/enterprise#101914
Forward-Port-Of: odoo/enterprise#95010This update resolves an issue where newly duplicated website pages weren't immediately visible in the page list. Users now need to reload the page list after duplicating a page to ensure the new page appears correctly. This improves the user experience and prevents frustration when managing website content.
Original PR description
Steps to reproduce: - Go in website page list - Select a page - Click on actions -> duplicate - Select a name - New page doesn't appear in the list, you need to reload to be able to see it task-5412167 https://github.com/odoo/odoo/issues/225299 Forward-Port-Of: odoo/odoo#240041 Forward-Port-Of: odoo/odoo#239702
This update fixes an issue where public holidays were incorrectly counted as excess days in leave calculations. The code has been updated to calculate leave duration before confirmation, ensuring accurate tracking of time off, especially when public holidays overlap with allocated leave periods. This prevents overreporting of leave balances.
Original PR description
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to…
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to 3rd Jan) - Create a public holiday at the beginning of the second allocation (e.g. on 1st Jan 2026) ### Cause: When we are checking the leave duration after having a public holiday the will return the attendance without the public holidays duration so when subtracting the attendance duration from the leave duration we will have a remaining amout equals to the public holiday duration and it will be considered as excess days. https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L228-L230 https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L246-L254 ### Fix: We compute the leave duration before confirming it instead of computed them after opw-5006119 Forward-Port-Of: odoo/odoo#239971 Forward-Port-Of: odoo/odoo#235575
This update resolves an issue where triple-clicking a checkbox in a checklist would unexpectedly select the entire list item. The fix prevents triple-clicks from triggering this unwanted selection, ensuring a more reliable and intuitive user experience when working with checklists.
Original PR description
**Current behavior before PR:** Currently, triple clicking on a checkbox in a checklist item ends up selecting the list content. This happens because in `selection_plugin` `onTripleClick` handler selects the whole list item. **Desired behavior after PR is merged:** This PR ensures that `onTripleClick` in `selection_plugin` does nothing if tripleclick is triggered when checking a box. task-5361579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238876 Forward-Port-Of: odoo/odoo#237690
This update resolves an issue where users couldn't adjust prices within the Swedish POS system when using the blackbox integration. The change allows price control, aligning with requirements that aren't mandatory for the Swedish blackbox compared to the Belgian one. This ensures accurate pricing for Swedish POS transactions.
Original PR description
Before this commit, user couldn't control the price in the POS if using the swedish blackbox. After this commit, user can control the price. It's not clear why the behavior at integration was set to this but it appears that it's not mandatory for swedish blackbox unlike the belgian one. opw-5253401 Forward-Port-Of: odoo/enterprise#101797 Forward-Port-Of: odoo/enterprise#100984
This update fixes an issue where changes to product quantities in Point of Sale didn't automatically update related items, particularly in combo products. The update now ensures that quantity changes are correctly reflected across all related items, improving accuracy and preventing pricing discrepancies. This enhances the overall reliability of the Point of Sale system.
Original PR description
Before this commit, when changing the quantities of a line, we would not automatically change the quantities of the children lines if any. This is now the case. We also handle the prices in a better way such that changing the quantities of a combo product does not affect the price unit of the lines computed previously. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237277
This update resolves a bug where the chatter feature was incorrectly using both the old and new email addresses of an applicant. The fix ensures that only the updated email address is used when sending emails from the applicant record, improving data accuracy and communication. This prevents confusion and ensures correct recipient addresses.
Original PR description
Steps to reproduce: 1- Create a job position and then create an applicant for the position with an email address. 2- Change email from the applicant form. 3- Use the chatter to send an email. 4- As seen, both old email and new email address are used as recipient addresses which shouldn't be the case. The cause was that it failed to save the new email on the partner_id associated to the hr_applicant. This was fixed by modifying the inverse function to allow the values to be modified even if already existant. task-5269650 Forward-Port-Of: odoo/odoo#239660 Forward-Port-Of: odoo/odoo#236208
This update resolves a bug preventing purchase orders from being found when matching vendor bills created by users associated with companies. The fix normalizes the search criteria to account for the difference between how purchase orders and vendor bills store partner information, ensuring accurate matching and bill visibility.
Original PR description
There are two issues: 1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user…
There are two issues:
1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user with a company
2) When making a bill matching, the vendors bill will not appear.
Steps to reproduce:
-------------------
* Create a company A
* Create a partner A of type individual as a sub-partner to the company A
* Create a purchase order with partner A and confirm it
* Create a vendor bill corresponding to the purchase order
1)
* Click on the purchase matching smart button the vendor bill and try to add to PO
* Search for the purchase order
-> Issue, the purchase order does not appear.
2)
* Go on the purchase order
* Click on Bill matching smart button
-> Issue the vendor bills will not appear
Observation:
-----------
The issue is that purchase Orders store the partner exactly as selected (individual contact), while Vendor Bills are normalized internally to the parent company ("commercial_partner_id'). This creates a mismatch when making the search.
https://github.com/odoo/odoo/blob/9e9e992698946b75212040ca0ff812194200a8bf/addons/account/models/account_move_line.py#L480-L483
1) The domain of the search is
https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/purchase/wizard/bill_to_po_wizard_views.xml#L10-L11
The domain on the search does not take into consideration the missmatch between Vendor Bill and PO.
2) When calling action_bill_matching, the domain is:
https://github.com/odoo/odoo/blob/73590e017e9f2861b0852952e14261e57eb67f70/addons/purchase/models/purchase_order.py#L609-L621
This is a similar issue as 1) and https://github.com/odoo/odoo/commit/c0e86ba6d31708fb16765ba0e0596adc2f29dcd8
Why the fix:
------------
Commercial_partner_id is always set, adding it in the search will allow to normalize the search on the parent_company if there is one.
https://github.com/odoo/odoo/blob/18.0/odoo/addons/base/models/res_partner.py#L450-L455
opw-5067995
Forward-Port-Of: odoo/odoo#236913This update fixes a technical issue preventing portal users from correctly filtering job postings. The change involved adding a security layer (`sudo()`) to access department data, which was previously causing access errors. This ensures portal users can consistently use the department filter functionality.
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 update resolves issues where copying and pasting content within the website builder could cause rendering errors or duplicated content. The fix filters out specific attributes that trigger saved node behavior, ensuring pasted content integrates correctly and avoids unexpected formatting changes. This improves website stability and user experience.
Original PR description
When the user copies a range of the html in the page, they may copy nodes with attributes that mark them to be saved. This happens if they select around a savable node, or if they select inside a savable node and the format plugin include clones of the ancestors (to keep matching style). This commit filters the attributes on the nodes that are copied, to prevent the user from pasting nodes marked as they should be saved. Steps to reproduce: - Open website builder - Select a link of the menu in the header - Copy - Move the selection to "normal" text (like in the footer) - Paste - Save - Bug: the website cannot render ### - Open website builder in translate mode, on a blog post - Select a word in the middle of a paragraph - Copy - Paste - Bug: The paragraph gets replicated inside itself opw-5053872 task-5222402
18 changes
Resolved issues and error corrections
This update fixes an issue where the Payslip Work Days Lines report displayed data for both Indian and Belgium payrolls. The fix adds a filter to ensure the report only shows data relevant to the currently selected company, improving data accuracy and user experience.
Original PR description
Steps to reproduce: - Install Indian and Belgium payroll. - Go to Payslip Work Days Lines report. - Employee data of both companies are shown. Issue: Payslip Work Days Lines Report Should Show Only Selected Company’s Data. Cause: Filtering was missing to set the data according to selected company Fix: Added domain in view to show data according to the current selected company. task-5407727
This change prevents unnecessary calculations when retrieving data for fields that are inherited from other models. By optimizing how these fields are accessed, we've reduced processing time and improved the overall performance of Odoo, especially when dealing with complex data relationships. This ensures a smoother and faster user experience.
Original PR description
when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it…
when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it [here](https://github.com/odoo/odoo/blob/b48d41086d7ff8ef91c6c43d37d588686d6b921a/odoo/orm/fields.py#L923) and field is from inherited model it trying ``model._read_group_groupby(model._table, groupby, query)`` because those related and non store. As there is no meaning for computation for that because it going groupable because it parent_field is groupable. So, keeping check for that and reduce the computation.
```
File "/tmp/tmpmagm1mli/migrations/base/tests/test_mock_crawl.py", line 430, in mock_act_window
views = get_views(
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 463, in get_views
res = super().get_views(views, options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/models.py", line 10, in get_views
result = super().get_views(views, options=options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_ui_view.py", line 52, in get_views
return super().get_views(views, options)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 2935, in get_views
result['models'][model] = {"fields": self.env[model].fields_get(
File "/home/odoo/src/odoo/19.0/addons/stock/models/product.py", line 521, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_model.py", line 76, in fields_get
return super().fields_get(allfields, attributes=attributes)
File "/home/odoo/src/enterprise/19.0/ai_fields/models/models.py", line 47, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3360, in fields_get
description = field.get_description(self.env, attributes=attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 883, in get_description
value = value(env)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 930, in _description_groupable
model._read_group_groupby(model._table, groupby, query)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_activity_mixin.py", line 259, in _read_group_groupby
return super()._read_group_groupby(alias, groupby_spec, query)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 2064, in _read_group_groupby
coquery = comodel._search(codomain, bypass_access=field.bypass_search_access)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_attachment.py", line 659, in _search
records = self.sudo().with_context(active_test=False).search_fetch(
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1418, in search_fetch
return self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3914, in _fetch_query
rows = self.env.execute_query(query.select(*sql_terms))
File "/home/odoo/src/odoo/19.0/odoo/orm/environments.py", line 534, in execute_query
self.cr.execute(query)
File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 426, in execute
self._obj.execute(query, params)
psycopg2.DatabaseError: out of memory for query result
```
opw-5260147
upg-3444635
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239991
Forward-Port-Of: odoo/odoo#239400This update resolves an issue where loading demo data in a newly created company within the Appraisal module would trigger an access error. The fix changes the demo employee data to reflect the current company, eliminating the permission conflict and allowing users to successfully load the sample data.
Original PR description
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module. **Steps to Reproduce:** 1. Install `hr_appraisal` without demo data. 2. Create a…
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module.
**Steps to Reproduce:**
1. Install `hr_appraisal` without demo data.
2. Create a new company and switch to it.
3. Appraisals > Click "Load sample data".
**Traceback:**
```
AccessError
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Sengsourigna Phonkaseumsouk (id=2) doesn't have 'read' access to:
- Employee, Emma Granger (hr.employee: 3, company=TPX Solutions)
Blame the following rules:
- Employee multi-company rule
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue; you might be able to access the record by switching to the company: TPX Solutions.
ParseError
while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside <function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref('hr_appraisal.hr_appraisal_2')]"/>
ValueError
ParseError('while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside\n<function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref(\'hr_appraisal.hr_appraisal_2\')]"/>') while evaluating 'action = model._load_demo_data()'
```
**Cause:**
The demo data loading process attempts to access employee records without the required permissions. Since the user belongs to a different company, the multi-company security rules prevent reading those employees.
**Fix:**
This commit removes the company assignment from the demo employee records so they are created in the current company instead of the base company.
sentry-7032880299
Forward-Port-Of: odoo/odoo#239415This update resolves a problem where the system incorrectly attempted to load translations for the 'be_comp' localization, leading to a ValueError. The fix ensures the correct company context is used during translation loading, preventing this error and ensuring translations are applied correctly.
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.
- There is no context of the company passed when calling _get_chart_template_data from _load_translations, so I have applied with_company, so _get_chart_template_data is called in the context of a specific company.
opw-5342498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239887
Forward-Port-Of: odoo/odoo#239809This update corrects an issue where subscription products incorrectly displayed both recurring and list prices on their product cards. Now, subscription products show only the recurring price, ensuring accurate pricing information for customers. This improves clarity and simplifies product understanding.
Original PR description
Version - 18.0 Steps to Reproduce: Issue 1: Incorrect tooltip text 1. Go to Products → Products in subscription app. 2. Open a product page and select goods product type 3. observe product_tooltip…
Version
- 18.0
Steps to Reproduce:
Issue 1: Incorrect tooltip text
1. Go to Products → Products in subscription app.
2. Open a product page and select goods product type
3. observe product_tooltip show incorrect wording:
* "Based on order" showed end of the period.
* "Based on delivered" showed beginning of the period.
Issue 2: Product card shows both recurring and sales price
1. Go to Products → Products in subscription app.
2. Observe that the product card displays both recurring price and sales price
After this PR:
- Tooltip now correctly states:
* for "based on order" invoice_policy -> beginning of period
* for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.
task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />
Forward-Port-Of: odoo/enterprise#101914
Forward-Port-Of: odoo/enterprise#95010This update corrects a bug that prevented Mexican companies from successfully sending CFDI invoices with global discounts. The issue stemmed from incorrect discount distribution logic within the account module, leading to negative line amounts. This fix ensures proper CFDI generation and transmission for Mexican clients.
Original PR description
**PROBLEM** With a Mexican company, when trying to send a CFDI with a global discount, it can happen that after the repartition of the discount we have lines with a negative amount, so we can't send…
**PROBLEM** With a Mexican company, when trying to send a CFDI with a global discount, it can happen that after the repartition of the discount we have lines with a negative amount, so we can't send the CFDI. **STEP TO REPRODUCE** 1. Take a mexican company 2. create a quotation with, product A = 1$, product B = 100$, global discount of 15% 3. create an invoice using this quotation, confirm it and try sending the CDFI. 4. the following error will appear : "Error when sending the CFDI to the PAC: Failed to distribute some negative lines" **CAUSE** In account, the function `_normalize_target_factor()` takes a list of dictionnary `target_factors`, with the keys being invoice lines (the targets) and the keys being weights (the factors). It is used to normalize the weight associated with the lines, to later use them to dispatch things like discounts to those lines. This function also does a sort on the weight, and return a list containing pairs of index and weights. This is useful only in the function `_distribute_delta_amount_smoothly()`, other functions doesn't work well with the sorted returned list: they don't use the index, and dispatch discounts to the wrong lines.
This update speeds up the calculation of product quantities in our system, particularly for databases with many products (over 700,000). By optimizing the process, we've significantly reduced the time it takes to perform this calculation, leading to a faster and more responsive system. This improvement enhances overall system performance and efficiency.
Original PR description
In databases with a large number of products, most of them will have 0 quantities on hand. This commit fast-tracks the computation of 0 qty products, skipping unnecessary `uom_id` and `float_round()` computations in _compute_quantities_dict and skipping unnecessary `__set_item__` in _compute_quantities. Benchmark | `product.product` count | Before this PR | After this PR | | ----------------------- | -------------- | ------------- | | 700,000 | 52.84s | 28.33s | opw-4930856 Forward-Port-Of: odoo/odoo#239918 Forward-Port-Of: odoo/odoo#239687
This update addresses an issue where runbot reporting was incomplete due to changes in how errors were handled during testing. Restoring logging to capture errors will provide more accurate reporting from the runbot, ensuring better monitoring of test results. This improves the reliability of our automated testing process.
Original PR description
One of the changes in #118332 was to let exceptions bubble up to the interpreter in case of error, to improve the experience while running the script locally. This turns out to have downgraded runbot reporting significantly as it doesn't account for stderr / log tracebacks if it got error-level (and possibly even warning-level) logs during the run. Hopefully get the best of both world (and shorten tracebacks slightly) by restoring `logging.exception` at the script level but triggering an abnormal exit for local CLI utility. Forward-Port-Of: odoo/odoo#239995
This update resolves a critical bug in the Report Editor where Google Translate was causing incorrect data to be saved and ultimately crashing the system. By disabling translation specifically within the report editing iframe, the issue is now fixed, ensuring accurate report data and stable operation.
Original PR description
Before this commit, when google translate was active on the current ReportEditor, it produced wrong data to save, and ultimately crashes. After this commit, since we disable the translation on the whole HTML element inside the iframe (that is only for the edited report), there is no error any more opw-5122924 Forward-Port-Of: odoo/enterprise#97019
This update resolves an issue where the web_studio report editor was generating invalid report designs. Specifically, it prevents errors when users attempt to add fields to reports, ensuring a more stable and reliable report creation process. This fix addresses a technical problem that could have disrupted report generation for users.
Original PR description
cf commit Forward-Port-Of: odoo/enterprise#101970 Forward-Port-Of: odoo/enterprise#99385
This update fixes a security vulnerability where portal users with existing sales orders could edit their country information. Previously, this was restricted only through the main portal interface. Now, the system prevents users with orders from modifying their country details via the profile settings, ensuring data integrity.
Original PR description
Steps to reproduce: 1. Install website_forum, website_sale. 2. Confirm a Sale Order for a portal user. 3. Log in as the portal user, go to My Account -> Edit Information. 4. Country is in readonly. 5. Go to Forum -> Profile -> Edit 6. Edit the country 7. Nothing stops the user from doing so. --- Description of the issue this commit addresses: If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user. --- Desired behavior after the commit is merged: When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore. --- task-5331916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237781
This update fixes an issue where background colors were lost when copying tables from the Knowledge editor to other Odoo applications. The change ensures that the correct MIME type is used for copying, preserving formatting during the copy/paste process. This improves the consistency and usability of table editing within Odoo.
Original PR description
To make it possible to properly copy DOM elements across editors, the `application/vnd.odoo.odoo-editor` mimetype was introduced in the `ClipboardPlugin`. However, this was not used inside the `HtmlViewer`. Because of this, some content formatting could be lost when copying elements from an `HtmlViewer` to an editor. This commit solves this by also invoking the code that fills the clipboard in `ClipboardPlugin` when content is copied in an `HtmlViewer`. Steps to reproduce: - Insert a table in Knowledge - Set a background color on a few cells - Use the "lock" feature of Knowledge (inside a dropdown the menu on the right) - Select the entire table - Copy/paste it in a project task => The background colors in the cells were lost task-4017841 Forward-Port-Of: odoo/odoo#239603 Forward-Port-Of: odoo/odoo#238655
This update resolves an issue where attempting to refund orders containing archived products resulted in a blank page. The fix ensures that product information is correctly synchronized, allowing refunds to process smoothly even after a product has been archived. This improves the reliability of the Point of Sale system.
Original PR description
Step to reproduce: - start pos and finalize a order with product A - go backend - Archive product A - start the pos again - try to refund the order Observation: - Blank page with traceback in console…
Step to reproduce: - start pos and finalize a order with product A - go backend - Archive product A - start the pos again - try to refund the order Observation: - Blank page with traceback in console ``` Caused by: TypeError: Cannot read properties of undefined (reading 'filter') at __exports.getOrderChanges at Proxy.getOrderChanges ``` Cause: - until now `product.template` model is looked for filter after a reload https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/models/data_service_options.js#L91-L93 https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/services/data_service.js#L290-L295 and not `product.product`, this makes `product_id` available but `product_tmpl_id` undefined, causing inconsistency Fix: - we add `product.product` in `cleanupModels` for data to in sync with backend opw-5237961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential error that could occur when creating invoices with journal items that don't have labels assigned. The change ensures that the code handles missing label values gracefully, preventing a traceback and ensuring invoices can be successfully validated. This improves the stability of invoice creation processes.
Original PR description
Creating an invoice containing journal items without a label triggers a traceback because the code unconditionally slices the 'name' field (line.name[:64]) without ensuring it is not False. Since 'name' is not a required field on account.move.line, it must be safely handled.
This commit ensures that the label is always a string by falling back to an empty string when the value is missing.
Steps to reproduce the bug:
- Create a storable product
- Create an invoice:
- Add the product to the invoice
- Set any customer
- Go to the journal items tab
- Remove the label of the journal item corresponding to the product
- Try to validate the invoice
- A traceback is raised
opw-5360602
Forward-Port-Of: odoo/odoo#239664
Forward-Port-Of: odoo/odoo#239188This update resolves an issue where a newly duplicated website page wasn't immediately visible in the page list. Users now need to reload the page list after duplicating a page to ensure the new page appears correctly. This improves the user experience and prevents frustration when managing website pages.
Original PR description
Steps to reproduce: - Go in website page list - Select a page - Click on actions -> duplicate - Select a name - New page doesn't appear in the list, you need to reload to be able to see it task-5412167 https://github.com/odoo/odoo/issues/225299 Forward-Port-Of: odoo/odoo#240041 Forward-Port-Of: odoo/odoo#239702
This update resolves an issue where triple-clicking a checkbox in a checklist would unexpectedly select the entire list item. The fix ensures that triple-clicking a checkbox only checks the box, improving the user experience and preventing unintended selections.
Original PR description
**Current behavior before PR:** Currently, triple clicking on a checkbox in a checklist item ends up selecting the list content. This happens because in `selection_plugin` `onTripleClick` handler selects the whole list item. **Desired behavior after PR is merged:** This PR ensures that `onTripleClick` in `selection_plugin` does nothing if tripleclick is triggered when checking a box. task-5361579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238876 Forward-Port-Of: odoo/odoo#237690
This update allows administrators to prevent automatic module installation during database upgrades, addressing potential upgrade failures caused by outdated or missing modules. This enhances stability and ensures business logic functions correctly, particularly after module uninstalls or new stable releases.
Original PR description
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the…
In some case, a database can be in a state where some auto install module are not installed - when the user uninstall a module - when module was added in stable and a database was created before the addition. It can lead to issues where an upgrade fails or some business logic does not work as expected because of the missing modules. This is not easy to reproduce and to test, even if uninstalling such module should in theory work and be tested. This pr proposes to add a flag "--skip-auto-install" to the config to be able to disable all auto install of modules. It is open to discussion to change this to a config option, with or without a module list **Initial solution (alternative to avoid a config)** --dev skipautoinstall **Current solutions** (command line param) --skip-auto-install **Maybe in the future but unlikely** (more flexible) --skip-auto-install=all --skip-auto-install=web_enterprise,iap (krma suggestions) --skip-auto-install=* --skip-auto-install=web_*,iap Those two last one could be more flexible but the use case are limited and can be done another way with an explicit -i, maybe no worth the additional complexity (mainly since we need to filter in two different places) Note that this pr uses **get** on the config just in case the config is monkey patched somewhere to make it more robust. Forward-Port-Of: odoo/odoo#239044 Forward-Port-Of: odoo/odoo#234710
This update resolves a bug preventing purchase orders from being found when matching vendor bills created by users associated with a company. The fix normalizes the search criteria to account for the difference between how purchase orders and vendor bills store partner information, ensuring accurate matching and bill visibility.
Original PR description
There are two issues: 1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user…
There are two issues:
1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user with a company
2) When making a bill matching, the vendors bill will not appear.
Steps to reproduce:
-------------------
* Create a company A
* Create a partner A of type individual as a sub-partner to the company A
* Create a purchase order with partner A and confirm it
* Create a vendor bill corresponding to the purchase order
1)
* Click on the purchase matching smart button the vendor bill and try to add to PO
* Search for the purchase order
-> Issue, the purchase order does not appear.
2)
* Go on the purchase order
* Click on Bill matching smart button
-> Issue the vendor bills will not appear
Observation:
-----------
The issue is that purchase Orders store the partner exactly as selected (individual contact), while Vendor Bills are normalized internally to the parent company ("commercial_partner_id'). This creates a mismatch when making the search.
https://github.com/odoo/odoo/blob/9e9e992698946b75212040ca0ff812194200a8bf/addons/account/models/account_move_line.py#L480-L483
1) The domain of the search is
https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/purchase/wizard/bill_to_po_wizard_views.xml#L10-L11
The domain on the search does not take into consideration the missmatch between Vendor Bill and PO.
2) When calling action_bill_matching, the domain is:
https://github.com/odoo/odoo/blob/73590e017e9f2861b0852952e14261e57eb67f70/addons/purchase/models/purchase_order.py#L609-L621
This is a similar issue as 1) and https://github.com/odoo/odoo/commit/c0e86ba6d31708fb16765ba0e0596adc2f29dcd8
Why the fix:
------------
Commercial_partner_id is always set, adding it in the search will allow to normalize the search on the parent_company if there is one.
https://github.com/odoo/odoo/blob/18.0/odoo/addons/base/models/res_partner.py#L450-L455
opw-5067995
Forward-Port-Of: odoo/odoo#2369132 changes
Resolved issues and error corrections
This update fixes an issue where invoice reports for KE companies were not displaying prices with commas. The fix removes a duplicate XPath and correctly formats the total and taxable amounts, ensuring accurate financial reporting. This improves clarity and compliance for KE-related invoices.
Original PR description
Steps to reproduce: 1. install `l10n_ke` 2. Switch to KE Company 3. Create a product with all KRA eTIMS details set on the Accounting page. 4. Create an invoice to KE Company with that product and set unitprice > 10000 5. Confirm the invoice and send it. Now, see the invoice report Issue: 1. xpath for `td_subtotal` was duplicated 2. The total amount and taxable amount were not formatted as prices (no commas). Before: <img width="771" height="397" alt="image" src="https://github.com/user-attachments/assets/492fe911-18d6-4e01-a16d-d7450c17373f" /> After: <img width="766" height="389" alt="image" src="https://github.com/user-attachments/assets/bbe5d4e2-b337-445c-833a-06492a8c827d" /> Solution: Updated the invoice report to: - Remove the duplicated `td_subtotal` xpath. - Properly format the total and taxable amounts with `t-options`. opw-5341578 Forward-Port-Of: odoo/enterprise#101586 Forward-Port-Of: odoo/enterprise#100279
This update resolves a critical bug in the Report Editor where Google Translate was causing incorrect data to be saved and ultimately crashing the system. By disabling translation specifically within the report editing iframe, the issue is now fixed, ensuring accurate report generation and preventing errors.
Original PR description
Before this commit, when google translate was active on the current ReportEditor, it produced wrong data to save, and ultimately crashes. After this commit, since we disable the translation on the whole HTML element inside the iframe (that is only for the edited report), there is no error any more opw-5122924 Forward-Port-Of: odoo/enterprise#97019
22 changes
Resolved issues and error corrections
This update resolves an issue where duplicating a bill within the ESG app would inadvertently create additional assignment rules. The fix ensures that only the original rule is created, maintaining data integrity and preventing unnecessary rule proliferation. This improves the stability and usability of the ESG carbon emissions tracking feature.
Original PR description
[FIX] esg: prevent rule creation on copy Steps: 1. Go to the ESG app and create a new Emissions Factor (or duplicate one for sake of ease) 2. Open the Assignation tab and create a rule for Any Account - Any Partner - Mileage 3. Create a Bill and add the Mileage product If you check here, no other assignation rule is created 4. Duplicate the bill 5. Navigate back to the Emissions Factor on the ESG app. A new assignation rule has appeared. Notice that the steps use a product Mileage as example, you can use another one You can also test the steps with different rule configuration, you only need at least one "Any" opw-5350250 https://github.com/odoo/enterprise/commit/bab99c460a93cb4eef959d8dcd2f12e4ebaa07af Forward-Port-Of: odoo/enterprise#101789
This update resolves a bug where locking a Point of Sale (PoS) with employee login and a blackbox would sometimes cause an error when trying to select an employee. The fix ensures the system checks if an employee is actually set before attempting to update the clock in date, improving PoS stability.
Original PR description
When a PoS was configured with "login with employees" and a blackbox, locking the pos then trying to select an employee raised a traceback. The PoS was trying to update the clock in date, but the employee was undefined. This is now fixed checking whether if the employee is set. Forward-Port-Of: odoo/enterprise#102137
This update fixes an issue where users without access to a document's folder were incorrectly shown as 'Restricted Folder' in the Documents Kanban view. The fix ensures the LLM receives the correct parent folder name, even when access is denied, improving the user experience and data accuracy.
Original PR description
Bug === In documents, when we don't have access on the folder of a document, we show "Restricted Folder" in the kanban view. For AI, because we don't want to add "Restricted Folder" in the prompt when the user has no access on the folder, we skip that in the compute of the display_name when we are in sudo. But display_name are always computer in sudo, so we never show "Restricted Folder". Forward-Port-Of: odoo/enterprise#100850
This update addresses an issue where certain buttons ('Reset Password' and 'Remote Debug') were not functioning correctly on Windows IoT. To ensure compatibility, these buttons have been hidden from the user interface, preventing potential errors and improving the user experience on this platform.
Original PR description
"Reset Password" and "Remote Debug" buttons are not compatible with Windows IoT, we then hide them on the corresponding records. Forward-Port-Of: odoo/enterprise#102154
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 users with company access can participate in planning slots, preventing disruptions to internal scheduling processes. This ensures consistent access for all users.
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#101883 Forward-Port-Of: odoo/enterprise#101659
This update fixes an issue where unscheduled shifts weren't immediately reflected in the Gantt view, requiring a page refresh. The change ensures shifts are updated instantly when unscheduled, improving scheduling accuracy and reducing user frustration. This improves the overall planning process.
Original PR description
**Steps to reproduce:** Go to planning gantt view. Click on shift. Click on unschedule button on popover. **Issue:** When clicking on Unschedule button on a shift popover, sometimes the shift still appears and again clicking on that it cause missing error occured until the page is refreshed. **Cause:** The record wasn’t updating in the view after a shift was unscheduled, so the unscheduled shift was still showing. **Fix:** Modified the method to reload the model and notify the view immediately after calling action_unschedule, ensuring shifts reflect the latest server state without requiring a manual refresh. task-5075381 Forward-Port-Of: odoo/enterprise#102010 Forward-Port-Of: odoo/enterprise#97108
This update fixes an issue where newly created employees were incorrectly marked as unavailable in the Planning Gantt view. The fix addresses a problem with how the system identified employee contracts and calculated working periods, ensuring accurate scheduling for all employees.
Original PR description
Steps to reproduce: - 1. Install Planning module. 2. Create a new employee without setting a contract start date. 3. Go to the Planning Gantt view by resource. Issue: - The Planning Gantt view…
Steps to reproduce:
-
1. Install Planning module.
2. Create a new employee without setting a contract start date.
3. Go to the Planning Gantt view by resource.
Issue:
-
The Planning Gantt view incorrectly grays out the entire schedule for newly created employees. It can also incorrectly gray out the initial days of a contract.
Cause:
-
1) With the introduction of `hr.version`, a version is now created for every employee by default. The logic to identify employees with a contract history was using a domain `[("employee_id", "in", ...)]`, which selects all employees, even those with no contract. This incorrectly flagged new employees as having a contract history, causing them to be marked as unavailable.
2) The view was using the computed `version.date_start` field. The computed `date_start` is calculated as the maximum of the version's creation date and the contract's start date. (e.g., contract starts Sep 1st, version created Sep 5th), the computed start date becomes Sep 5th, incorrectly graying out the period from Sep 1st to Sep 4th.
Fix:
-
1) The query that checks for an employee's contract history is now filtered by `('contract_date_start', '!=', False)`.
2) The Gantt view's working period calculation now uses the stored, `contract_date_start` and `contract_date_end` fields.
task-5058866
Forward-Port-Of: odoo/enterprise#101956
Forward-Port-Of: odoo/enterprise#94007This update ensures that shift schedules now accurately reflect a resource's working days, preventing the creation of shifts on weekends and holidays. Previously, the system incorrectly generated shifts for all days of the week, leading to inefficient scheduling. This change improves the accuracy and usability of shift planning.
Original PR description
Steps to reproduce: - Go to Planning. - Create a multi-shift for a resource for the entire week. - Shifts are created for all days, including weekends and non-working days. Issue: Shifts were created for the entire week, ignoring the resource working schedule, so weekends and non-working days were also included. Cause: Shifts were created without considering the resource’s working schedule, which led to inclusion of weekends and non-working days. Fix: Updated shift creation to align with the resource’s schedule, skipping weekends and non-working days. task-5051694 Forward-Port-Of: odoo/enterprise#95093
This update resolves an issue that caused errors during call recording by correctly managing how the system listens for media streams. The change ensures the Odoo's SIP library functions properly, preventing disruptions and improving recording reliability. This enhances the overall call recording experience.
Original PR description
When recording a call, a traceback shows up because the current session uses `onTrack` to set a listener. This is a problem because `onTrack` is a property on the `peerConnection`, this means that it overrides the listener put by SIP library. This commit fixes that by using `addEventListener` instead so the original implementation of the SIP library is not overriden. The handler override was introduced in this PR: https://github.com/odoo/enterprise/pull/99168 Task-5379708
This update refactors the HTML sanitization process within the MRP Workorder module, utilizing the 'bleach' library for enhanced security. The associated unit tests have been updated to align with these changes, ensuring consistent and reliable HTML handling.
Original PR description
Purpose ======= The HTML sanitizer has been refactored to use bleach, adapt the unit tests to those changes. Task-2812488 See odoo/odoo/pull/90965
This update fixes an issue where Odoo wasn't correctly displaying replies to Tweets, leading to a double mention. The change aligns Odoo's Twitter reply interface with Twitter's native format, now showing "In reply to <user>" in feeds and related views. This ensures a consistent and user-friendly experience when interacting with Tweets.
Original PR description
Bug === When we reply to a Tweet, we want to show "In reply to <user>", in the feed view, in the modal for the "post" and the "comments". Task-3686630
This update resolves an issue where sick leave deferral calculations were inaccurate when a leave period extended across multiple months. The fix ensures correct deferral amounts are applied, improving the accuracy of payroll processing for employees with extended sick leave. This impacts the proper calculation of employee compensation.
Original PR description
The defer computation was not correct if the leave spans multiple months. This commit fixes it. Forward-Port-Of: odoo/enterprise#102188
This update resolves a bug that prevented refunds from being processed correctly for orders created with 'Consumidor Final Anónimo' customers in the POS system. The fix ensures proper error dialogs are displayed, preventing crashes and allowing refunds to be completed for this customer segment.
Original PR description
We had a bug when attempting to refund orders that were created with the "Consumidor Final Anónimo" customer. The refund validation would crash with a TypeError instead of showing the proper error…
We had a bug when attempting to refund orders that were created with the "Consumidor Final Anónimo" customer. The refund validation would crash with a TypeError instead of showing the proper error message. Steps to reproduce: ------------------- In POS with l10n_cl_edi module activated: * Create a new order with "Consumidor Final Anónimo" as customer * Add products and pay the order * Validate the order * Attempt to refund this order > Observation: The refund validation would crash with: TypeError: Cannot read properties of undefined (reading 'add') at OrderPaymentValidation.isOrderValid Why the fix: ------------ The code was trying to access `this.dialog` which is undefined in the OrderPaymentValidation class context. The dialog service should be accessed via `this.pos.dialog`, which is the correct pattern used throughout the base OrderPaymentValidation class. This fix ensures the error dialog is properly displayed when attempting to refund orders for the anonymous final consumer, instead of crashing with a TypeError. Forward-Port-Of: odoo/enterprise#101356
This update resolves a technical error that occurred when users switched between scanner modes. The change was necessary due to a recent update to how the system communicates with devices, and the original error handling wasn't properly adjusted. This ensures the scanner functionality is now reliable.
Original PR description
When toggling the "is scanner" toggle, we were getting a traceback. This comes from the switch from longpolling to `iot_http`, but the error handling wasn't adapted. opw-5408986 Forward-Port-Of: odoo/enterprise#102059
This update ensures that orders are immediately sent to the kitchen (PDIS) after a self-order payment is confirmed, regardless of whether the user sees a confirmation page. Previously, delays or missed confirmation pages could cause confusion. This change improves the reliability of order processing for self-order and kiosk transactions.
Original PR description
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the…
pos_online_payment* = pos_online_payment_self_order_preparation_display Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268) --- Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page which, once the transaction succeeded, sent the related order to the kitchen (PDIS). However, in some cases, the user never reaches this page. For example, the user may see the payment succeed in their banking app and close the tab before the redirection happens. For POS self-orders, we must send the order to the kitchen as soon as the payment is confirmed to avoid confusion between the customer, the cashier, and the kitchen staff. Relying solely on the confirmation page was therefore unreliable. --- To fix this, we now leverage the cron that post-processes payment transactions: we gather all transactions made in self-order or kiosk mode that are not yet post-processed, and send their corresponding orders to the kitchen. This ensures that orders reach the PDIS even when the user never lands on the confirmation page. Forward-Port-Of: odoo/enterprise#99249
This update resolves an issue where incorrect date formats were appearing in reports related to bills to receive. The fix ensures dates are consistently formatted, regardless of user locale settings, improving the accuracy and reliability of financial reporting. This prevents errors and ensures data integrity.
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. Forward-Port-Of: odoo/enterprise#102030
This update automatically selects a failure location when a quality check fails, preventing incorrect stock movements and manual corrections. Previously, users had to manually choose a location, leading to errors and inconsistencies. This change ensures accurate stock tracking and reduces the risk of mistakes in quality control processes.
Original PR description
- When `failure location(s)` are configured on a `Quality Point`, users must manually choose one when failing a `quality check`. However, if the user forgets to select one, the failed quantities are incorrectly moved to the `stock location` instead of a `designated failure location`. - This results in incorrect stock moves and quantity values, requires manual corrections, and increasing the risk of mistakes. This improvement ensures that the quality check wizard automatically preselects the first available failure location whenever at least one exist, ensuring that failed quantities are correctly going to failure location even if user don't select one, which ensures consistency across all operation types, creates correct stock moves, and maintains accurate quantity values. Task ID: 4737111
This update refreshes the user interface for the signer experience within the Enterprise module. The changes modernize the toolbar and background, creating a more consistent and professional look and feel. This improves the overall user experience for signing documents.
Original PR description
Before this PR, the toolbar was looking a bit old and the viewer background was to dark in LM. Now it is more harmonized. | Before | After | |--------|--------| | <img width="1596" height="831" alt="Screenshot 2025-11-13 at 17 40 51" src="https://github.com/user-attachments/assets/30eae7ae-f8bb-4fe2-87f7-9151974d5d86" /> | <img width="1596" height="831" alt="Screenshot 2025-11-13 at 17 40 37" src="https://github.com/user-attachments/assets/673ba382-0bf1-4385-b669-a81438123aac" /> | task-5060120
This update fixes an issue where assignee rows weren't displayed in the Gantt view when users had no tasks assigned. Now, all users are consistently visible, and searching by assignee filters correctly, showing only unassigned tasks within a specific project.
Original PR description
**Before this commit:** When searching for an assignee in the gantt view, the corresponding row was not displayed if the user had no tasks assigned. Similarly, when applying a custom filter on the assignee also not working properly. **After this commit:** When searching or filtering by an assignee, the corresponding user row is now always visible in the gantt view, even if the user has no assigned tasks. Custom filters on assignee also work properly. task-5076701 Forward-Port-Of: odoo/enterprise#102072 Forward-Port-Of: odoo/enterprise#96531
This update fixes a minor error in the demo data for the Belgian HR payroll module, ensuring the correct number of paid time off days are displayed. The maximum allowed time off has also been updated to comply with Belgian law (24 days for 6-day workweeks).
Original PR description
In the demo data, the number of paid time off was displayed as 21, when it should be 20. The issue was tracked to the statement used for assigning the working schedule to each employee. Also the maximum time off possible is now 24 days as stated by the law (for people working 6 days a week). task-5172492 Forward-Port-Of: odoo/enterprise#98228
This update addresses a requirement from FAIA version 2.01, which now mandates the inclusion of a 'PurchaseInvoices' tag in the generated SAFT XML reports for Luxembourg (`l10n_lu`) companies. Previously, vendor bills weren't correctly identified, leading to report discrepancies. This change implements a standardized template to ensure accurate reporting.
Original PR description
Since version 2.01 of FAIA, it is a requirement to include the `PurchaseInvoices` tag in the FAIA XML. With a `l10n_lu` company: - Create a vendor bill. - In the general ledger, download the FAIA XML report. In the generated XML document, the vendor bill will not appear under `PurchaseInvoices`. The `PurchaseInvoices` section is meant to mirror the `SalesInvoices` section and contains the exact same structure. This PR implements a generic template for both. **Specs and source** (in `FAIA_v2.01_full`): https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360572 Forward-Port-Of: odoo/enterprise#102092 Forward-Port-Of: odoo/enterprise#100697
This update fixes an issue where refreshing a new offer page would reset the employee information, requiring users to re-enter details. The change ensures the correct employee context is maintained when the offer page is refreshed, improving the user experience and data accuracy. This prevents data entry errors and streamlines the offer creation process.
Original PR description
Steps to Reproduce ================== - Go to Employees - Choose an employee with no offers - Click on the "Offers - new" smart button (a form view will open with the correct employee name at the bottom) - Refresh the offer's page without saving (the employee field is emptied and the required Applicant field appears) Issue ================== The generate offer action that is triggered through the smart button returns a one-time action dictionary with the context. But that context is lost when we refresh the offer page as it's not saved anywhere. Fix ================== Replace the action dictionary with an action record for creating a new offer to ensure the context is maintained upon page refresh. Task-ID: 5059490
16 changes
Resolved issues and error corrections
This update resolves an issue where the deferral of sick leave payments was inaccurate when the leave duration extended across multiple months. The fix ensures that leave deferrals are calculated correctly, leading to more precise payroll processing for employees with extended sick leave. This improves the accuracy of financial reporting.
Original PR description
The defer computation was not correct if the leave spans multiple months. This commit fixes it.
This update resolves an issue where the Odoo PWA app wasn't working correctly in certain customized browsers like Wecom and DingTalk. The fix ensures the app functions properly by handling cases where browser version information is missing, improving overall PWA support and user experience.
Original PR description
Description of the issue/feature this PR addresses: In some customized browsers, such as Wecom and DingTalk, the userAgent may not contain the Version information, resulting in an error. Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Odoo PWA (Progressive Web App) functionality wasn't working correctly in certain customized browsers like Safari. The fix ensures a smoother PWA installation experience by addressing a version check problem, improving overall reliability and user experience for PWA users.
Original PR description
Description of the issue/feature this PR addresses: In some customized browsers, such as Wecom and DingTalk, the userAgent may not contain the Version information, resulting in an error. Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that user rows are always visible in the Gantt view, even when they don't have assigned tasks. Previously, users without tasks were hidden, and searching wasn't reliable. Now, the Gantt view accurately displays all users, making assignee searches and filtering more effective.
Original PR description
**Before this commit:** When searching for an assignee in the gantt view, the corresponding row was not displayed if the user had no tasks assigned. Similarly, when applying a custom filter on the assignee also not working properly. **After this commit:** When searching or filtering by an assignee, the corresponding user row is now always visible in the gantt view, even if the user has no assigned tasks. Custom filters on assignee also work properly. task-5076701 Forward-Port-Of: odoo/enterprise#101986 Forward-Port-Of: odoo/enterprise#96531
This update resolves an issue impacting the calculation of sick leave payouts within the Belgian HR payroll module. The fix ensures accurate accrual and payment of sick time off covering multiple months, improving payroll accuracy and compliance. This change primarily affects employees receiving sick leave payments.
Original PR description
…months
This update resolves errors that occurred when duplicating folders, particularly when duplicating the 'Company' root folder. The system now correctly handles folder duplication within the application, and a previous issue where copies were incorrectly placed within the original folder is now addressed.
Original PR description
**Before this PR:** - Duplicating a folder into itself caused a traceback. - Duplicating a folder into one of its sub-folders also caused a traceback. - Duplicating the 'Company' root folder into 'My Drive' incorrectly created the copy inside the 'Company' folder instead. **Technical reason:** - A record was being created before the copy operation, which led to infinite recursion. - The owner was incorrectly set as the parent folder, causing the duplicated folder to appear in 'Company' folder. **After this PR:** - Duplicating a folder into itself or any of its sub-folders now works correctly. - Attempting to duplicate the Company root folder into My Drive will no longer work and will instead display a warning. Task-5149773
This update resolves a critical issue where the Odoo Report Editor was crashing due to incorrect translation processing within the report's HTML. By disabling translation specifically for the report's iframe content, the problem is fixed, ensuring reports save correctly and preventing future crashes.
Original PR description
Before this commit, when google translate was active on the current ReportEditor, it produced wrong data to save, and ultimately crashes. After this commit, since we disable the translation on the whole HTML element inside the iframe (that is only for the edited report), there is no error any more opw-5122924 Forward-Port-Of: odoo/enterprise#97019
This update fixes an issue where the barcode app on mobile devices displayed stock locations in a list view, which isn't ideal for small screens. By adding a setting to prioritize kanban views on mobile, the app now presents stock locations in a more user-friendly format, improving usability on smaller devices.
Original PR description
Issue ===== On mobile, we should prioritize kanban views over list views because kanban views are usually more suitable for small device screen. That said, when a product's barcode is scanned in the Barcode app main menu, we show this product's stock locations but we do that with a list view, no matter if the user is on a big screen or a small screen. How to reproduce ================ On mobile device: - Enable location and have a product with a barcode and with quantities in two different locations; - Open Barcode app; - Scan the product's barcode => The product's stock locations are displayed in a list view, which is not very pratical on small device. Fix === The action key `mobile_view_mode` was not set, with this key, we can define what view type we want to prioritize for mobile device. [opw-5180783](https://www.odoo.com/odoo/project/49/tasks/5180783) Forward-Port-Of: odoo/enterprise#101872 Forward-Port-Of: odoo/enterprise#101336
This update resolves a bug that caused Odoo to crash when calculating inventory values for FIFO products with a zero standard price and no prior cost history. The fix introduces a safeguard to prevent infinite recursion, ensuring accurate stock valuation and stability. This improves the reliability of inventory reporting.
Original PR description
Current behavior: The server crashes with a `RecursionError`. This happens because the valuation logic attempts to retrieve a historical cost when the current standard price is 0.0. For FIFO products without prior history, the system inspects the last move's value. Since that move also has 0 cost, it calls `_get_value_from_std_price` again, triggering an infinite loop. Fix: This commit adds a recursion guard using `self.env.context`. If the valuation method detects it is already running for the current record, it falls back to the current standard price (0.0) instead of attempting another historical lookup. Closes #239564
This update fixes an issue where the download button appeared prematurely in the eSigner wizard and addressed text size problems when users signed with Aadhaar. Now, the download button only appears after signing, and text is correctly sized for readability, ensuring a smoother user experience for e-signature workflows.
Original PR description
Version: - 19.0 Issue: - The wizard shows a download button even when using emsigner, but the file should only be downloaded after signing. - When users sign with Aadhaar and download the document, the text appears too small. Fixes: - Hide the download button in the wizard for emsigner requests. - Adjust page coordinates so the font size displays correctly. Impact: - Makes the text clear and readable in documents signed with Aadhaar. - Hides the download button until the user signs. After signing with eSigner, they can download the document with the certificate. task-5075596
This update resolves an issue where clicking 'Send' in the Sign Request wizard incorrectly redirected users to the signing interface when the sender was also a signer. The fix ensures that clicking 'Send' now correctly closes the wizard, providing a smoother user experience for sending sign requests.
Original PR description
When creating a Sign Request where the sender is also one of the signers, clicking Send in the wizard incorrectly redirected to the document preview/signing interface. This fix ensures that clicking Send always closes the wizard and does not trigger any redirect, regardless of the sender’s signer status. task-5408155
This update allows users to configure recurring prices for individual product variants within subscription orders. Previously, users couldn't specify variant-specific pricing, limiting flexibility. This change ensures accurate recurring revenue tracking for products with multiple variations.
Original PR description
Version: - 19.0 Before: - When creating a product with variants and setting recurring prices, users could not select product variants in the recurring price list. Issue: - The recurring price list appeared read-only for product variants, preventing users from defining variant-specific recurring prices. Cause: - The product variant field was missing from the recurring pricing view. Fix: - Added the product variant field to the recurring prices list view, allowing users to select and manage variants while setting recurring prices. Taskid-5361266
This update resolves an issue preventing price adjustments in the POS system when using the Swedish blackbox integration. Previously, price control wasn't possible. Now, users can manage prices correctly within the Swedish blackbox, aligning with current regulations. This ensures accurate reporting and transactions for Swedish customers.
Original PR description
Before this commit, user couldn't control the price in the POS if using the swedish blackbox. After this commit, user can control the price. It's not clear why the behavior at integration was set to this but it appears that it's not mandatory for swedish blackbox unlike the belgian one. opw-5253401 Forward-Port-Of: odoo/enterprise#101797 Forward-Port-Of: odoo/enterprise#100984
This update ensures that Luxembourg companies (l10n_lu) using the general ledger and generating FAIA XML reports correctly include vendor bills under the 'PurchaseInvoices' tag, as required by a recent FAIA update. This resolves a reporting discrepancy and ensures compliance with Luxembourg tax regulations.
Original PR description
Since version 2.01 of FAIA, it is a requirement to include the `PurchaseInvoices` tag in the FAIA XML. With a `l10n_lu` company: - Create a vendor bill. - In the general ledger, download the FAIA XML report. In the generated XML document, the vendor bill will not appear under `PurchaseInvoices`. The `PurchaseInvoices` section is meant to mirror the `SalesInvoices` section and contains the exact same structure. This PR implements a generic template for both. **Specs and source** (in `FAIA_v2.01_full`): https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360572 Forward-Port-Of: odoo/enterprise#102092 Forward-Port-Of: odoo/enterprise#100697
This update fixes an issue where the Quality Control module's list view was incorrectly loading. The change ensures the correct view is used, resolving a problem that prevented users from accessing the Control Points feature. This ensures the Quality Control module functions as intended.
Original PR description
Since odoo/enterprise#94012, when loading the quality.point list view from the main menu, `quality_point_routing_view_tree` is used instead of `quality_point_view_tree`. This is not correct. To reproduce : - Install quality_control and mrp_workorder - In Quality Module, go to Quality Control / Control Points [opw-5253899](https://www.odoo.com/odoo/project/966/tasks/5253899)
This update prevents website errors related to rental events when product types are misconfigured. Specifically, it addresses a technical issue that caused tracebacks during payment processing, ensuring a smoother user experience for customers purchasing rental tickets. While the rental feature itself is being addressed, this fix focuses on robust error handling.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `website_event_sale` but not `stock` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- Having odd configurations like rentable tickets creates rental orders without rental dates, leading to unhandled errors. Solution -------- While rentable event tickets doesn't make enough sense to make it work, we can still improve the error handling to prevent showing tracebacks to the client. opw-5207045 Forward-Port-Of: odoo/enterprise#101859 Forward-Port-Of: odoo/enterprise#99000
14 changes
Resolved issues and error corrections
This update fixes an issue where invoice totals were incorrect when exporting data for WPAY. Specifically, it now includes the necessary IGST tax amount in the JSON data, ensuring accurate reporting and compliance. This change improves the reliability of the export process for international transactions.
Original PR description
This commit fixes the invoice total value for the case of export in case of WPAY. For the case of export, there are no taxes, but in the JSON data we need to include the IGST tax amount in the invoice total. community:-https://github.com/odoo/odoo/pull/237260 opw-5267055
This update fixes an issue where the IGST (Integrated Goods and Services Tax) export tax wasn't correctly included in Odoo's accounting for WPAY transactions. The change ensures the total invoice value accurately reflects the IGST amount, aligning with tax regulations for export sales. This improves the accuracy of financial reporting.
Original PR description
For export WPAY transactions, the IGST amount must be included in both the item value and the total invoice value. This patch ensures the IGST tax amount is correctly added when the The transaction is an export. enterprise:-https://github.com/odoo/enterprise/pull/100412 opw-5267055
This update resolves a formatting problem in invoice PDFs generated when using quotation templates in sales orders. Previously, the product name and description were combined on a single line. Now, a necessary line break is added to ensure proper invoice formatting and readability, aligning with standard invoice practices.
Original PR description
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale and invoicing installed 2- Create a quotation template, and add a description in the line. 3- Create a quotation with the created template. 4- Confirm the order and create an invoice for the sale order. 5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line. `_get_journal_items_full_name` is used to enforce the product name in the description. However, in cases where product name doesn't exist in the description, e.g. our case here, the name and description will be shown in the same line in the invoice pdf. This can be fixed by adding a new line between the name and the description. read: #235122 opw-5130171
This update corrects a formatting issue in invoices generated when using quotation templates in sales orders. Previously, the invoice PDF displayed product names and descriptions on the same line, leading to an unorganized appearance. This fix ensures proper line breaks, improving invoice readability and presentation.
Original PR description
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale and invoicing installed 2- Create a quotation template, and add a description in the line. 3- Create a quotation with the created template. 4- Confirm the order and create an invoice for the sale order. 5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line. `_get_journal_items_full_name` is used to enforce the product name in the description. However, in cases where product name doesn't exist in the description, e.g. our case here, the name and description will be shown in the same line in the invoice pdf. This can be fixed by adding a new line between the name and the description. opw-5130171
This update addresses an issue where runbot reporting was incomplete due to changes in how errors were handled during local testing. The fix restores logging to provide more detailed reporting, ensuring runbots accurately reflect test results and reducing tracebacks. This improves the reliability of automated testing.
Original PR description
One of the changes in #118332 was to let exceptions bubble up to the interpreter in case of error, to improve the experience while running the script locally. This turns out to have downgraded runbot reporting significantly as it doesn't account for stderr / log tracebacks if it got error-level (and possibly even warning-level) logs during the run. Hopefully get the best of both world (and shorten tracebacks slightly) by restoring `logging.exception` at the script level but triggering an abnormal exit for local CLI utility. Forward-Port-Of: odoo/odoo#239995
This update fixes a security vulnerability where portal users could modify their country information even when associated with an existing sale order. Previously, this restriction was only enforced through the main website portal. Now, the system prevents users with invoices or sales orders from changing their country details via the profile settings, ensuring data integrity.
Original PR description
Steps to reproduce: 1. Install website_forum, website_sale. 2. Confirm a Sale Order for a portal user. 3. Log in as the portal user, go to My Account -> Edit Information. 4. Country is in readonly. 5. Go to Forum -> Profile -> Edit 6. Edit the country 7. Nothing stops the user from doing so. --- Description of the issue this commit addresses: If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user. --- Desired behavior after the commit is merged: When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore. --- task-5331916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237781
This update fixes an issue where the TM-m30 printer wasn't correctly identified as a receipt printer in Odoo. Now, the system automatically detects the TM-m30 and ZPL printers, ensuring they are categorized as receipt printers, which improves printer compatibility and functionality within Odoo.
Original PR description
Before this commit, the receipt printer subtype was assigned based on the presence of `CMD:ESC/POS;` in the `device-id` of the printer. However, this string was only present for the `lpd` backend, for `dnssd` it was not resulting in a subtype of Office printer. After this commit, we additionally check for the string `TM-m30` in the device name, and if it is present we set it as a receipt printer. We also check for the string `ZPL` and if found set it as a label printer. task-5411994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where copying and pasting empty list items in the HTML editor would prevent the backspace key from working. The fix inserts a line break (<br>) into the pasted item, allowing for proper text deletion. This improves the overall usability of the HTML editor.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a new paragraph, type some text. - Create a numbered list below paragraph, type some text. - Keep the cursor at the start of list text and select the above text - Copy the selection and paste in a new paragraph. - Backspace in pasted list is not working. This happens because pasted list item is empty. **Desired behavior after PR is merged:** Now, copied empty list item is filled with `<br>`, as result backspace works properly. task-5226511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that invoice PDFs generated for the Chilean (*l10n_cl*) localization correctly display unit prices without decimal points, aligning with Chilean accounting standards. Previously, the PDF format consistently showed prices with two decimal places, which is not required in Chile. This update improves invoice accuracy and compliance.
Original PR description
**Steps to reproduce:** * Install the *l10n_cl* module with demo data. * Switch the environment to the **CL** company. * Create a customer invoice containing at least one invoice line. Enter a…
**Steps to reproduce:** * Install the *l10n_cl* module with demo data. * Switch the environment to the **CL** company. * Create a customer invoice containing at least one invoice line. Enter a **price_unit with decimals** (e.g., *99.56*). * Confirm the invoice. * Download and open the generated PDF from the invoice form. **Observed behavior:** * The **unit price** rendered in the PDF is displayed as a rounded decimal value (e.g., *100.00*), even though *Chilean* localization does **not** use decimal representation for unit prices. **Cause:** * The QWeb template uses `t-options` to format float values with **two-decimal precision**, forcing decimals to appear in the PDF. **Fix:** * Reduce the formatting precision in the PDF template so that **no decimal points** are displayed, matching Chilean localization rules. **Before Fix** <img width="783" height="319" alt="image" src="https://github.com/user-attachments/assets/e5ea5a38-a77a-4d64-9aae-672940734ea4" /> **After Fix** <img width="794" height="316" alt="image" src="https://github.com/user-attachments/assets/c47d2f0a-b4ea-428e-bf57-23584c34bf5c" /> --- opw-5234563
This update resolves an issue where printing reports (specifically 'Lot/Serial Number (PDF)') would fail if the report itself was previously deleted. The fix prevents a system error that occurs when attempting to access report IDs after deletion, ensuring a smoother user experience when generating labels.
Original PR description
This error occurs when the user deletes the `Lot/Serial Number (PDF)` report and then attempts to print report. Steps to reproduce: --- - Install `stock` module(without demo) - Search `Lot/Serial Number (PDF)` in `..Actions/Reports` > Delete it - Enable `Lots & Serial Numbers` in settings. - Create a Picking and `Mark as TODO` - Set a `Serial Numbers` in order line - In cog menu `Print Labels` > `Lot/SN labels` > `Confirm` > `Confirm` Traceback: --- `ValueError: External ID not found in the system: stock.action_report_lot_label` At [1], when we try to access any report XML ID, we encounter an error because the corresponding report has been deleted. [1]- https://github.com/odoo/odoo/blob/b6b37a794f9e3e724a32a3529ce2ef7361b8046e/addons/stock/wizard/stock_lot_label_layout.py#L40 sentry-7064566500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue impacting payroll calculations for Swiss employees, specifically related to overtime payments (ST-Overtime) and the LPP (Lump-Sum Payment Plan). The fix ensures accurate tax and social security deductions are applied, improving compliance and financial reporting for businesses using the Odoo Enterprise module.
Original PR description
Forward-Port-Of: odoo/enterprise#102161
This update resolves an issue where image styles (like transform and width) were incorrectly applied to new media types after an image was replaced. Now, styles are automatically removed when switching between image and other media types, ensuring consistent styling across the HTML editor. This improves the user experience and prevents unexpected visual behavior.
Original PR description
**Current behavior before PR:** - When an image had styles applied to it (such as transform or width) and was replaced with another media type like an icon or document, those styles were incorrectly carried over to the replaced media. **Desired behavior after PR is merged:** - Since transform and width styles are meant to apply only to images, they are now removed when an image is replaced with other media types. task-5373362
This update fixes an issue where analytic distribution information was lost when expenses were reinvoiced to customers. Now, the analytic account linked to the sales order takes priority, ensuring accurate tracking of costs and revenue across all related documents (expense, SO, and vendor bill).
Original PR description
Steps to reproduce the flow: - Create an expensable product “Hotel” that can be reinvoiced to a customer - Create an analytic distribution model that automatically applies the analytic account…
Steps to reproduce the flow: - Create an expensable product “Hotel” that can be reinvoiced to a customer - Create an analytic distribution model that automatically applies the analytic account “Commercial &Marketing” to the previous created product “Hotel” - Create an SO for a customer “Gilles”. The SO is linked to the analytic account “Home Construction” - Create an expense which category is “Hotel”. The analytic distribution is automatically set to “Commercial & Marketing” - Reinvoice this expense to “Gilles”. The analytic distribution automatically changes to “Home Construction”. -> Wrong. We lose part of the information - When posting the expense report, the expense is added in the SO through a dedicated SO line. The analytic account previously set as “Home Construction” is now transformed, for an unknown reason, into “Commercial & Marketing”. -> Wrong. - On the vendor bill, the analytic distribution is “Home Construction” Now: 1. The analytic plans from the expense and from the SO are different. Simply add the analytic account from the SO 2. The analytic plans are the same. There are conflicts. In this case, the analytic distribution set on the SO is prioritary. We ensure that costs incurred or sales generated from the expense are reflected in the SO's analytic plan rather than the generic one. In the previous example, Home Construction is the only analytic account that should be considered on the expense, bill and SO. task-4564463
A recent update was incorrectly displaying inaccurate reconciliation numbers on the dashboard, leading to users not seeing the expected reconciliation entries. This revert fixes the issue by ensuring the correct number of entries is shown, allowing users to properly reconcile their accounts. This resolves several related support tickets.
Original PR description
This recent commit is causing an issue for lots of databases. The wrong number of entries to reconcile is displayed on the dashboard. After clicking on the "N to reconcile" button, no entries appear in the reconciliation view. this is a revert of commit #ed71144 opw-5414718 opw-5418442 opw-5418117 opw-5417268 opw-5417879 opw-5417291
5 changes
Resolved issues and error corrections
This update resolves an issue impacting Swiss payroll calculations, specifically related to overtime payments (ST-Aperiodic) and the calculation of LPP (Lohn- und Produktivitäts-Pauschale). The changes ensure accurate reporting of these key payroll components, aligning with Swiss tax regulations.
This update addresses an issue where runbot reports weren't accurately capturing errors or warnings during test module runs. The change restores logging to provide better reporting, while maintaining a standard experience for local testing. This ensures more reliable and comprehensive test results.
Original PR description
One of the changes in #118332 was to let exceptions bubble up to the interpreter in case of error, to improve the experience while running the script locally. This turns out to have downgraded runbot reporting significantly as it doesn't account for stderr / log tracebacks if it got error-level (and possibly even warning-level) logs during the run. Hopefully get the best of both world (and shorten tracebacks slightly) by restoring `logging.exception` at the script level but triggering an abnormal exit for local CLI utility. Forward-Port-Of: odoo/odoo#239995
This update fixes a bug that prevented users from uploading images when quoting tweets within the Odoo Enterprise application. The change allows users to attach images to quoted tweets, enhancing the functionality and user experience. This resolves an issue identified in a previous version.
Original PR description
Bug === Since odoo/odoo@e8567dadbdaaec6e5be8f66f12e2b02da321f999 , it's not possible to upload an image when we quote a tweet. Now, the file data is supposed to be managed in the onChange event, and we can not rely on the input value. Task-3339389
This update fixes an issue where Sendcloud delivery address parsing incorrectly handled addresses with multiple dashes or slashes, such as those common in Austria. The change improves the accuracy of address recognition, ensuring correct delivery address formatting and preventing potential delivery errors. This ensures accurate address data is used when creating shipments.
Original PR description
Issue ----- When creating a sendcloud delivery, addresses containing multiple dashes or slashes (eg Austrian addresses) have their number incorrectly parsed. Examples: Innsbruck Straße 8/1/13 -> 8/11 (should be 8/11/13) 7-3/11A Hochköning Straße -> 7-3 (should be 7-3/11A) Fix ----- Update part of the regex pattern from `\d+[-\/]?\d*` to `\d+(?:[-\/]?\d+)*` in order to match multiple occurences of one of '-', '\' or '/' followed by some number. ----- Ticket: opw-5366863
This update ensures that rental orders created from leads automatically include the tags associated with the original lead. Previously, rental orders lacked this tag inheritance, which is now corrected through a code adjustment. This improves data organization and reporting for rental agreements.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a lead with tags; 2. convert lead to rental order. Issue ----- The new rental order has no tags. Cause ----- Tags are added to regular sales orders via the `_prepare_opportunity_quotation_context` method, but rental orders use `_get_action_rental_context` instead, which is virtually identical, but adds the `in_rental_app` context value, and doesn't include `default_tag_ids`. Solution -------- Rather than having duplicate code, make `_get_action_rental_context` retrieve the base context from `_prepare_opportunity_quotation_context`, then adding `in_rental_app=True`. opw-4549941