Daily updates from Odoo
Monday, November 20, 2023
19 changes
1 change
Resolved issues and error corrections
Helpdesk screens now better handle long team member names and avoid a brief resizing issue in the email composer. Ticket graph views are also organized more clearly, making it easier to compare work by team, stage, and assignee.
Original PR description
## Specs - Helpdesk.team Form View > team members name is overflowing - Helpdesk.ticket form view > coupon > generate coupon > send > send > the mail composer quickly resizes before closing - Changed…
## Specs - Helpdesk.team Form View > team members name is overflowing - Helpdesk.ticket form view > coupon > generate coupon > send > send > the mail composer quickly resizes before closing - Changed the helpdesk.tickets graph views with the following logic: - when viewing the tickets of a single team, group the graph view by stage > assignee - when viewing the tickets of multiple teams, group the graph view by team > stage ### In term of implementation: Modified helpdesk_ticket_view_graph_all_ticket view to group it by team > stage actions action_main_my_graph, my_ticket_action_no_create_graph, helpdesk_ticket_action_sla, helpdesk_action_success, helpdesk_ticket_action_7days_success now use views that inherits the same view as all_tickets created new links for actions helpdesk_ticket_action_main_my with every view_mode to avoid having the graphview display first when clicking on action same thing for helpdesk_my_ticket_action_no_create, helpdesk_ticket_action_sla, helpdesk_action_success, helpdesk_ticket_action_7days_success now linked helpdesk_my_ticket_action_no_create action to the helpdesk_ticket_view_graph_my_ticket view (no_create action is used by the my tickets dashboard buttons) Also: removed helpdesk_ticket_action_close_analysis_graph_inherit_dashboard renamed helpdesk_ticket_action_7dayssuccess_tree/kanban/activity/... these views weren't applying on the actions correctly. Removed them in upgrade script ~~https://github.com/odoo/odoo/pull/127993~~ https://github.com/odoo/upgrade/pull/5042 Task-3344837 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
18 changes
Resolved issues and error corrections
Fixed an issue where product information in approval requests was not displaying properly on mobile devices. Previously, only product IDs were shown. Now, a custom view displays product names and quantities clearly, making it easier for users to review approval requests on mobile devices.
Original PR description
Steps to reproduce: - Install approvals. - Go to the app and create a new approval like `Borrow Items`. - Now fill the form with atleast 1 product. - Go to mobile view of the same page and reload. - See the product Lines The issue is that since we don't have any kanban view specific for approvals, we will try to load a generic one which in this case will be only showing the id of the product. Creating a custom kanban view for this lines we can do a proper display like displaying the name of the product and the quantity. Before:  After:  opw-3449483 Forward-Port-Of: odoo/enterprise#49468
This fix resolves an issue where newly created models in Studio could not be edited after creation. When users created a new model and navigated to it, they would receive an error message stating the action is not editable. The problem was that the studio context key was missing when the menu for the new model was created, preventing Studio from recognizing it as an editable item.
Original PR description
Steps to reproduce ================== - Go to invoices - Open studio - Create a new model, validate, etc - Go to another menu - Click on the newly created menu `This action is not editable by Studio` Cause of the issue ================== The newly created menu was created without the studio context key https://github.com/odoo/enterprise/blob/8b5778206effa1f23707bf3eacb326efbec8473f/web_studio/static/src/client_action/editor/new_model_item/new_model_item.js#L24 See https://github.com/odoo/enterprise/pull/48640/commits/53c497f532fe6d94119a3ca54da88dddf26cf2b8 opw-3593825
Fixed an issue where downloading the accounts coverage report would cause an infinite loading spinner. The problem was corrected by changing how the system handles the download action, ensuring the file downloads properly instead of trying to replace the current page.
Original PR description
The aim of this commit is removing the infinite loader once you download the accounts coverage report on account.report. The problem was that we return an ir.actions.act_url with a target to "self". It means that this url should replace the current page by the url. This commit changes the target of the action to "download" according to the [documentation](https://www.odoo.com/documentation/17.0/developer/reference/backend/actions.html#url-actions-ir-actions-act-url). no task id
Fixed an issue that prevented financial reports containing boolean-type expressions (such as the Luxembourg annual tax report) from being printed to PDF. The system now properly converts boolean values to readable "Yes" and "No" text instead of causing a printing error.
Original PR description
When a report contained an expression using "boolean" figure_type (for example, the annual LU tax report), trying to print it to pdf raised an error when rendering the qweb template, since the formatted 'name' key for that column contained a value of type bool instead of str ; and the template tried to call len(bool) at some point. To fix that, we make it so that _format_value now directly returns 'Yes' and 'No'. The owl template of the report also needed to be fixed in order to use that value instead of hardcoding those two strings.
This fix prevents the Documents module from automatically creating duplicate partner records when receiving documents from unknown contacts. Previously, the system would create new partners for documents, which conflicted with accounting's VAT-based contact matching, causing duplicate entries. Now, only existing partners are linked to documents, keeping your contact database clean and accurate.
Original PR description
When receiving a document from an unknown contact, we no longer create a new partner. However, if the contact is known, we assign the already existing partner to the document. We remove that feature because it was creating duplicate partners for documents sent to accounting which uses VAT number as primary matching criterion. Contacts created in Documents were messing up with the ones associated with the VAT numbers. Task-3579869 Forward-Port-Of: odoo/enterprise#50379
This fix resolves issues in the Shop Floor module where manually updated quantities for raw materials and byproducts were not being correctly saved when marking items as picked. Additionally, clicking the button multiple times would incorrectly reduce the quantity to zero. This ensures accurate inventory tracking and prevents data loss during shop floor operations.
Original PR description
In Shop Floor, when you change the details of a raw material or a byproduct, the new quantity is not fully reflected on the move when you click to mark it as 'picked'. Moreover, clicking a second time make the move quantity falls to 0.
This update corrects the French balance sheet financial reporting by adding a missing accounting code (262) to the Participations section. This ensures that participation investments are properly captured in both gross and net value calculations, improving the accuracy of financial reports for French companies using Odoo.
Original PR description
Add code 262 in "brut" and "net" expressions of "Participations" section opw-3545765 Linked community PR: https://github.com/odoo/odoo/pull/142205 Forward-Port-Of: odoo/enterprise#50903 Forward-Port-Of: odoo/enterprise#50745
Fixed an issue where tax report activities were always assigned to the main administrator instead of the user configured in the activity type settings. Now when creating tax report activities, the system respects the default user assigned to the activity type, ensuring proper task delegation to the right team members.
Original PR description
Steps to reproduce: - Go to "Settings / Technical / Discuss / Activity Types" - Set a default user for "Tax Report" and "Tax Report Ready" (i.e. Marc Demo) - Go to "Accounting / Reporting / Audit Reports / Tax Report" - Click on "CLOSING ENTRY" button => A "Tax Report" activity is created on the closing entry for the main admin (i.e. Mitchell Admin). - Post the closing entry => A "Tax Report Ready" activity is created for the main admin too. In both cases, the default user configured on the activity type is ignored. Solution: Use the default user configured on the activity type and make sure that the user is part of the company and is in group "account.group_account_manager". opw-3496493 Forward-Port-Of: odoo/enterprise#50857 Forward-Port-Of: odoo/enterprise#49486
This fix resolves an issue where users with Accountant rights could not access uploaded Mexican CFDI invoices due to missing attachment permissions. When a CFDI invoice was uploaded, a second attachment was created without proper links to the invoice, preventing other users from viewing it. The fix ensures all attachments are properly linked so all authorized users can access uploaded invoices.
Original PR description
Steps to reproduce: - Install l10n_mx_edi - Use an user with Accountant rights in Accounting (e.g. Mitchell Admin) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Customers / Invoices" - Click on "Upload" button and upload a CFDI invoice - Connect with another user with Accountant rights in Accounting (e.g. Marc Demo) - Try to open the invoice created from the uploaded CFDI invoice => You will be able to open the invoice, but an Access Error on the attachment will be raised. Cause: When the CFDI invoice is uploaded, an attachment is correctly created from it and linked to the invoice. But another attachment is created from that document to create a "l10n_mx_edi.document" record. This second attachment has no reference to the invoice (i.e. its "res_model" and "res_id" fields are not set). opw-3579253 Forward-Port-Of: odoo/enterprise#50689
This update fixes how the configuration button works in accounting reports, particularly for composite reports that combine multiple sections. Previously, clicking the button would only open the current section's settings instead of the main report. The fix also ensures the button appears correctly in debug mode regardless of other display settings.
Original PR description
[FIX] account_reports: use correct cog button target on composite reports In debug mode, a little cog button is displayed next to the report filters. Clicking it open the form view of the report. The…
[FIX] account_reports: use correct cog button target on composite reports In debug mode, a little cog button is displayed next to the report filters. Clicking it open the form view of the report. The problem is the report used as the target of this action was options['report_id'], not options['sections_source_id']. Because of that, when clicking this button on a composite report, only the form view of the currently displayed section was open, while we actually should have opened the form of the whole composite report. -------------------------- [IMP] account_reports: allow opening the sections' form view from the composite report owning them For usability. ------------------------- [FIX] account_reports: don't depend on show_debug_column options to display the cog button The cog button allows opening the form view of the report to reconfigure it. It is only supposed to be displayed in debug mode. For that, the show_debug_column option key was used. Yet, this was wrong, as this option key is not always true in debug mode: for example, if a comparison is being done, it will be False. We now display the cog directly from debug mode info, without depending on options.
This fix resolves an issue in the Australian payroll module that was preventing employee data from being properly accessed and displayed. The fix adds necessary permission settings to employee fields, ensuring that employee information can be retrieved and used correctly throughout the system.
Original PR description
Purpose ======= This is breaking the hr.employee.public prefetching
This fix corrects how taxes are organized in Colombian electronic invoices (EDI format). The system now properly groups taxes by rate within each tax type section, ensuring invoices comply with Colombian tax authority requirements. This resolves an issue that was introduced in a previous update.
Original PR description
There should be one TIM section per Colombian tax type. Each TIM contains [1...*] IMP. These IMP should be grouped by tax rate. This commit ensures this, after a6647aabcd8d3fbfb6a270120bfffad3c4ed7c46 broke it. opw-3598156 Forward-Port-Of: odoo/enterprise#50978 Forward-Port-Of: odoo/enterprise#50920
Fixed an issue where deactivated accounting reports would still automatically open when selected from the menu instead of showing the active alternative report. This ensures that when users disable a specific report variant (like the Belgian VAT Return), the system correctly displays the appropriate active report instead.
Original PR description
On some variants of the reports, marking the reports as inactive wouldn't disable the automatic redirection towards this report when selected from the menu. Example to reproduce : - Open BE Company CoA - Make the belgian VAT Return report inactive (debug mode --> configuration --> accounting reports) - Open the Tax report ==> The belgian vat report was opened while the generic one should be opened, since we deactivated the belgian one. Added a check when compiling the available variants before redirection. task-3577540
This update resolves an unpredictable crash that was occurring in the frontdesk tour feature. The fix improves the reliability of the guided tour experience, ensuring users can complete the frontdesk onboarding process without encountering unexpected errors.
This update fixes a bug in the automatic account transfer feature where transaction records were being returned in inconsistent order. By adding proper sorting logic to the data retrieval process, the system now ensures that transfer records are always processed in the same sequence, improving reliability and preventing unexpected behavior.
Original PR description
In the function _get_transfer_move_lines_values, we empty the order of the query, because we do a group by. We should instead define another order, so the results are always returned in the same order. Related to runbot error 25781 Forward-Port-Of: odoo/enterprise#49915
This fix addresses an issue where importing bank statement CSV files with unsorted rows would result in incorrect account balances. The system now validates that imported CSV rows are sorted by date and raises an error if they are not, ensuring data accuracy during the import process.
Original PR description
steps to reproduce: import a csv file where the rows are not sorted by date before this commit: balances are not correctly set as the first row and last row are used, assuming the rows are sorted by date. after this commit: raise an error if the rows are not sorted. opw-3507204 Forward-Port-Of: odoo/enterprise#50847 Forward-Port-Of: odoo/enterprise#50706
This fix resolves two critical issues with Mexican electronic invoices (CFDI) when processing payments with 0% tax rates. First, it ensures that zero-rate tax information is properly included in payment documents. Second, it eliminates a system error that occurred when processing exempt tax invoices. These fixes ensure accurate and reliable payment processing for Mexican businesses.
Original PR description
Issue 1: With a 0% tax 'Tasa' in the invoice, TotalTrasladosBaseIVA0 & TotalTrasladosImpuestoIVA0 must be present in the payment CFDI file. Issue 2: With a 0% tax 'Exento', a traceback was raised when generating the payment CFDI. opw-3574611 Forward-Port-Of: odoo/enterprise#50506
This fix corrects an issue where vendor bills created from inter-company customer invoices between branches were incorrectly assigned to the wrong company. When a branch creates an invoice for another branch, the corresponding vendor bill now correctly belongs to the receiving branch instead of the originating branch. This ensures accurate financial records across multi-branch organizations using inter-company transactions.
Original PR description
When having a customer invoice from branch 1 to branch 2, the relative vendor bill's company id is wrongly set as branch 1. Steps: - Create two branches for a company - On both branches, activate inter-company transactions ans synchronize invoices/bills - Create an invoice from branch 1 to branch 2, confirm -> The relative vendor bill's company is set as Branch 1 instead of Branch 2 opw-3517000 Forward-Port-Of: odoo/enterprise#49232