Daily updates from Odoo
Tuesday, May 13, 2025
28 changes · master
Resolved issues and error corrections
This update keeps spreadsheet-related features working smoothly after an underlying spreadsheet component change. It also makes chart options available where dashboards need them, improving consistency across spreadsheet and dashboard experiences.
This update improves the reliability of bank reconciliation screens by using stable record identifiers instead of list positions. This helps prevent incorrect button or line handling after platform changes removed the previous position-based reference.
Original PR description
This commit will fix multiple occurrence of using id instead of index because since 18.4, the index is not there anymore no task id
Manually edited appointment booking links that are missing required details no longer cause a system error. Instead, users are shown a standard page-not-found response, keeping the booking experience more stable and avoiding unnecessary error reports.
Original PR description
The system fails to trigger the appointment booking form due to missing required parameters (`date_time` and `duration`) Steps to Produce: 1. Created a DB with demo data and installed an appointment. 2. Open `Appointments`. 3. Click the Action button of the dental care appointment and generate and copy the share link. 4. Open copied link and click on an available time slot. 5. On the next view manually remove everything after the info in url. 6. Error occurs. Error: `TypeError : AppointmentController.appointment_type_id_form() missing 2 required positional arguments: 'date_time' and 'duration'` Solution: Updated the `appointment_type_id_form()` method by setting default values to `None`: - If `date_time` or `duration` is missing, the system won't crash with a `TypeError`. - Now it gives `404` page not found. Sentry - 4952598215
Code cleanup and technical improvements
This update reorganizes internal stock-related tests so they use a dedicated warehouse and related resources instead of shared defaults. This should make future logistics testing more consistent and reliable, with no direct change expected for end users.
Original PR description
The end goal of Logistics tests refactoring is to use dedicated resources (companies, users, warehouses etc.) in all stock tests. This is part 1 of these changes, focusing on a dedicated warehouse, but also introducting some small improvements. After this PR is merged, we will: * use a dedicated warehouse in all stock tests * use locations, picking types, routes etc. associated with that warehouse, instead of global ones * consistently use test resources naming convention: * StockLocationObj -> the Odoo Model * stock_location -> a specific instance * stock_location.id -> the ID of that instance * use Command class instead of command triple * fix a few typos Please note that not all tests in stock module (and related ones) have been updated. The main reason is that not all of stock tests inherit from TestStockCommon. This will be changed in the future.
Miscellaneous changes
This commit address keyerror `default_pricelist` which is already defined in superclass but not used in the test case. and This commit fixes a `Field error` in the `test_postpaid_next_invoice_date` test case in the `sale_subscription` module. The error was caused by referencing an invalid field name (`tax_id`) on the `sale.order.line` model during the creation of a sale order. The correct field name, `tax_ids`, has been used instead. build_error-181599 Forward-Port-Of: odoo/enterprise#84
Original PR description
This commit address keyerror `default_pricelist` which is already defined in superclass but not used in the test case. and This commit fixes a `Field error` in the `test_postpaid_next_invoice_date` test case in the `sale_subscription` module. The error was caused by referencing an invalid field name (`tax_id`) on the `sale.order.line` model during the creation of a sale order. The correct field name, `tax_ids`, has been used instead. build_error-181599 Forward-Port-Of: odoo/enterprise#84016
It is possible that a employee won't have a contract (maybe a freelancer) nor a user related. In such case when asked to sign a document, the document cannot be signed. It is possible to reproduce this behaviour on runbot https://www.awesomescreenshot.com/video/39482670?key=9eed08257cc76b5749c1c8c0dda62377 This commit aims to set a user, since the user cannot be false. I believe that since one of the options would be set it to the manager of the contract the employee is under, it would be a
Original PR description
It is possible that a employee won't have a contract (maybe a freelancer) nor a user related. In such case when asked to sign a document, the document cannot be signed. It is possible to reproduce this behaviour on runbot https://www.awesomescreenshot.com/video/39482670?key=9eed08257cc76b5749c1c8c0dda62377 This commit aims to set a user, since the user cannot be false. I believe that since one of the options would be set it to the manager of the contract the employee is under, it would be a valid option considering that the employee has no contract, to set it to whoever sent the request, in this case, the request create_uid opw-4750010 Forward-Port-Of: odoo/enterprise#84923 Forward-Port-Of: odoo/enterprise#84711
A confirmation dialog is now displayed when validating an order that has unsent changes, prompting the user to send it before proceeding with payment. community PR: https://github.com/odoo/odoo/pull/204691 task-id: 4687464 Forward-Port-Of: odoo/enterprise#84302
Original PR description
A confirmation dialog is now displayed when validating an order that has unsent changes, prompting the user to send it before proceeding with payment. community PR: https://github.com/odoo/odoo/pull/204691 task-id: 4687464 Forward-Port-Of: odoo/enterprise#84302
The feature is not implemented yet. Don't show buttons that aren't mapped to anything. Forward-Port-Of: odoo/enterprise#85155
Original PR description
The feature is not implemented yet. Don't show buttons that aren't mapped to anything. Forward-Port-Of: odoo/enterprise#85155
This commit contains 2 small changes: - The 'No subscription linked to your IoT Box' notification warning has been limited to trigger at most once every 5 minutes, as before it was spamming the user with repeat notifications. - The title of the PoS autoconfigure popup upon connecting a new IoT box has been changed to 'Connect to a Point of Sale'. task-4787508 Forward-Port-Of: odoo/enterprise#85302
Original PR description
This commit contains 2 small changes: - The 'No subscription linked to your IoT Box' notification warning has been limited to trigger at most once every 5 minutes, as before it was spamming the user with repeat notifications. - The title of the PoS autoconfigure popup upon connecting a new IoT box has been changed to 'Connect to a Point of Sale'. task-4787508 Forward-Port-Of: odoo/enterprise#85302
Forward-Port-Of: odoo/enterprise#84899
Original PR description
Forward-Port-Of: odoo/enterprise#84899
This commit adds, removes and modifies demo data in order to better display the new features of the accounting app. --- task-4749800 Forward-Port-Of: odoo/enterprise#84621
Original PR description
This commit adds, removes and modifies demo data in order to better display the new features of the accounting app. --- task-4749800 Forward-Port-Of: odoo/enterprise#84621
Before this commit, when doing a bank synchronization the active id was the id of the wizard for selecting an account. So the amount on the global summary were wrong no task id Forward-Port-Of: odoo/enterprise#85280
Original PR description
Before this commit, when doing a bank synchronization the active id was the id of the wizard for selecting an account. So the amount on the global summary were wrong no task id Forward-Port-Of: odoo/enterprise#85280
Since this commit: https://github.com/odoo/odoo/commit/d29af194d49dc35b9273712bc9158b05927a378e They changed the preferred internal group for a preferred account type. Also correcting a type in the name of a filter no task-id Forward-Port-Of: odoo/enterprise#85253
Original PR description
Since this commit: https://github.com/odoo/odoo/commit/d29af194d49dc35b9273712bc9158b05927a378e They changed the preferred internal group for a preferred account type. Also correcting a type in the name of a filter no task-id Forward-Port-Of: odoo/enterprise#85253
`hr.dep_rd` is demo data, it's not available anymore during tests in the default configuration. So replace it by creating a department on the fly. And remove the resolution of `employee_al` which is also demo data *and* seems unused. While at it, nuke a bunch of instance variables which don't seem used outside of `setUp`. https://runbot.odoo.com/odoo/error/161648 Forward-Port-Of: odoo/enterprise#84251
Original PR description
`hr.dep_rd` is demo data, it's not available anymore during tests in the default configuration. So replace it by creating a department on the fly. And remove the resolution of `employee_al` which is also demo data *and* seems unused. While at it, nuke a bunch of instance variables which don't seem used outside of `setUp`. https://runbot.odoo.com/odoo/error/161648 Forward-Port-Of: odoo/enterprise#84251
Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.). To works, this domain needs dynamic elements, such as `context_today`, which is defined in `py_builtin.js` and dynamically retrieves the current date. https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py
Original PR description
Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic…
Similar to: https://github.com/odoo/odoo/pull/184830
We've recently introduced a new operator: “is within” in the domain
selector, which can be used to find out whether a date is within a
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.
https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py_builtin.js#L77-L79
However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s
In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:
`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.
The community commit (https://github.com/odoo/odoo/pull/204172) handles:
- website/model_page.py:
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L13-L18
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L47-L50
This commit
handles two other cases:
- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2
- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`
In all three cases, the problem is the same: the problem is not only
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:
- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in the python server
- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)
- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`
- For the moment, the values we use are the same as those used by
`is_within`, i.e.:
- context_today()
- relative_delta()
- datetime
- time
opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091
community: https://github.com/odoo/odoo/pull/204172
Forward-Port-Of: odoo/enterprise#84203
Forward-Port-Of: odoo/enterprise#82564Steps to reproduce: - Setup an employee with identification_id, and l10n_hk_given_name - Leave l10n_hk_mpf_manulife_account and l10n_hk_surname empty - Generate Manulife MPF report with any payslips Current behavior: - Error raised Expected behavior: - Should be able to generate the report Forward-Port-Of: odoo/enterprise#85113
Original PR description
Steps to reproduce: - Setup an employee with identification_id, and l10n_hk_given_name - Leave l10n_hk_mpf_manulife_account and l10n_hk_surname empty - Generate Manulife MPF report with any payslips Current behavior: - Error raised Expected behavior: - Should be able to generate the report Forward-Port-Of: odoo/enterprise#85113
Problem: In a multi-company environment with multiple companies from India, users are getting access right errors about being unable to read employees from Company B when viewing the Salary Register from Company A and vice versa. Steps to Reproduce on Runbot: 1. Install accounting,employee, payroll, India payroll 2. Create 2 Indian companies with India fiscal package 3. Create an employee per company and create payslips per employee and pay them 4. View the salary register in Payroll > Re
Original PR description
Problem: In a multi-company environment with multiple companies from India, users are getting access right errors about being unable to read employees from Company B when viewing the Salary Register from Company A and vice versa. Steps to Reproduce on Runbot: 1. Install accounting,employee, payroll, India payroll 2. Create 2 Indian companies with India fiscal package 3. Create an employee per company and create payslips per employee and pay them 4. View the salary register in Payroll > Reporting --> access right error thrown opw-4677551 Forward-Port-Of: odoo/enterprise#85241 Forward-Port-Of: odoo/enterprise#83199
Before this commit, due to a cleaning of sale order views, the `planning_first_sale_line_id` and `planning_initial_date` has been removed from the sale order form view but those fields have to be loaded in the form view to be used as default values when the user clicks on `Planned\n x Hours` stat button, otherwise a traceback will be occurred. This commit introduces again those fields in the sale order form view to be sure those fields are defined and used as default value for the `Planned\n
Original PR description
Before this commit, due to a cleaning of sale order views, the `planning_first_sale_line_id` and `planning_initial_date` has been removed from the sale order form view but those fields have to be…
Before this commit, due to a cleaning of sale order views, the `planning_first_sale_line_id` and `planning_initial_date` has been removed from the sale order form view but those fields have to be loaded in the form view to be used as default values when the user clicks on `Planned\n x Hours` stat button, otherwise a traceback will be occurred. This commit introduces again those fields in the sale order form view to be sure those fields are defined and used as default value for the `Planned\n x Hours` stat button. Steps to reproduce ------------------ 0. Install sale_planning module 1. Go to Sales app 2. Create a quotation with a product in which slots will be generated 3. Confirm the quotation 4. Click on `Planned\n x Hours` stat button Current behavior ---------------- A traceback is occurred because `planning_first_sale_line_id` and `planning_initial_date` fields are not defined in the form view. Expected behavior ----------------- The action of the stat button should be executed without any issue. task-4781696 Forward-Port-Of: odoo/enterprise#85231
When updating a parent product, the MPS view will load ALL the components on the page even if it breaks the pager limit. Previously, there was a refresh at every change. It was annoying so it was removed. However this refresh made sure to reduce the number of records shown to the pager limit. The solution is to simply slice the received array of lines to the n first records, n being the value of `this.env.config.limit`. opw-4778588 Forward-Port-Of: odoo/enterprise#85159
Original PR description
When updating a parent product, the MPS view will load ALL the components on the page even if it breaks the pager limit. Previously, there was a refresh at every change. It was annoying so it was removed. However this refresh made sure to reduce the number of records shown to the pager limit. The solution is to simply slice the received array of lines to the n first records, n being the value of `this.env.config.limit`. opw-4778588 Forward-Port-Of: odoo/enterprise#85159
- review the onboarding image & annotations - review the start button to avoid double primary - worksheet instruction dialog uses default dialog header - removed the lock operator styling follow-up task-4346172 Forward-Port-Of: odoo/enterprise#83515
Original PR description
- review the onboarding image & annotations - review the start button to avoid double primary - worksheet instruction dialog uses default dialog header - removed the lock operator styling follow-up task-4346172 Forward-Port-Of: odoo/enterprise#83515
Forward-Port-Of: odoo/enterprise#84419
Original PR description
Forward-Port-Of: odoo/enterprise#84419
The mx payment method on a payment should be the one from the pos payment method. Steps: - Have a PoS payment method with `l10n_mx_edi_payment_method_id` != `payment_method_transferencia` - Open a PoS session, make an order with this payment method and close the session - Look for the related payment --> `l10n_mx_edi_payment_method_id` == `payment_method_transferencia` With this commit, we override the compute to get the payment way from the pos payment method. opw-4699064 Forward-Port-
Original PR description
The mx payment method on a payment should be the one from the pos payment method. Steps: - Have a PoS payment method with `l10n_mx_edi_payment_method_id` != `payment_method_transferencia` - Open a PoS session, make an order with this payment method and close the session - Look for the related payment --> `l10n_mx_edi_payment_method_id` == `payment_method_transferencia` With this commit, we override the compute to get the payment way from the pos payment method. opw-4699064 Forward-Port-Of: odoo/enterprise#85043 Forward-Port-Of: odoo/enterprise#83323
This update is done without an upgrade because the old format will still work. But for cleanliness, templates should reflect what the editor will actually do, and since [This commit], files are `span` elements, not `div` anymore, and they are wrapped in a baseContainer (`div` or `p`). [This commit]: https://github.com/odoo/odoo/commit/96c8c398c0fbef519b56edf4941691d11372eac0 task-4745902 Forward-Port-Of: odoo/enterprise#83899
Original PR description
This update is done without an upgrade because the old format will still work. But for cleanliness, templates should reflect what the editor will actually do, and since [This commit], files are `span` elements, not `div` anymore, and they are wrapped in a baseContainer (`div` or `p`). [This commit]: https://github.com/odoo/odoo/commit/96c8c398c0fbef519b56edf4941691d11372eac0 task-4745902 Forward-Port-Of: odoo/enterprise#83899
[This commit] modified the `ir.filters` `user_id` field into `user_ids`. In Knowledge embedded views (and links), the `SearchModel` state and some custom favorite filters are stored inside a html attribute of the body of an article, therefore they are not properly upgraded with the standard python script. This commit introduces a JS upgrade script to modify these values. `user_id` is converted to `user_ids` with an empty array as a value (which means that the filters are always "shared
Original PR description
[This commit] modified the `ir.filters` `user_id` field into `user_ids`. In Knowledge embedded views (and links), the `SearchModel` state and some custom favorite filters are stored inside a html attribute of the body of an article, therefore they are not properly upgraded with the standard python script. This commit introduces a JS upgrade script to modify these values. `user_id` is converted to `user_ids` with an empty array as a value (which means that the filters are always "shared with everyone"). The field has to be modified both in the custom favorites and in the stored `SearchModel` state. [This commit]: https://github.com/odoo/odoo/commit/414e55cf7c3971a7ba0a7c96855db4c23e77a5c4 task-4718129 Forward-Port-Of: odoo/enterprise#83612
This commit fixes the issue where the WhatsApp account was from another company and the related channel was not being read correctly. Adding a test to ensure that the WhatsApp account is read correctly even when the account is from another company. task-4775511 Forward-Port-Of: odoo/enterprise#84860
Original PR description
This commit fixes the issue where the WhatsApp account was from another company and the related channel was not being read correctly. Adding a test to ensure that the WhatsApp account is read correctly even when the account is from another company. task-4775511 Forward-Port-Of: odoo/enterprise#84860
Expand ligatures (IJ, œ, æ...) to their constituent letters, so that they can be converted to T9. Forward-Port-Of: odoo/enterprise#85115
Original PR description
Expand ligatures (IJ, œ, æ...) to their constituent letters, so that they can be converted to T9. Forward-Port-Of: odoo/enterprise#85115
Before this commit, when the user is in `Timesheets > To Validate > All Timesheets` and group by `Sale Order Item`, a traceback is occurred because no fields are given for the group by of web_read_group made on `planning.slot`, the reason is because we just check if `project_id` and/or `employee_id` are used in row fields or section field of the grid view of timesheets to add additional data based on planning.slot in the same period of the grid view. This commit avoids calling the web_read_gr
Original PR description
Before this commit, when the user is in `Timesheets > To Validate > All Timesheets` and group by `Sale Order Item`, a traceback is occurred because no fields are given for the group by of…
Before this commit, when the user is in `Timesheets > To Validate > All Timesheets` and group by `Sale Order Item`, a traceback is occurred because no fields are given for the group by of web_read_group made on `planning.slot`, the reason is because we just check if `project_id` and/or `employee_id` are used in row fields or section field of the grid view of timesheets to add additional data based on planning.slot in the same period of the grid view. This commit avoids calling the web_read_group on planning.slot model when no rows managed are found in the grid view since the result of the web_read_group will be useless in that case. Steps to reproduce ------------------ 0. Install `project_timesheet_forecast` module 1. Go to `Timesheets > To Validate > All Timesheets` 2. Go to the grid view 3. Group by `Sale Order Item` Expected behavior ----------------- The grid view should be loaded without any issue and show the so_line field as row. Current behavior ---------------- A traceback is occurred inside the web_read_group on planning.slot model. task-4782077 Forward-Port-Of: odoo/enterprise#85022
Before the commit: On a return which passed all checks in 'new' state, when we clicked the dots then click review all checks. It would open the checks view with all the checks green then instantly redirect to the return view. It would also automatically forward to the next state. This is because there is a call to refresh the checks on the page load of the checks view. During this page load, a call to try_forward_state was triggered even if we didn't want to change state. Now, when we op
Original PR description
Before the commit: On a return which passed all checks in 'new' state, when we clicked the dots then click review all checks. It would open the checks view with all the checks green then instantly redirect to the return view. It would also automatically forward to the next state. This is because there is a call to refresh the checks on the page load of the checks view. During this page load, a call to try_forward_state was triggered even if we didn't want to change state. Now, when we open the view from the button 'review all checks', we would not allow changing automatically to the next state. The only way is via the 'Review Checks' main button. Forward-Port-Of: odoo/enterprise#84755