Tuesday, October 15, 2024
29 changes
1 change
Resolved issues and error corrections
This fix ensures companies are listed in the expected order in account reports, with the main company shown before its branches. This helps keep report results consistent and avoids confusion when reviewing multi-company data.
Original PR description
Companies will be returned main first then branches. reshuffling the expected results
15 changes
Resolved issues and error corrections
This fixes account code availability checks so codes mapped from other companies no longer incorrectly block new accounts. Businesses using multiple companies can reuse valid account codes in the intended company without unnecessary setup conflicts.
Original PR description
In #181352, we relaxed the constraint that prevented accounts from being mapped to an account code in a company the account doesn't belong to, if there already exists an account in that company that already has that code. That constraint was annoying because it meant that mapping an account to a code in a different company would "reserve" that code in the other company's CoA. When we relaxed that constraint, we forgot to modify '_search_new_account_codes' such that the previously-reserved codes would now be available for new accounts. This commit fixes that. task-none
9 changes
Resolved issues and error corrections
This fix corrects an issue where Mexican companies' CFDI invoices, payments, and delivery slips were displaying the wrong digital stamp for the emitter. The system was incorrectly showing the SAT (tax authority) stamp in both stamp fields instead of showing the company's own digital stamp alongside the SAT stamp. This has been corrected to display the proper stamps in the PDF documents.
Original PR description
### Steps to reproduce the issue: 1. In Mexican Company, create an Invoice elligible for CFDI 2. Send & Print 3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same ### Explanation: In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello` ### Fix reasoning: Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values opw-4227743
Discount descriptions on sales orders now display more clearly with the updated product description layout. This helps sales teams and customers better understand applied discounts without confusing or poorly formatted text.
Original PR description
c3e98851d9b509e97fbcc78616ff5580222425d1 introduced a new widget for products' descriptions on SO. This commit aims to fine-tune the behavior of discount description to better fit the new display.
The message action label was shortened from “Copy Message Link” to “Copy Link” in mail and live chat. This makes the interface cleaner and easier to scan without changing the underlying behavior.
Original PR description
Shorter is better. Part of Task-4260440 
The Italian electronic invoicing direct debit flow now identifies payments more accurately after a status change in Odoo. This prevents already paid transactions from being missed when determining the payment method, reducing errors in Italian payment reporting.
Original PR description
When computing the payment method, we searched for `in_process` but now we consider them `paid`, so we're just checking for `not draft` payments instead. Related PR: odoo/odoo#178235 Runbot link: https://runbot.odoo.com/web#id=76193&model=runbot.build.error&menu_id=405 runbot-76193
Quotation template users are now prevented from uploading unsupported file types in the quote builder. This avoids confusing upload failures and system errors when non-PDF files are selected.
Original PR description
Currently, an exception was generated when the user uploaded a non-pdf file in Quate Builder of quotation templates. error: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte` This commit will fix the above issue by preventing uploading non-supported files that were uploaded by users. sentry-5962839786
This fix prevents the point of sale from failing when a product does not have an Indian HSN code set. Cashiers can add such products to orders normally, reducing interruptions during sales.
Original PR description
Before this commit, adding a product without the l10n_in_hsn_code field to an order would cause an error, as the system expected this field to be a string. opw-4254621 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where extra browser launch settings could be lost when fullscreen or kiosk mode was enabled. It helps hardware-connected browser sessions open with the intended options and restores fullscreen behavior in Firefox.
Original PR description
Before this PR, the `Browser` helper class used a `chromium_additional_args` variable to keep track of extra command line arguments. However, it's contents were overwritten by the `fullscreen()` and `enable_kiosk_mode()` functions, causing the additional arguments to be lost. This PR removes the variable and instead constructs the argument list when `open_browser` is called. It also fixes fullscreen mode in Firefox by restoring a keypress call that was removed in v18. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The To-Do form view now expands to use the available screen height, matching the experience users already have with task forms. This also fixes related resizing behavior for rich text fields when records are saved or changed with the pager, making editing more consistent.
Original PR description
Before this commit, the height of the form view does not really take the whole space available in the screen as it is the case in the form view of task. This commit makes sure the height of the form view in To-Do app takes the whole screen height as task form view.
This update resolves several operational issues across Odoo, including Finnish VAT reporting, manufacturing work order quantities and durations, purchase valuation rounding, POS superuser access, image thumbnails, and editor toolbar behavior. These fixes improve reporting accuracy, reduce accounting corrections, and make day-to-day workflows more reliable for users.
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
The self-order payment page now starts the payment process only after the page is mounted, avoiding repeated page renders. This prevents duplicate Razorpay terminal requests for the same order, reducing payment errors and improving checkout reliability.
Original PR description
Before this commit: =================== The payment page was being rendered multiple times due to the `onWillStart` method triggering the `startPayment` method multiple times. This led to multiple requests being sent to the Razorpay terminal for the same order. After this commit: ================== Replaced `onWillStart` with `onMounted` to initiate the `startPayment` method. This prevents duplicate requests to the Razorpay terminal for the same order, ensuring the payment process is handled efficiently. Task- 4254682
Employees on flexible-hour schedules now get a single work entry when their attendance spans lunch. This prevents inflated or fragmented work records and keeps payroll-related time tracking aligned with actual attendance.
Original PR description
Steps --- * Create a flexible hours working schedule * Create a running contract for some employee that uses this schedule * `work_entry_source = 'attendance'` * Create an attendance overlapping lunch for the employee * (e.g 10:00 -> 20:00) * => 2 work entries are generated. But we want only one (10 - 20). * 10 - 12 * 13 - 20
Restaurant point of sale users can now print a bill for an order that has not yet been sent without triggering an error. The change prevents the system from trying to update an order in the backend before it has been fully created there, avoiding an interruption during service.
Original PR description
Steps to reproduce : -------------------------- - Install the pos_restaurant module. - Open session and add something to order. - Don't order them and try to print the bill. Issue : -------- - There will be a traceback as it was trying to update order at backend. Cause : --------- - The order is still draft and have string_id so we can't update it. Fix : ------ - Only update if order is created at backend and have integer id.
Exported journal reports in PDF format now include appropriate side margins. This prevents content from running to the edge of the page, making printed or shared reports easier to read and more professional.
Original PR description
Before this commit, when we export the journal report as a pdf, the side of the content were extended to the side of the page. This commit adds a css property to set margin to the content of the page. task-4260189
Manufacturing users can now post work-in-progress accounting entries even when a work order has been started but its time tracking has not yet been ended. This avoids a blocking error and helps keep manufacturing accounting actions usable during normal operations.
Original PR description
before this commit, if user tries to open/generate WIP entry for manufacturing without recording the end time in the time tracking inside the work order a traceback is shown to user * create a manufacturing order that generate work order * in the work orders generated, start a work order * now click on POST WIP accounting entry from action * traceback is shown after this commit, no traceback wont be shown in the above scenario
This fix updates checkout test flows so rental orders correctly reach the delivery step before confirmation. It helps ensure the online rental checkout experience is validated reliably and reduces the risk of unnoticed checkout issues.
Original PR description
…checkout _* = website_sale_renting, website_sale_stock_renting Added the 'tourUtils.confirmOrder(),' to fix the tour.
A recent update caused partner names and other non-account information to be misaligned when exporting certain financial reports to Excel. This fix restores the correct display of partner names and similar data in exported reports like the partner ledger, ensuring users see the information in the right columns.
Original PR description
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb
Fixed an issue where users without HR permissions couldn't view employee pictures in the appraisal goal view. Users can now access the public employee profile by clicking the picture, and the "mark as done" option is properly hidden when a goal is already completed. This improves the user experience for non-HR staff using the appraisal system.
Original PR description
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631
This update adds new accounts to the Finnish financial reporting system to improve the chart of accounts structure. The changes ensure that the balance sheet reports now include additional account categories needed for more accurate financial reporting in Finland.
Original PR description
Adding some new accounts in the reports task: 4210069
This update fixes a crash that occurred in the accounting reports when users rapidly removed multiple partners from a filter. The system now gracefully handles situations where filter update requests fail, preventing the application from becoming unresponsive. This improves the stability and user experience when working with partner filters in account reports.
Original PR description
When the partner filter gets a lot of partners removed one after the other very fast, sometimes the filter update request fails, and the `this.data` variable becomes `null` while waiting for data. When this happens, we just ignore the invalid data to mitigate the problem. In [saas-17.2](https://www.odoo.com/odoo/project/967/tasks/3912381) this has anyway being amended by introducing a delay between the partner cancellation and the the filter update. Subsequent requests just reset the delay, so one only request is done in the end. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4020313) opw-4020313
This fix removes a restriction that was preventing users from manually disabling automatic transaction syncing in their online banking connections. Previously, a technical condition was blocking users from saving changes to the auto-sync setting, making it impossible to turn off automatic syncing when needed. The fix simplifies the approach by removing this problematic restriction.
Original PR description
A previous [commit](https://github.com/odoo/enterprise/pull/63926/commits/c749e1358dbd0175d0de5f32eab2c4dd98053905) added a readonly condition on the field auto_sync of the account.online.link view. This was made to prevent the automatic fetching of transaction from interactive providers when the connexion had expired. The issue lies in that condition being based on the field it applies to. This does not work well with manual editing as the readonly condition would update before hitting 'save', preventing to save the changes when unticking the 'auto_sync' checkbox. After discussion with FLG, we decided to keep things simple and remove that condition altogether. Else, one would have had to create a new field and import new data from the institution (is_interactive). No opw but the issue was raised in a odoofin support discord thread.
A bug in the barcode scanning system for manufacturing operations has been fixed. The system was not properly returning results from an internal function, which could cause operations to fail silently. This fix ensures that barcode scanning operations complete correctly when processing inventory moves.
Original PR description
Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super().
Mexican invoices now correctly display the Uso field in Spanish when the customer's language is set to Spanish (MX), instead of showing it in English. This fix ensures that invoice PDF reports respect the customer's language preference for all field labels and values.
Original PR description
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to…
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to reproduce the issue: - Go to the Accounting app --› Customer invoices journal --› Create a new invoice. - Select a customer with the Spanish (MX) / Español (MX) language set. - Select any product from the inventory catalog. - Set the Uso (l10n_mx_edi_usage) as "Gastos en general". - Confirm the invoice. - Click on "Send and print" button and mark the CFDI checkbox in the next window, click on send and print button again. - The Uso (l10n_mx_edi_usage) field is being translated into English, despite the language set for the customer is Spanish (MX) / Español (MX). Cause of the issue: The XML template (report_invoice.xml) uses a dynamic value for the Uso field, preventing the standard PO file translations from being applied. A python translation using the _description_selection from Fields with the env language detection method is necessary in the _l10n_mx_edi_get_extra_invoice_report_values method in account_move.py. opw-4212069
Fixed an issue where EC Sales Reports were incorrectly including transactions when a customer had a delivery address in a non-EC country. The system now properly checks the delivery address country first when determining if a transaction should be included in EC sales reports, and only falls back to the company's country if no delivery address is specified.
Original PR description
…sales Steps to reproduce:: [l10n_fr] - create a customer, BE Company; delivery adress USA - create an invoice for the customer - Go to EC Sales Report Issue: The transaction is displayed Solution: When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries opw-4131299 Forward-Port-Of: odoo/enterprise#69960