Daily updates from Odoo
Navigate
Branch
Tuesday, May 13, 2025
43 changes
31 changes
Enhancements to existing features
Users now see a clear option to reset filters when a view has no matching records, helping them recover faster from empty search results. Empty screens that rely on sample data also display a banner so users better understand that the data shown is illustrative.
Original PR description
task-4648766 odoo PR https://github.com/odoo/odoo/pull/208864 enterprise PR https://github.com/odoo/enterprise/pull/85388
AI agents are now linked more directly to their persona records, making related chat interactions faster and easier to maintain. The opening message in AI agent conversations can also use the agent's subtitle, creating a clearer first impression for users.
Original PR description
First commit refactors how ai.agent records are accessed from Persona(res.partner) to improve performance and code clarity. Currently, an orm.searchRead() call was necessary to fetch the corresponding ai.agent for a Persona. This commit also adds helper function `isAgent()` to the Persona model. Second commit is my change proposal for start message of a chat with AI agent. Let me know how you think about this! <img width="1357" alt="image" src="https://github.com/user-attachments/assets/48955c4b-529a-44f0-b1e0-748b9c2de9ce" />
Updates Romanian electronic invoicing to better synchronize with ANAF, Romania's tax authority. This helps businesses keep invoice exchange and compliance workflows aligned with official systems.
Original PR description
WIP task-4588800 related : https://github.com/odoo/odoo/pull/205141
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
12 changes
Enhancements to existing features
The appraisal template wording was revised to correct translation-related phrasing issues. This helps employees and managers see clearer, more accurate appraisal content in the HR app.
Original PR description
Edited the template wording to fix some incorrect translations task number: 4791321
Resolved issues and error corrections
Users can once again insert cells in spreadsheet pivot tables after a previous change removed that option. This restores expected spreadsheet behavior and helps users adjust pivot-based reports without workarounds.
Original PR description
This commit reverts the commit c4a481aa5fd4c4168e2ec0252bca46ac95cf1a67 which removed the ability to insert cells in pivot tables. Task: 4707732
The Documents app no longer applies an extra spacing workaround in its toolbar area. This keeps the layout aligned with the corrected shared interface behavior, reducing the chance of uneven spacing for users.
Original PR description
requires: https://github.com/odoo/odoo/pull/207461 --- This commit removes an obsolete padding on .o_control_panel_actions class in the `documents` module. The layout issue it was compensating for has now been properly addressed in the `web` module by applying the correct gap-* classes correctly on the control panel’s main div. task-4568501
Posting Kenyan OSCU credit notes no longer fails when a newly created, unposted credit note has not yet received its final document number. This helps users complete credit note workflows reliably without unexpected system errors.
Original PR description
**[FIX] l10_ke_edi_oscu: Handle None name of fresh unposted credit notes.** To reproduce the issue: - Create an invoice with some lines - Create the first credit note and change the product set on one of the lines or its quantity to trigger the fix piece of the code (do not confirm the credit note) - Create another credit note and try to post it -> Traceback The issue is caused by the fact that newly created moves generally have `None` in the `name` field, which is only populated after posting. This fix resolve this by replacing the string shown when the name field is None. opw-4779976
Fixed an issue where German DATEV exports could show outdated amounts for journal entries after debit or credit values were changed. This helps ensure exported accounting files match the posted accounting data and reduces reconciliation errors.
Original PR description
<b>Steps to produce :</b> 1) Install 10n_de_reports and switch to the German company 2) Create a journal entry from accounting with a credit and debit 3) Now update the credit and debit to a…
<b>Steps to produce :</b> 1) Install 10n_de_reports and switch to the German company 2) Create a journal entry from accounting with a credit and debit 3) Now update the credit and debit to a different value. 4) Post the journal 5) Go to "Accounting / Reporting / Audit Reports / General Ledger" 6) Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" <b>Issue:</b> The line for the created journal entry has a price_total of the previous balance even after updating the credit and debit values. <b>Cause:</b> When the user updates the 'debit' and 'credit' values for an `aml`, The `price_totals` value remains unchanged as it is not dependent on `balance`. So, it will show the previous value in the report line because we are taking the abs(aml.price_total) from the report data. <b>Solution:</b> We can add an extra check of the move type so that it will fall back to the else block, where the line_amount will take a value by calculating taxes from `aml.tax_ids.compute_all`. opw-4707567
Customer follow-ups now calculate due and overdue totals correctly when vendor payables are also present. This prevents vendor bill attachments or payable amounts from incorrectly affecting customer follow-up processing.
Original PR description
Since f82f9ab7b0351d0c1239c4cafa772bea8c17c6ff, the unreconciled aml domain includes payable accounts, which leads to issue when processing followup. Since we need to get the total value including payable accounts, we add `account_id` to the group by, this way we can conditionnally set the computed values regarding the type of account, but also get the total due/overdue amounts, by adding two computed fields. Steps to reproduce new issue: - create a vendor bill for Demo (Joel Willis), with due date 15 days ago - confirm the bill, print the PDF and attach it to the bill (as if we received it from the vendor) - now open the follow-up wizard from the partner form, and notice that the Vendor bill is attached opw-4664402
The Trial Balance report now calculates end balances correctly when users group results by an analytic plan. This prevents totals from being counted twice, giving finance teams more reliable reporting when using analytic accounting.
Original PR description
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic distribution - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Activate "Analytic Group By" in the settings of the report - Add the plan used in the analytic distribution in "Analytic" group option **Issue:** In the "End Balance" column, all the amounts are summed in the total column instead of being grouped by analytic plan. It results on a total amount being twice what it should be as the total column of each period is also included in the sum. This is a complement to previous fix for the grouping by analytic account where the analytic plan groupby case was forgotten: https://github.com/odoo/enterprise/commit/05bbab713c749b7d7450d5dbaf2eda1ba4f68712 opw-4648009
Mexican electronic invoice views now correctly show the supplier RFC when that field is added to invoice lists or forms. This fixes a display issue caused by reading a placeholder instead of the actual invoice attachment data.
Original PR description
Before this patch, adding `l10n_mx_edi_cfdi_supplier_rfc` (or any other field filled by `_fill_from_cfdi_values`) to a tree/form view showed the field empty.
Root cause
----------
`_fill_from_cfdi_values()` decoded the CFDI using `attachment.raw` with `bin_size=True` still in the context, so the ORM returned the placeholder `b'59.00 bytes'`. As a result,
`_decode_cfdi_attachment()` got an empty payload and returned `{}`.
Fix
---
Reload the attachment without the `bin_size` flag
The Philippine SLSP reports now refresh correctly when users change key inclusion filters, and the displayed active filter names stay accurate. Totals and exported amounts are also corrected, improving confidence in tax report review and submission outputs.
Original PR description
Fixed the following issues in the SLSP reports: - When filters "Including Partners Without TIN" and "Including Importations" are updated, the lines are not refreshed - When the filters above are updated, the name of the current active filters are not refreshed - When "Including Partners Without TIN" is enabled, the grand total does not consider lines from those partners - When exported, amounts from the previous row are carried forward to the current row, if the current row has no value for that amount 4748216
Users can now customize the Documents spreadsheet kanban view in Studio without triggering an error when changing sorting options. This keeps document-related views editable for configuration teams and avoids interruptions during setup.
Original PR description
Steps:
- install `web_studio` and `documents_spreadsheet`
- open documents
- open studio on the spreadsheet kanban view (the default one)
- change sort by field to "created on" field
- error
This commit replaces encodeURIComponent with window.encodeURIComponent,
because owl won't try to evaluate this variable via the context.
And so the fix
```js
get renderingContext() {
const context = super.renderingContext;
context.encodeURIComponent = encodeURIComponent;
...
}
```
In `DocumentsKanbanRecord` is no longer necessary.
The error occurred because `encodeURIComponent` was not found in the context object.
The reason this fix doesn't work with studio is the view is defined as
```xml
<kanban js_class="documents_kanban"/>
```
and studio does not load view js classes.
And since the fix is in `documents_kanban`, it's not taken into account. opw-4744886This fix stops users from creating an incomplete private key entry while configuring Argentine invoicing. It prevents an error during renewal request generation and helps companies complete their tax configuration more reliably.
Original PR description
The system failed to retrieve `company.l10n_ar_afip_ws_key_id.pem_key` because of quick create. Steps to Reproduce: 1. Switch to `(AR) Exento Company`. 2. Navigate to `Settings `> `Invoicing`. 3. Search for `Argentinean Localization`. 4. In `Primary Key`, clear the field, enter any value, and click Create. 5. Click `Generate Renewal Request`. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'bool'` Solution: Add `no_quick_create : True` for l10n_ar_afip_ws_key_id field. Sentry - 5999498377
Miscellaneous changes
### Before this PR If the backorder is "always", on the shopfloor when clicking "close production" on the "production overview", it redirects to the backend ### After this PR Clicking on close production it does not redirect to backend Forward-Port-Of: odoo/enterprise#83087 Forward-Port-Of: odoo/enterprise#79918
Original PR description
### Before this PR If the backorder is "always", on the shopfloor when clicking "close production" on the "production overview", it redirects to the backend ### After this PR Clicking on close production it does not redirect to backend Forward-Port-Of: odoo/enterprise#83087 Forward-Port-Of: odoo/enterprise#79918