Daily updates from Odoo
Friday, September 26, 2025
89 changes
10 changes
Resolved issues and error corrections
The IoT box remote debugging dialog now always shows the generate password button. This removes an outdated restriction so users can access the password action when needed.
Original PR description
Since we recently removed the check for the requests sent to the iot box controllers the generate password button being invisible doesn't make sense anymore. This PR makes it always visible Forward-Port-Of: odoo/odoo#228602
The project creation wizard now displays the Customer field neatly on one line when Billable is enabled. This keeps the form visually consistent and easier to read for users creating billable projects.
Original PR description
**Steps to Reproduce:** - Go to the Projects app - Click "Create" to open the wizard - Enable the "Billable" option - Observe the alignment of the "Customer" field that appears **Issue:** The…
**Steps to Reproduce:** - Go to the Projects app - Click "Create" to open the wizard - Enable the "Billable" option - Observe the alignment of the "Customer" field that appears **Issue:** The "Customer" label and input field are stacked vertically, with the input's underline (green line) positioned below the label, leading to uneven spacing and misalignment compared to other fields. **Current behaviour:** - The "Customer" field is visually misaligned , its label and input are not horizontally aligned, causing UI inconsistency. **Expected behaviour:** - The "Customer" label and input field should align horizontally on a single line, with the input's underline matching the label's baseline. **Fix:** The layout is updated using proper flexbox classes to ensure the "Customer" label and input field appear on the same line with proper vertical alignment. Task-4949146 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221242
Belgian point-of-sale users now see a clear “Device disconnected” message when the blackbox device is unplugged or loses connection. This avoids confusing staff with a vague unknown error and helps them understand the issue faster.
Original PR description
When the blackbox is being disconnected the user gets "unknown blackbox error" instead of "Device disconnected" explicit message. This PR removes this vague error message introduced in https://github.com/odoo/enterprise/pull/93468 Forward-Port-Of: odoo/enterprise#95489
Users with view-only access can now mark documents as favorites using the keyboard shortcut without hitting an access error. This makes the Documents app shortcut behavior consistent with the regular favorite button and avoids an unnecessary interruption in daily document navigation.
Original PR description
steps to reproduce =================== - Select a document where you have viewer permission. - Try to toggle the favorite through a hotkey. - Access Error when toggling favorite. Technical =========== - To maintain compatibility with stable versions and avoid changing the return type of the existing method, created the helper method, which will call `toggle_favorited` as we need to handle it for multiple records. After this commit ================== - This commit handles the accessError for shortcut flow. As in 18.3 we already have documents_favorite widget https://github.com/odoo/enterprise/pull/82639 which will work for manually favoriting the document, but it is not handling the shortcut flow. Task-4910326 Forward-Port-Of: odoo/enterprise#89928
Recruitment offers now handle cases where an employee signs multiple contracts from the same offer without causing an error. The system uses the most recently signed contract, helping HR teams complete hiring workflows smoothly.
Original PR description
Issue: - In recruitment, if an employee sign multiple contract from a same offer, we are getting singleton error. Fix: - To fix this we will take the latest signed contract into consideration. task: 5089959
New users can now load demo data in the Attendance app without hitting an access error. This makes it easier for teams to try or evaluate Attendance features without needing administrator intervention.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module. Steps to reproduce: --- - Install ``hr_attendance`` module (without demo data) - Create NEW user >…
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module.
Steps to reproduce:
---
- Install ``hr_attendance`` module (without demo data)
- Create NEW user > Login with new user
- Open ``Attendance`` and Click ``Load Demo Data``
Traceback:
---
```
AccessError
You are not allowed to create 'Resource Working Time' (resource.calendar) records.
This operation is allowed for the following groups:
- Administration/Settings
Contact your administrator to request access if necessary.
ParseError
while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside <record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">
<field name="name">Standard 32 hours/week (4 work days, friday free)</field>
<field name="company_id" eval="False"/>
<field name="hours_per_day">8</field>
<field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {'name': 'Monday Morning', 'dayofweek': '0', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Monday Lunch', 'dayofweek': '0', 'hour_from': 12, 'hour_to': 13, 'day_period': 'lunch'}), (0, 0, {'name': 'Monday Afternoon', 'dayofweek': '0', 'hour_from': 13, 'hour_to': 17, 'day_period': 'afternoon'}), (0, 0, {'name': 'Tuesday Morning', 'dayofweek': '1', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Tu...
ValueError
ParseError('while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside\n<record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">\n <field name="name">Standard 32 hours/week (4 work days, friday free)</field>\n <field name="company_id" eval="False"/>\n <field name="hours_per_day">8</field>\n <field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {\'name\': \'Monday Morning\', \'dayofweek\': \'0\', \'hour_from\': 8, \'hour_to\': 12, \'day_period\': \'morning\'}), (0, 0, {\'name\': \'Monday Lunch\', \'dayofweek\': \'0\', \'hour_from\': 12, \'hour_to\': 13, \'day_period\': \'lunch\'}), (0, 0, {\'name\': \'Monday Afternoon\', \'dayofweek\': \'0\', \'hour_from\': 13, \'hour_to\': 17, \'day_period\': \'afternoon\'}), (0, 0, {\'name\': \'Tuesday Morning\', \'dayofweek\': \'1\', \'hour_from\': 8, \'hour...
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195714This fixes an issue where a completed manufacturing backorder could incorrectly change an earlier operation from cancelled to in progress. It helps production teams see the correct work order status and avoid confusion when tracking partially completed manufacturing orders.
Original PR description
In this bug, in backorder created for later work opertions, the `state` of initial operation is changed to `progress` after, the backorder is `done`. To produce the bug: 1- Create a Bill of Materials with at least two operations at two work centers 2- Create a manufacturing order and confirm it. 3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity 4- In the second work order, the first operation initially appears as `Cancelled`. Once the second operation is completed, it will change to `In progress`. opw-4931653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222075
New users can now load demo data in the Appraisal app without encountering an error. This helps evaluators and administrators test or explore the appraisal workflow smoothly, even when the module was installed without demo data initially.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module. Steps to reproduce: --- - Install `hr_appraisal` module (without demo data) - Create NEW user > Login…
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.
Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`
Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
<field name="user_id" ref="base.user_admin"/>
<field name="name">Appraisal of Emma Granger</field>
<field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'), ref('hr.work_contact_eg')])]"/>
<field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
<field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
<field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
<field name="res_model">hr.appraisal</field>
<field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
</record>
ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n <field name="user_id" ref="base.user_admin"/>\n <field name="name">Appraisal of Emma Granger</field>\n <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'), ref(\'hr.work_contact_eg\')])]"/>\n <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n <field name="res_model">hr.appraisal</field>\n <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n </record>') while evaluating
'action = model._load_demo_data()'
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
Forward-Port-Of: odoo/enterprise#93461This fix prevents images inserted into an empty formatted line in the HTML editor from being removed when the content is cleaned up. Users can now add images from placeholders without losing them after clicking elsewhere, improving editing reliability.
Original PR description
Problem: When an image is added inside a `data-oe-zws-empty-inline`, it is removed along with its parent during normalization. Solution: During normalization, replace `data-oe-zws-empty-inline` with the image inside instead of removing both. Steps to reproduce: - Press CTRL+B in an empty line - Press Enter - Click on "Insert image, ..." from the placeholder - Choose an image - Click in the previous paragraph - The image disappears without this fix task-5051343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224922
Updating the color of a blog tag now refreshes existing blog posts that use it, so the public blog page displays the new color as expected. This prevents outdated tag colors from remaining visible due to cached page content.
Original PR description
Steps to reproduce: - Go to the /blog page - See that some posts use some tags - Go to Configuration > Tags - Change the color of an existing tag - Go back to the /blog page => The color of the tag is not updated for existing posts using it. This is a t-cache issue, which unfortunately is difficult to fix in stable (as it would require modifying multiple nodes in qweb). As a workaround, and knowing that the t-cache system was fully removed in 19.0 at [1], this fixes the bug with a hack: on tag update, make a dummy update to the related blog posts already using it. Tag updates should be quite rare anyway. [1]: https://github.com/odoo/odoo/commit/1cf06a5688e6aa80175d5a28a83b639d0eb925a7 task-4045724 Forward-Port-Of: odoo/odoo#228428
17 changes
Resolved issues and error corrections
Fixed an issue where membership products could disappear from invoice line search after the product's purchase option was disabled. This keeps membership invoicing workflows consistent and avoids confusion when editing draft invoices.
Original PR description
**Steps to Reproduce:** 1. Create a new membership product from the Membership module. 2. Open any partner and go to the Membership page. 3. Click on Buy Membership and select the created product. 4.…
**Steps to Reproduce:**
1. Create a new membership product from the Membership module.
2. Open any partner and go to the Membership page.
3. Click on Buy Membership and select the created product.
4. Click on Invoice Membership.
5. Open the newly created draft invoice.
6. From the invoice line, open the product form (via the internal link).
7. Disable the Can be Purchased option and return to the invoice using breadcrumbs.
8. Add a new line in the invoice and search for the same product by its name.
**Observation:**
1. When Can be Purchased is enabled on the product, the product appears in the invoice line search.
2. When Can be Purchased is disabled, the product no longer appears in the search.
**Issue:**
In the product field domain defined in
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029 the `default_move_type` context is `null`.
As a result, only the condition `[('purchase_ok', '=', True)]` is applied in the `name_search` domain.
**Solution:**
Pass the proper context value in the invoice action, ensuring the domain evaluates correctly and the product remains searchable.
**Note:**
The domain used in the following field
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029
is evaluated by a following JavaScript function
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/web/static/src/core/py_js/py_interpreter.js#L483-L489
rather than on the Python backend. Because the domain logic depends on dynamic
context evaluation performed client-side, there is no straightforward way to
retrieve or test the domain arguments dynamically within the `name_search`
method on the server. As a result, it is not feasible to write automated test
cases for this specific domain filtering scenario in the backend.
opw-5028789
Forward-Port-Of: odoo/odoo#225230Fixes an issue in bank reconciliation where, when several bank lines were reconciled at once, an exchange difference entry could be attached to the wrong line. This helps keep accounting records accurate for multi-line reconciliations involving currency differences.
Original PR description
When selecting multiple lines in the bank rec widget (reconcile button), it could happen that one of those lines have a exchange diff move linked to it. In this case, the exchange move id was placed on the first line all the time which could be wrong. This commit will change the use of indexes to use the reconciled line of the exchange diff move. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures bank reconciliation assigns exchange difference entries to the correct selected line when multiple lines are reconciled together. It reduces the risk of accounting records being linked to the wrong transaction, improving accuracy in multi-currency reconciliation workflows.
Original PR description
When selecting multiple lines in the bank rec widget (reconcile button), it could happen that one of those lines have a exchange diff move linked to it. In this case, the exchange move id was placed on the first line all the time which could be wrong. This commit will change the use of indexes to use the reconciled line of the exchange diff move. no task id
Users now see a clear “Device disconnected” message when the Belgian POS blackbox device is unplugged or loses connection. This avoids a vague unknown error and helps staff understand and resolve the issue faster.
Original PR description
When the blackbox is being disconnected the user gets "unknown blackbox error" instead of "Device disconnected" explicit message. This PR removes this vague error message introduced in https://github.com/odoo/enterprise/pull/93468 Forward-Port-Of: odoo/enterprise#95489
This fixes an issue where borders added to images in email marketing were missing when recipients viewed the email. Image styling is now preserved more reliably, helping sent emails match the design created by the user.
Original PR description
Problem: When adding a border to an image and sending an email, the border is not visible in the received email. Solution: Ensure a `border-style` is set if missing, otherwise keep the existing one. Steps to reproduce: - Open email marketing. - Add an image snippet. - Add a border to the image. - Send the email. - The received image has no border. opw-5004824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223867
Users with view-only access can now mark or unmark documents as favorites using keyboard shortcuts without seeing an access error. This makes the shortcut behavior consistent with the standard favorite button and avoids interruptions for document viewers.
Original PR description
steps to reproduce =================== - Select a document where you have viewer permission. - Try to toggle the favorite through a hotkey. - Access Error when toggling favorite. Technical =========== - To maintain compatibility with stable versions and avoid changing the return type of the existing method, created the helper method, which will call `toggle_favorited` as we need to handle it for multiple records. After this commit ================== - This commit handles the accessError for shortcut flow. As in 18.3 we already have documents_favorite widget https://github.com/odoo/enterprise/pull/82639 which will work for manually favoriting the document, but it is not handling the shortcut flow. Task-4910326 Forward-Port-Of: odoo/enterprise#89928
This fixes an issue in the Timesheet Attendance report query that could cause database errors during upgrades. By correctly identifying the employee field, affected upgrade processes can complete as expected without this report blocking them.
Original PR description
In the affected query, the variable "employee_id" is undefined in the scope where it is used. This leads postgres to interpret it as a variable with default type VARCHAR and to the impossibility to compare it against an integer. We just qualify the variable name so it now works as expected. Failing upgrade requests: [3103245](https://upgrade.odoo.com/odoo/request/3103245) [3121291](https://upgrade.odoo.com/odoo/request/3121291) Fixes https://github.com/odoo/odoo/pull/192434/commits/c97ecfa7fc091f763329af589b69db2292931163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225401
The self-order mobile test now cancels only orders that are still in draft status. This prevents test failures caused by trying to cancel completed or paid orders, improving reliability without changing customer-facing behavior.
Original PR description
Before this commit: = - Previously, `test_self_order_mobile` set all orders to cancel, causing errors with finalized orders (e.g., paid orders from demo data). After this commit: = - Only draft orders are cancelled, preventing errors and ensuring correct test behavior. Runboat Error: 224197
This fix prevents an earlier manufacturing operation from incorrectly changing to “In progress” after a later backordered operation is completed. It keeps work order statuses accurate, reducing confusion for production teams tracking manufacturing progress.
Original PR description
In this bug, in backorder created for later work opertions, the `state` of initial operation is changed to `progress` after, the backorder is `done`. To produce the bug: 1- Create a Bill of Materials with at least two operations at two work centers 2- Create a manufacturing order and confirm it. 3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity 4- In the second work order, the first operation initially appears as `Cancelled`. Once the second operation is completed, it will change to `In progress`. opw-4931653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222075
The website SEO dialog now ignores dynamic template images that users cannot edit. This prevents broken image icons from appearing in the image optimization area on pages such as appointments and courses, making SEO guidance clearer and less confusing.
Original PR description
**Issue:** In the SEO dialog, under the `Images Optimization` section, broken images are displayed due to the inclusion of non-editable dynamic template images. This issue has been observed on the appointment and course pages. **Steps to reproduce:** 1. Go to the `Appointment` page on the website. 2. Go to `Site` settings present in the header > `Optimize SEO`. 3. Notice under the `Images Optimization` section, the broken image icon. See [screencast](https://drive.google.com/file/d/1EZTF2FY1ljj6S2PLwwt42Vht1IdVC3aK/view) Exclude non-editable dynamic template images from the SEO dialog's `Images Optimization` section. Users cannot modify their `alt` attributes, so including them serves no purpose.
Dark mode display issues were fixed in Point of Sale and Appointments so icons and text remain easy to see. This improves readability and consistency for users working with darker interface settings.
Original PR description
In this commit: ------------------- - Added a dark mode color for the star icon. - Changed the text color to white in light mode, which is reflected as black in dark mode. This fixes the issue of the text not being properly visible in dark mode. task:4943078
New users can now load demo data in the Attendance app without running into a permissions error. This makes onboarding and testing smoother for teams setting up Attendance for the first time.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module. Steps to reproduce: --- - Install ``hr_attendance`` module (without demo data) - Create NEW user >…
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module.
Steps to reproduce:
---
- Install ``hr_attendance`` module (without demo data)
- Create NEW user > Login with new user
- Open ``Attendance`` and Click ``Load Demo Data``
Traceback:
---
```
AccessError
You are not allowed to create 'Resource Working Time' (resource.calendar) records.
This operation is allowed for the following groups:
- Administration/Settings
Contact your administrator to request access if necessary.
ParseError
while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside <record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">
<field name="name">Standard 32 hours/week (4 work days, friday free)</field>
<field name="company_id" eval="False"/>
<field name="hours_per_day">8</field>
<field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {'name': 'Monday Morning', 'dayofweek': '0', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Monday Lunch', 'dayofweek': '0', 'hour_from': 12, 'hour_to': 13, 'day_period': 'lunch'}), (0, 0, {'name': 'Monday Afternoon', 'dayofweek': '0', 'hour_from': 13, 'hour_to': 17, 'day_period': 'afternoon'}), (0, 0, {'name': 'Tuesday Morning', 'dayofweek': '1', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Tu...
ValueError
ParseError('while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside\n<record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">\n <field name="name">Standard 32 hours/week (4 work days, friday free)</field>\n <field name="company_id" eval="False"/>\n <field name="hours_per_day">8</field>\n <field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {\'name\': \'Monday Morning\', \'dayofweek\': \'0\', \'hour_from\': 8, \'hour_to\': 12, \'day_period\': \'morning\'}), (0, 0, {\'name\': \'Monday Lunch\', \'dayofweek\': \'0\', \'hour_from\': 12, \'hour_to\': 13, \'day_period\': \'lunch\'}), (0, 0, {\'name\': \'Monday Afternoon\', \'dayofweek\': \'0\', \'hour_from\': 13, \'hour_to\': 17, \'day_period\': \'afternoon\'}), (0, 0, {\'name\': \'Tuesday Morning\', \'dayofweek\': \'1\', \'hour_from\': 8, \'hour...
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195714This fixes an issue that prevented newly created users from loading sample data in the Appraisal app. The change ensures the demo data setup runs with the needed permissions, so users can explore the app without encountering an error.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module. Steps to reproduce: --- - Install `hr_appraisal` module (without demo data) - Create NEW user > Login…
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.
Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`
Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
<field name="user_id" ref="base.user_admin"/>
<field name="name">Appraisal of Emma Granger</field>
<field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'), ref('hr.work_contact_eg')])]"/>
<field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
<field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
<field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
<field name="res_model">hr.appraisal</field>
<field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
</record>
ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n <field name="user_id" ref="base.user_admin"/>\n <field name="name">Appraisal of Emma Granger</field>\n <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'), ref(\'hr.work_contact_eg\')])]"/>\n <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n <field name="res_model">hr.appraisal</field>\n <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n </record>') while evaluating
'action = model._load_demo_data()'
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
Forward-Port-Of: odoo/enterprise#93461UAE invoice reports no longer show the same amount information twice when tax-included pricing is enabled. This keeps printed proforma and tax invoices clearer and avoids confusion for customers and accounting users.
Original PR description
**Step to reproduce:** - install account module with localization "UAE" - go to Settings > Tax Included - create a invoice (make sure a tax is applied) - print any invoice (Proforma or Tax)…
**Step to reproduce:**
- install account module with localization "UAE"
- go to Settings > Tax Included
- create a invoice (make sure a tax is applied)
- print any invoice (Proforma or Tax)
**Observation:**
- the amount is being displayed twice in the Amount column.
**Cause:**
- A change was introduced in 18.0 to add additional column right after Amount
column, [1] in l10n_ae module
- Another commit [2] in saas-18.3 introduces same column in main account module
- hence we have two columns printing same information
**Fix:**
- Removed and fixed a faulty xpath from view, as after commit [2]
base layout provides same logic
[1] https://github.com/odoo/odoo/commit/fe68fa30b18f90411043fc6e2314fd376ddaed0c
[2] https://github.com/odoo/odoo/commit/1bf232c22f430d282aaadd858c5e61fed12f4da6
**Before:**
<img width="774" height="146" alt="image" src="https://github.com/user-attachments/assets/a9eb6af2-81b3-4989-bf6e-6676eafe10f8" />
**After:**
<img width="813" height="143" alt="image" src="https://github.com/user-attachments/assets/fb019516-de7d-4dd3-b7dd-3fd14322b031" />
opw-4976410
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe AI field picker now prevents the same field from being selected multiple times and clearly marks fields that are already selected. Long field paths also wrap correctly, making them easier to remove and improving day-to-day usability.
Original PR description
before this commit: When you press Enter in the field picker, it will always pick the same field again, even if it is not visible. After this commit: A field can only be selected once, and it stays visible in the list. Added a visual check to show that the field is already selected.
Rating forms no longer show stray “by” or “on” text when publisher comments or related details are missing. This keeps rating records cleaner and avoids confusing users after comments are removed.
Original PR description
Steps to Reproduce: 1. Navigate to a rating record form view 2. View ratings without publisher comments 3. Notice confusing 'by on' text fragments appearing Current Behavior: - 'by on' text shows even when there's no comment or publisher information - Text fragments remain visible after comments are removed Expected Behavior: - 'by' and 'on' text should only appear when there's actual content to display - Proper conditional visibility based on comment presence Changes Made: - Added conditional visibility to rating form view text elements - Improved XML structure for better maintainability - Fixed persistent text display issues when comments are removed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing a blog tag color now correctly updates existing blog posts that use that tag. This ensures visitors see the latest tag styling on blog pages without waiting for old cached content to refresh.
Original PR description
Steps to reproduce: - Go to the /blog page - See that some posts use some tags - Go to Configuration > Tags - Change the color of an existing tag - Go back to the /blog page => The color of the tag is not updated for existing posts using it. This is a t-cache issue, which unfortunately is difficult to fix in stable (as it would require modifying multiple nodes in qweb). As a workaround, and knowing that the t-cache system was fully removed in 19.0 at [1], this fixes the bug with a hack: on tag update, make a dummy update to the related blog posts already using it. Tag updates should be quite rare anyway. [1]: https://github.com/odoo/odoo/commit/1cf06a5688e6aa80175d5a28a83b639d0eb925a7 task-4045724 Forward-Port-Of: odoo/odoo#228428
9 changes
Resolved issues and error corrections
Users with viewer permission can now mark documents as favorites using the keyboard shortcut without seeing an access error. This makes the Documents app shortcut behavior consistent and prevents disruption for users who rely on favorites to organize files.
Original PR description
steps to reproduce =================== - Select a document where you have viewer permission. - Try to toggle the favorite through a hotkey. - Access Error when toggling favorite. Technical =========== - To maintain compatibility with stable versions and avoid changing the return type of the existing method, created the helper method, which will call `toggle_favorited` as we need to handle it for multiple records. After this commit ================== - This commit handles the accessError for shortcut flow. As in 18.3 we already have documents_favorite widget https://github.com/odoo/enterprise/pull/82639 which will work for manually favoriting the document, but it is not handling the shortcut flow. Task-4910326 Forward-Port-Of: odoo/enterprise#89928
This fix ensures Swedish ISO 20022 payment processing passes all needed information through the system when other add-ons extend the same process. It helps prevent customization-related issues and keeps payment file generation more reliable.
Original PR description
Pass all arguments to super-call of _get_company_PartyIdentification32-method in account_iso20022/models/account_journal_iso20022_se.py so they can be passed correctly in other modules inheriting the method. Forward-Port-Of: odoo/enterprise#93883
This fix ensures helpdesk tickets appear properly in timesheet reports when they should. It corrects a previous report update that missed the right part of the report layout, helping users see more complete ticket-related time information.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
Users now see a clear “Device disconnected” message when the Belgian POS blackbox is unplugged or loses connection. This replaces a vague unknown error, helping staff understand the issue faster and reduce confusion at checkout.
Original PR description
When the blackbox is being disconnected the user gets "unknown blackbox error" instead of "Device disconnected" explicit message. This PR removes this vague error message introduced in https://github.com/odoo/enterprise/pull/93468
This fix keeps the restaurant appointment floor screen aligned with recent point-of-sale changes. It helps ensure restaurant staff can continue using table and appointment flows reliably without screen errors.
Original PR description
This commit adapts an overriding method to reflect changes in the base method done in this pr https://github.com/odoo/odoo/pull/176016.
This fix updates product barcode lookup checks so product weight data is only set and verified when the product form supports it. It also corrects test permissions for product variants, helping prevent false failures in automated quality checks.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so we can't set them. - The variant rights were not passed correctly for the first basic test. After this commit: ----------------------- - We have updated the test and checked that weight is correctly set when present in the view. - Now we have passed the correct variant right for the test. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155 Forward-Port-Of: odoo/enterprise#93075
The barcode kanban view now only displays existing inventory quantity records instead of allowing new ones to be created. This prevents accidental inventory entries when users scan or type product barcodes and then open the kanban view.
Original PR description
Steps to reproduce: - Scan or type product barcode - Navigate to Kanban View Problem: - New `stock.quants` are not supposed to be created from `stock.quant.kanban.barcode`, its only to supposed to show existing ones. Forward-Port-Of: odoo/enterprise#94802
This fix prevents an error when newly created users try to load sample data in the Appraisal app. It ensures the demo setup runs with the necessary permissions, so users can explore the module without needing administrator access.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module. Steps to reproduce: --- - Install `hr_appraisal` module (without demo data) - Create NEW user > Login…
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.
Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`
Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
<field name="user_id" ref="base.user_admin"/>
<field name="name">Appraisal of Emma Granger</field>
<field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'), ref('hr.work_contact_eg')])]"/>
<field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
<field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
<field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
<field name="res_model">hr.appraisal</field>
<field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
</record>
ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n <field name="user_id" ref="base.user_admin"/>\n <field name="name">Appraisal of Emma Granger</field>\n <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'), ref(\'hr.work_contact_eg\')])]"/>\n <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n <field name="res_model">hr.appraisal</field>\n <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n </record>') while evaluating
'action = model._load_demo_data()'
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
Forward-Port-Of: odoo/enterprise#93461This fix corrects the order of two exempt amount columns in the Mexican DIOT downloadable text file. The reported values were already calculated correctly, but placing them in the right columns helps ensure the exported file matches the expected tax reporting format.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95383
5 changes
Resolved issues and error corrections
The WhatsApp message composer now requires users to select a template before sending. This prevents an error that occurred when sending without a template and makes the process clearer for users.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the "WhatsApp" button next to the phone number. 3. Remove the template and click Send Message. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874
The Helpdesk dashboard's SLA Success Rate action now opens the expected list of recently closed tickets resolved within the SLA. This helps support teams trust their performance metrics and quickly review successful SLA outcomes.
Original PR description
**Steps to Reproduce** - Install the Helpdesk module. - Check the My Performance section. - Click on SLA Success Rate. **Issue:** Clicking on SLA Success Rate does nothing. It should display the closed tickets from the past seven days that were resolved within the SLA. **Cause:** Missed a domain filter, so no data is returned or shown. **Fix:** - Add the correct domain filter to show closed tickets. - And also modified compute method as well, so both are aligned. The problem arises in this [commit](https://github.com/odoo/enterprise/pull/76079/files#diff-e145df8bcc8742bcac578d5b05b6fc1aeaef55d236952a2a58d61ac92ce84a67R258-R260) task-4781994 Forward-Port-Of: odoo/enterprise#85412
This update removes outdated test setup declarations that are no longer needed for Knowledge, Stock Barcode, and Manufacturing Work Orders. It helps prevent automated validation errors and keeps internal quality checks aligned with the current shared testing framework, with no expected change for end users.
Original PR description
runbot-error-232620 Forward-Port-Of: odoo/enterprise#95516
Scanning a product in the Barcode app now opens the same kanban-style view used by other barcode workflows. This creates a more consistent experience for warehouse teams and avoids the unexpected switch to a list view.
Original PR description
This commit is to show the kanban view as a default when scanning a product in barcode. Before PR: All views in barcode are in kanban view except when scanning a product, it appears in list view. After PR: Now barcode also shows kanban view when scanning a product. Forward-Port-Of: odoo/enterprise#95517
SEPA direct debit email templates now use the recipient partner's language. This ensures customers receive payment-related messages in the language expected on their account, reducing confusion and support follow-up.
Original PR description
Before this commit the mail sent were not translated in the language of the partner. task-5010120
15 changes
Resolved issues and error corrections
This fixes an error that could appear after validating a reception and opening the move details when no package was assigned. Users can now view completed stock move details normally, even when package tracking is enabled but unused for that move.
Original PR description
Steps to reproduce: - Inventory -> Settings -> Enable Packages - Create a reception - Add a Product, put some quantity - Validate the reception - Open the move's details Issue: A traceback is generated, as now we're in a 'done' context and the widget should only display the closest package for each move line. But it didn't check whether there was a package assigned to the move line in the first place. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix removes unnecessary test dependencies and duplicate test helper declarations in Knowledge, Manufacturing Work Orders, and Barcode. It helps keep automated checks stable without changing day-to-day user workflows.
Original PR description
runbot-error-232620
Scanning a product in the Barcode app now opens the same kanban-style view used elsewhere in barcode workflows. This removes an inconsistent list view and makes the product scanning experience more predictable for warehouse users.
Original PR description
This commit is to show the kanban view as a default when scanning a product in barcode. Before PR: All views in barcode are in kanban view except when scanning a product, it appears in list view. After PR: Now barcode also shows kanban view when scanning a product.
This fix makes automated tour tests load their required resources consistently and avoids a conflicting test library being included in sale timesheet assets. It improves test reliability across different installation setups without changing day-to-day business features.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal upgrade issue where Odoo could try to inspect dependencies for modules that are not available in the configured add-ons path. It helps upgrades proceed more reliably when some modules are missing or intentionally unavailable.
Original PR description
`Manifest.for_addon(module_name)` returns `None` if the module is unavailable in the addons path. This is a common case during upgrades. https://github.com/odoo/odoo/blob/ef15cb776ebdd409691cef03835b51fcf7e808da/odoo/modules/module.py#L280 See also: 8e496b3df0df708280c77b9a1ae15c46e922c3bc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures spreadsheet radar chart labels are shortened only when needed. Short labels now remain readable, while longer labels are neatly shortened with an ellipsis, improving chart clarity for users.
Original PR description
Before this commit: - Radar chart point labels were truncated incorrectly because Chart.js passes extra arguments (label, index, labels) to the callback. - As a result, truncateLabel received the index as maxLen and applied unnecessary truncation. After this commit: - The callback now wraps truncateLabel to pass only the label string. - This ensures long labels are truncated with ellipsis and short labels remain unchanged. Task: 5078858 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now shows a user-friendly error when someone searches on certain many-to-many fields that are not stored in the database. This prevents confusing technical crashes and helps users or support teams understand why the search cannot be completed.
Original PR description
When searching non-stored many2many fields, fail with a user-friendly message.
`self.env['account.payment'].search([('reconciled_invoice_ids', '=', 1)])` today results in an AttributeError when trying to get the SQL for the bridge table name.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an error that could occur when shoppers opened a product page with an unavailable combination of options while using store pickup. The store location selector is now blocked for impossible combinations, preventing crashes and keeping the shopping experience stable.
Original PR description
Steps to reproduce: 1. Configure 'pick up in store' delivery method 2. Open the page of the product with an impossible combination (e.g. Customizable desk) 3. Edit the url to have attribute values of the impossible combination (2,5) There is a traceback as there is no `inStoreStockData`. After fixing it, the widget was still clickable, but as there was no product, there was another traceback since the data was not present. After this commit, the location selector is prevented from being opened when the combitation is not possible. Forward-Port-Of: odoo/odoo#228592 Forward-Port-Of: odoo/odoo#228336
This fixes a checkout error that could appear when customers bought items that do not require delivery, such as paid event tickets. The address page now handles orders without a delivery section correctly, helping customers complete checkout without interruption.
Original PR description
This commit fixes the js error triggered on the address page of the checkout. The js targets the H5 tag containing the title of the delivery div. However, if there is no deliverable product such as event tickets, this div is not rendered and an error is triggered by the js when it tries to use the textContent attribute of the undefined element. Reproduce: Register for an event with paid tickets. The error will be triggered on the address page of the checkout. Task-5107362
The IoT Box remote debugging dialog now always shows the generate password button. This avoids confusion after the related request check was removed and ensures users can access password generation when needed.
Original PR description
Since we recently removed the check for the requests sent to the iot box controllers the generate password button being invisible doesn't make sense anymore. This PR makes it always visible Forward-Port-Of: odoo/odoo#228602
This fix prevents stock users from running into an access error when sales line values include tax information. It allows the reinvoicing flow to continue smoothly without changing what users see or how they work.
Original PR description
Description of the issue/feature this PR addresses: When getting the sale line values as a stock user, we get an access error when trying to access taxes. We should bypass access checks for these values. The lines are already created with sudo. Current behavior before PR: User cannot read account.tax model. Desired behavior after PR is merged: Avoid error. (runbot.build.error/231611 - test_picking_reinvoicing) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
VAT payment instructions in Belgium and Netherlands reports now display with cleaner formatting when sent through the mail composer. This prevents awkward word breaks and misaligned fields, helping messages in the chatter look clearer and more professional.
Original PR description
Issue: -VAT payment instructions sent via mail composer were shown in the chatter with poor formatting. -Words could be split in half and fields were misaligned. Fix: -Updated the layout to improve text wrapping and field alignment in the chatter. Impact: -Ensures VAT payment instructions are displayed clearly and professionally in the chatter. task-5065873
This change removes a formatting issue in the IoT Box service setup that caused system logs to show a startup configuration warning. It helps keep device startup logs clean and avoids confusion when monitoring Odoo IoT Box services.
Original PR description
This PR fixes an error in Odoo journalctl logs: ``` Sep 12 01:11:48 iotbox systemd[1]: Starting odoo.service - Odoo IoT Box service... Sep 12 01:11:49 iotbox systemd[1]: /etc/systemd/system/odoo.service:5: Failed to parse sec value, ignoring: 0 # infinetely wait for Odoo to start Sep 12 ``` It looks like systemd attemps to interpret inline comments, which this PR removes task-5113737 Forward-Port-Of: odoo/odoo#228553
A small error in the HR contract helper was corrected so related contract versions are found accurately. This helps ensure employee contract history and related HR processes use the complete set of contract records.
Original PR description
The helper method to get all versions related to a contract was missing an '='. Forward-Port-Of: odoo/odoo#228420
Project and timesheet walkthrough tests now handle cases where project templates turn the New button into a dropdown. This helps keep automated checks reliable when demo data includes active templates, reducing false build failures.
Original PR description
Before this commit, project tours block on the Kanban and List "New" button being turned into a dropdown list when there are active project templates. These tours cannot be fixed by simply archiving or unlinking project templates before running them in the tests, because two of them are onboarding tours which need to work in both situations. With this commit, we add a new step in the tours that clicks on the "New Project" dropdown item when the button is a dropdown. Otherwise, the step will be skipped. Task-id: none (runbot builds including demo data were red)
27 changes
Resolved issues and error corrections
This fix restores a missing database index used by inventory rules to avoid confusing upgrade messages. It helps keep upgrades cleaner and preserves expected performance for company-related stock rule lookups.
Original PR description
due to conflict on this forward port https://github.com/odoo/odoo/pull/113045 ``index=True`` was removed according to this pr https://github.com/odoo/odoo/pull/90531 So, adding it back during upgrade it shows misleading logs ``` 2025-08-26 22:19:25,039 23 INFO db_3112946 odoo.schema: Keep unexpected index stock_rule_company_id_index on table stock_rule ``` opw-5052223 upg-3112946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226268
This fix prevents product packaging entries from being duplicated when a new product has attributes but only one resulting variant. It keeps product setup cleaner and avoids incorrect duplicate packaging records after saving.
Original PR description
**PROBLEM** When creating a new product, with attributes but only one variant the packaging is duplicated on save. **STEP TO REPRODUCE** 1. Install inventory, go to the settings and enable the product packagings option. 2. Create a new product, with one attribute with one possible value, and with a packaging. 3. save the product and notice the packaging was duplicated. **CAUSE** `packaging_ids` is stored on the product.product model (product variant). `packaging_ids` in the product.template model is a compute field with an inverse. When creating the product, the inverse function is called a first time, creating a first packaging. Later in the product creation, it is called a second time because of a write call on the product.template model, creating a second packaging. **FIX** In the create() and write() of product template, set some value in the context to know if we should create the packaging or not when calling the inverse function. opw-5050592
New users can now load demo data in the Attendance app without hitting an access error. This makes initial setup and evaluation smoother for teams trying the module with non-administrator accounts.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module. Steps to reproduce: --- - Install ``hr_attendance`` module (without demo data) - Create NEW user >…
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module.
Steps to reproduce:
---
- Install ``hr_attendance`` module (without demo data)
- Create NEW user > Login with new user
- Open ``Attendance`` and Click ``Load Demo Data``
Traceback:
---
```
AccessError
You are not allowed to create 'Resource Working Time' (resource.calendar) records.
This operation is allowed for the following groups:
- Administration/Settings
Contact your administrator to request access if necessary.
ParseError
while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside <record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">
<field name="name">Standard 32 hours/week (4 work days, friday free)</field>
<field name="company_id" eval="False"/>
<field name="hours_per_day">8</field>
<field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {'name': 'Monday Morning', 'dayofweek': '0', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Monday Lunch', 'dayofweek': '0', 'hour_from': 12, 'hour_to': 13, 'day_period': 'lunch'}), (0, 0, {'name': 'Monday Afternoon', 'dayofweek': '0', 'hour_from': 13, 'hour_to': 17, 'day_period': 'afternoon'}), (0, 0, {'name': 'Tuesday Morning', 'dayofweek': '1', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Tu...
ValueError
ParseError('while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside\n<record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">\n <field name="name">Standard 32 hours/week (4 work days, friday free)</field>\n <field name="company_id" eval="False"/>\n <field name="hours_per_day">8</field>\n <field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {\'name\': \'Monday Morning\', \'dayofweek\': \'0\', \'hour_from\': 8, \'hour_to\': 12, \'day_period\': \'morning\'}), (0, 0, {\'name\': \'Monday Lunch\', \'dayofweek\': \'0\', \'hour_from\': 12, \'hour_to\': 13, \'day_period\': \'lunch\'}), (0, 0, {\'name\': \'Monday Afternoon\', \'dayofweek\': \'0\', \'hour_from\': 13, \'hour_to\': 17, \'day_period\': \'afternoon\'}), (0, 0, {\'name\': \'Tuesday Morning\', \'dayofweek\': \'1\', \'hour_from\': 8, \'hour...
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prNew users can now load demo data in the Appraisal module without running into an error. This makes it easier for teams to try or evaluate the Appraisal feature in a fresh setup.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module. Steps to reproduce: --- - Install `hr_appraisal` module (without demo data) - Create NEW user > Login…
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.
Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`
Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
<field name="user_id" ref="base.user_admin"/>
<field name="name">Appraisal of Emma Granger</field>
<field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'), ref('hr.work_contact_eg')])]"/>
<field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
<field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
<field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
<field name="res_model">hr.appraisal</field>
<field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
</record>
ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n <field name="user_id" ref="base.user_admin"/>\n <field name="name">Appraisal of Emma Granger</field>\n <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'), ref(\'hr.work_contact_eg\')])]"/>\n <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n <field name="res_model">hr.appraisal</field>\n <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n </record>') while evaluating
'action = model._load_demo_data()'
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247This update corrects automated checks around product barcode lookup so product weight data is properly handled when available. It also fixes test permissions for product variants, helping prevent false failures and improving confidence in barcode lookup reliability.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so we can't set them. - The variant rights were not passed correctly for the first basic test. After this commit: ----------------------- - We have updated the test and checked that weight is correctly set when present in the view. - Now we have passed the correct variant right for the test. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155
This fixes an issue where extremely small manufacturing operation or work order durations could break planning. The change ensures scheduling can continue reliably instead of failing with an error when tiny duration values are encountered.
Original PR description
Operation & Workorder duration is a float with 2 decimal digits to be expressed in minutes, meaning minimal duration is 1sec. However one can encounter numbers like 0.001, 0.00001, ... This can lead to : AttributeError: 'NoneType' object has no attribute 'astimezone' in function _get_first_available_slot task: 5090338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures timesheet reports correctly include helpdesk ticket information where relevant. It repairs a previous update that did not properly target the report field, helping users see the expected ticket context in exported or printed reports.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
Google Calendar account resets now consistently bypass event permission checks where needed. This prevents reset failures caused by validation errors, helping users reconnect or reset calendar sync without disruption.
Original PR description
This commit adds the last context key "skip_event_permission" to the remaining writes done to `calendar.event` records at the reset of google_calendar account, created at odoo/odoo#227991. By adding it, we'll no longer face any possibility of triggering a ValidationError during account resets of google_calendar. task-5103918
Updating a product barcode no longer clears the product's e-commerce description when no new description is available from barcode lookup. This prevents accidental loss of sales content on product pages during routine product maintenance.
Original PR description
**Steps to reproduce:** 1.Install website_sale 2.Create a new product and set an e-commerce description (under the Sales page) 3.Update the barcode (length ≥ 8) in General Information page **Issue:** - The e-commerce description is cleared after updating the barcode. **Cause:** https://github.com/odoo/enterprise/blob/c0c4f5d4b9799fb88d80a6074bb1efb0cb73ccc8/product_barcodelookup/models/product_template.py#L16-L21 - The onchange triggered by barcode updates calls _update_product_by_barcodelookup method, which overrides the product's ecommerce description field even when no barcode_lookup_data and no updated description. https://github.com/odoo/enterprise/blob/233e82cf4e6908502a580be4bcd77fadd2aada53/website_product_barcodelookup/models/product_template.py#L8-L11 **Solution:** - Added a check for update the ecommerce description Only if we receive a description. opw-4813710
This fix ensures that when users add a border to an image in email content, the border remains visible after the email is sent. It improves consistency between the email editor preview and what recipients actually receive.
Original PR description
Problem: When adding a border to an image and sending an email, the border is not visible in the received email. Solution: Ensure a `border-style` is set if missing, otherwise keep the existing one. Steps to reproduce: - Open email marketing. - Add an image snippet. - Add a border to the image. - Send the email. - The received image has no border. opw-5004824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223867
This fix removes an unnecessary navigation step from an automated Point of Sale test that was causing intermittent database-related failures. It helps keep validation runs stable and reduces false alarms in the development pipeline without changing user-facing behavior.
Original PR description
Before this commit: ================= The `test_draft_pos_order_linked_sale_order` test fails intermittently with a `psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the…
Before this commit:
=================
The `test_draft_pos_order_linked_sale_order` test fails intermittently with a
`psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the
browser tour navigates back to the backend.
After this commit:
=====================
The problematic navigation step is removed from the `PosSettleOrder5` tour,
stabilizing the test and preventing the runbot error.
Cause:
========
The `Chrome.clickMenuOption("Backend", { expectUnloadPage: true })` step
forces an immediate database flush (`self.cr.flush()`) during the test's
authentication phase.
This forced flush happens when the records are in an intermediate state (after
loading the Sale Order but before payment/validation). This specific
intermediate state, combined with the subsequent recomputation of computed
fields (like `qty_delivered` through `sale_mrp` and `sale_margin`), exposes an
underlying bug in Odoo's ORM cursor management, leading to the
`psycopg2.ProgrammingError`.
Since the backend navigation is not necessary for the test's assertion logic,
removing this step prevents the premature flush and resolves the failure.
Runbot Error: 226521
Task: 4974084This fix ensures email signature formatting remains intact when messages are prepared for Outlook. It prevents image sizing and other final style settings from being accidentally merged with Outlook-specific hiding rules, leading to more consistent email appearance.
Original PR description
Problem: `_hideForOutlook` breaks the last style when appending `mso-hide: all;` if the style string does not end with `;`. Example: `width: 100%` → `width: 100% mso-hide: all;` Solution: Ensure the new attribute is appended correctly at the end of the styles, regardless of whether the last style ends with `;`. Note: The problem might be only observed on `18.4` because the composer doesn't use the user signature before `18.4`. Steps to reproduce in 18.4: 1. Open "My Profile". 2. Add an image to "email signature" with reduced scaling (25%, 50%). 3. Open any record with chatter (task, SO, invoice, etc.). 4. Type a message in chatter and click "Send". 5. Click "Open Full Compositor" and send a message from the email compositor. 6. Open the runbot's MailHog and observe the differences between the two emails. opw-5046573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web test runner now classifies errors and warnings more accurately depending on when they occur. This helps development teams see important problems without unnecessarily stopping test runs, improving reliability of quality checks.
Original PR description
This commit associates separate "issue levels" to the test runner's internal logger. These affect the logging and reporting of issues, i.e. errors and warnings: - suppressed (by 'test.todo'): issues are traced in the console but not reported in test results; - trace (default in test runs): issues are traced in the console and reported in test results; - global: issues are warned/errored in the console with "HOOT" prefix (i.e. won't interrupt the test run); - critical (default outside of test runs): issues are warned/errored in the console without "HOOT" prefix, thus interrupting the whole test run. This fix should hopefully solve errors that were too quiet before test run, or too "important" during the run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing a website theme color from the color palette and saving no longer triggers an error. This improves reliability for users editing website appearance and prevents disruption during routine design updates.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146
Users now see a clear warning instead of an error when opening a product forecast in a company that has no warehouse. This prevents a confusing crash and explains why the forecast cannot be shown until a warehouse exists.
Original PR description
Step to reproduce: - install stock - create a new company and switch to that company - open a storable product - click on forecasted smart button Cause: - StockForecasted component needs at least 1 warehouse, but when we create a new company, it does not have any warehouse https://github.com/odoo/odoo/blob/7747c5810eabe798a1631c3e3b26b81a5c89b4b4/addons/stock/static/src/stock_forecasted/stock_forecasted.js#L49-L52 - clicking on the smart button, raises traceback Fix: - we show a warning when the smart button is clicked and no warehouse is found **Note**: not adding a test case, as issue is not reproducible in test mode due to this https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 opw-5059799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Appointment bookings with custom questions or extra fields now correctly show the generated details in the appointment description field. This restores the expected behavior so staff can see customer-provided information directly on the appointment form.
Original PR description
Steps to reproduce: 1. Create an appointment with 1 question or any additional field. 2. Book the appointment throught the website filling all fields. 3. When checking in the appointment form, the description field is empty (even though the description still exists and it's being generated and sent). After #47471 where we improved the appointment sent descriptions, we also get rid of the way we used to autofill the description field in the appointment form view. This fix is a workaround to keep the same behavior we've had before this will be properly fixed in master. opw-3226882
Changing the color of a blog tag now updates how that tag appears on existing blog posts. This prevents outdated tag colors from remaining visible on the blog page after an administrator makes a configuration change.
Original PR description
Steps to reproduce: - Go to the /blog page - See that some posts use some tags - Go to Configuration > Tags - Change the color of an existing tag - Go back to the /blog page => The color of the tag is not updated for existing posts using it. This is a t-cache issue, which unfortunately is difficult to fix in stable (as it would require modifying multiple nodes in qweb). As a workaround, and knowing that the t-cache system was fully removed in 19.0 at [1], this fixes the bug with a hack: on tag update, make a dummy update to the related blog posts already using it. Tag updates should be quite rare anyway. [1]: https://github.com/odoo/odoo/commit/1cf06a5688e6aa80175d5a28a83b639d0eb925a7 task-4045724
A database query in the timesheet attendance reporting area was corrected so it can properly identify employees during processing. This prevents certain upgrade requests from failing due to a mismatched employee reference.
Original PR description
In the affected query, the variable "employee_id" is undefined in the scope where it is used. This leads postgres to interpret it as a variable with default type VARCHAR and to the impossibility to compare it against an integer. We just qualify the variable name so it now works as expected. Failing upgrade requests: [3103245](https://upgrade.odoo.com/odoo/request/3103245) [3121291](https://upgrade.odoo.com/odoo/request/3121291) Fixes https://github.com/odoo/odoo/pull/192434/commits/c97ecfa7fc091f763329af589b69db2292931163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225401
Closed self-order point-of-sale sessions now remove their temporary database sequence after use. This helps prevent unnecessary database clutter over time, improving maintainability without changing the cashier or customer experience.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223758
Creating a salesperson from a CRM opportunity no longer copies phone details from the related lead by mistake. This prevents incorrect contact information on salesperson records and reduces manual cleanup for sales teams.
Original PR description
To reproduce: ============= 1- add a lead 2- add a phone and a mobile number 3- convert it to opportunity 4- create salesperson from that view 5- salesperson contains lead number Problem: ========= Before this fix, creating a Salesperson inherited the global context, which included unrelated values as active_model was set to crm.lead. This led to incorrect default values being applied. https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/web/models/models.py#L872C13-L872C21 The default values contained the lead phone and lead number and was applied in the creation of salesperson. Solution: ========== Since we have some synchronization of some fields (email, phone) that is automatically done normally, it's reasonable to remove the code and see what it gives. opw-4871069
This fixes a visual flicker in the website editor preview after changing page styling such as boxed layout or background color. The preview now keeps styling consistent during reloads, giving users a smoother and less distracting editing experience.
Original PR description
In this [commit], fallback iframe was added to avoid flickering between iframe reloads. But the flicker still happens if we change page's style, since we do not apply the new styles to the fallback iframe. To reproduce the issue: - Open Website and start editing - Move to the 'Theme' tab - Change page layout to 'Boxed' - Set background color to a non-transparent color, e.g. red - Save, and do any action to reload the iframe, e.g. go to /contactus => The iframe flickers from the previous color to red, which shouldn't be the case. Task-4985472 [commit]: https://github.com/odoo/odoo/commit/7b19831e1c624b483008feb526ba773ec8b23009
A test for selling product kits was updated so it matches the intended setup for invoicing before delivery. This helps keep the sales and manufacturing workflow reliable by ensuring automated checks reflect ordered-quantity invoicing rules.
Original PR description
This change updates the test_sell_kit_invoice_before_delivery test to ensure that kit components and the kit product itself use an invoicing policy of Ordered Quantities rather than the default Delivered Quantities. build_error-232796
Changing a quotation template on a sales order now removes the previously linked quote calculator spreadsheet. This prevents users from seeing calculations from an old template and keeps the sales order aligned with the selected template.
Original PR description
Step to reproduce: - Create a new SO - Add a customer and quotation template to the order - Click on quote calculator smart button - Return to sale order (click on SO number in top left) - Change the quotation template - Result: it does not change the quote calculator that is linked to the new quotation template Cause: - Clicking on Quote Calculator creates a copy of the quotation template spreadsheet and links it to the SO. https://github.com/odoo/enterprise/blob/8bc6098335d283e6d210dc788463a8ef8c559b14/spreadsheet_sale_management/models/sale_order.py#L30-L35 - When the quotation template is later changed, the spreadsheet linked to the old template remains attached to the SO. Fix: - On changing the sale_order_template, the old spreadsheet should be unlinked from the SO. - Keeping it linked is inconsistent, as it does not matches the current template opw-4998587
Event registration confirmation emails now keep QR codes at the correct size and shape, even after the email template is edited and previewed. This prevents distorted QR codes and helps attendees reliably scan their registration details.
Original PR description
### Steps to reproduce: 1. Set up an event registration with atleast 1 attendee. 2. Go to email templates and search for "Event: Registration Confirmation". (or any with QR code in it) 3. Check the preview of the email template. 4. Edit any text inside the template and check the Preview again. (QR code stop taking the proper height) ### Issue: During the rendering of the email template, the QR code image html is changing provoking the QR to not have the proper aspect ratio and look stretched. ### Fix: We can make sure we're always taking the 100% height of the container by adding a style attribute to the image tag, thus not losing the aspect ratio of the QR code. opw-4976893
This fixes a problem where reinstalling the Danish Nemhandel module could leave it broken. Businesses using Danish electronic invoicing can reinstall or recover the module more reliably without disrupting related workflows.
Original PR description
**Description of the issue/feature this PR addresses:** Reinstalling the module breaks it. 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 adds checks to ensure India GSTR-1 reporting handles sales under reverse charge and SEZ sales with LUT correctly. It helps reduce compliance reporting risk by validating these specific tax scenarios before they affect business filings.
Original PR description
Adding GSTR1 test case with RCM tax and SEZ (with LUT) see https://github.com/odoo/odoo/pull/213931
Greek customer VAT numbers that start with “EL” are now treated as Greece for validation and exports. This prevents missing country information in accounting export files such as DATEV customer account exports.
Original PR description
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer…
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer from Greece with VAT number EL033910442 2. Create an invoice for that customer 3. Navigate to Accounting > Reporting > General Ledger 4. Download Datev Data through the gear icon 5. Open EXTF_Customer_accounts.csv 6. Notice that EL was not recognised as the country code **Root Cause** The VAT validation logic `simple_vat_check` first tries to find a country-specific check function `check_vat_EL`, but such a function does not exist. For Greece, the correct function is `check_vat_GR` (since the ISO country code is `GR`). When `EL` is passed directly, no check function is found, validation fails, and the VAT country is left empty. **Fix** Normalize the VAT prefix before validation by mapping EL → GR, ensuring Greek VAT numbers prefixed with EL are validated with the existing check_vat_GR logic. Opw-4982164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
6 changes
Resolved issues and error corrections
The Spanish Mod 349 tax report now correctly shows the underlying invoice lines when users audit the summary for intra-community operations. This helps accounting teams verify reported EU transaction amounts without missing supporting details.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813
Website product pages now show the correct price when a customer's tax rules change how taxes are applied. This prevents small rounding errors, such as a $10 item appearing as $10.01, improving price accuracy for shoppers.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Configure website to display prices tax-included; 2. have two 15% taxes, one price-included, one price-excluded; 3. create a $10 product that uses the price-included tax; 4. create a fiscal position that maps the included tax to excluded one; 5. assign the fiscal position to the public partner; 6. open the product's shop page as public user. Issue ----- The price gets displayed as $10.01. Cause ----- When applying the taxes to the price, small errors are introduced by rounding the base price before doing the tax calculations. Solution -------- To circumvent issues like these, commits 143ec3739196f and 6045061f818a0 added the `round` & `round_base` context values respectively. By settings these to `False`, we can prevent intermediate rounding that may introduce errors like these. opw-4945752
A timesheet attendance report query now correctly identifies the employee field it needs to use. This prevents database comparison errors that could block affected Odoo upgrade requests.
Original PR description
In the affected query, the variable "employee_id" is undefined in the scope where it is used. This leads postgres to interpret it as a variable with default type VARCHAR and to the impossibility to compare it against an integer. We just qualify the variable name so it now works as expected. Failing upgrade requests: [3103245](https://upgrade.odoo.com/odoo/request/3103245) [3121291](https://upgrade.odoo.com/odoo/request/3121291) Fixes https://github.com/odoo/odoo/pull/192434/commits/c97ecfa7fc091f763329af589b69db2292931163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225401
Sales orders now ignore archived projects when deciding whether to show the project shortcut button. This prevents users from seeing a project indicator when only inactive projects are linked, reducing confusion in order follow-up.
Original PR description
Issue: ----- When a project is archived, the project stat button still appears on the sale order. Fix: --------- This commit excludes archived projects from the project count. As a result, the project stat button will be hidden when only archived projects are linked. Steps to reproduce: -------- - Install sale_project module - Create a product with service type, linked to a project and task - Create a sale order with the above product and confirm it - Archive the linked project - Return to the sale order and check the project stat button task-4780817
Payment terminal messages printed at the bottom of POS receipts now use the correct font sizing. This makes the text easier to read on printed receipts and keeps it consistent with the on-screen preview.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project task lists now keep the allocated hours field visible and editable even when its value is zero. This makes it easier for users to update multiple task allocations without being blocked by hidden cells.
Original PR description
Before this commit, when the user would like to edit the allocated hours field of multiple tasks inside the list view, he cannot when the allocated hours is equal to 0. The reason is because the cell is hidden once the value is equal to 0. This commit makes that field is always editable in the list view of tasks even if the value is 0. task-5093288