Daily updates from Odoo
Monday, November 25, 2024
16 changes · 17.0
Resolved issues and error corrections
This update corrects a test issue in the HR Payroll Expense module, ensuring that an employee's bank account is established before approval of the payroll expense sheet. This prevents errors and ensures accurate processing of payroll transactions. The fix improves the reliability of the HR payroll system.
Original PR description
related: https://github.com/odoo/odoo/pull/181870 task-4206895 Forward-Port-Of: odoo/enterprise#71080
This update fixes a problem that prevented users from completely uninstalling the Helpdesk module when other Helpdesk-related modules were also removed. The change ensures a smooth uninstall process by forcing a necessary data refresh, preventing a key error related to field configurations.
Original PR description
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self]…
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self] KeyError: 'helpdesk.team.fsm_project_id' ``` Cause ----- Issue since 1da1467115726263e5cdc50354b4413f8bb7ca7d and the addition of `use_fsm` as a dependency of `_compute_fsm_project_id` When we uninstall any helpdesk module, we set to False the associated fields of all helpdesk teams (mapped in `_get_field_modules`) for all uninstalled modules. https://github.com/odoo/enterprise/blob/9fba5f841c3c0710eb0cce00263bf914dac03dc6/helpdesk/models/ir_module.py#L13-L16 The change of `use_fsm` means `fsm_project_id` is marked as a field to be recomputed. This happens at some point during a `flush_all`, but after the field has been deleted in DB and a new registry has been loaded without that field. Change ----- Force a recomputation by flushing the records. opw-4338172 opw-4339801 Forward-Port-Of: odoo/enterprise#74255
This update resolves an error in the Hong Kong payroll module that prevented calculations for internet allowances for new employees who hadn't started working. The fix ensures accurate allowance calculations by handling cases where work days are zero, preventing the system from crashing.
Original PR description
Steps to reproduce: - Install both hr_contract_salary and l10n_hk_Hr_payroll - Try to review a contract in recruitment Current behaviour: - Exception raised Expected behaviour: - No exception raised Explanation: - Internet allowance is based on employee actual work days. However, for candidate who hasn't join the company, they won't have any work days. Therefore the salary internet rules prorata_rate will be divided by zero, and raised exceptions. X-original-commit: f9e7d39
This update speeds up the barcode app by limiting the amount of data loaded when operations are opened. Previously, loading large numbers of empty packages caused significant delays. A new configuration setting allows users to balance data loading speed with network efficiency.
Original PR description
Currently, when an operation is loaded in the barcode app, the frontend executes a request to get_barcode_data which will perform a read on all relevant barcode data from the backend to cache it on…
Currently, when an operation is loaded in the barcode app, the frontend executes a request to get_barcode_data which will perform a read on all relevant barcode data from the backend to cache it on the frontend. The problem is, when loading the records of `stock.quant.packages`, it will attempt to read all empty packages with no location id. There are cases where these packages are way too many i.e. 500K and thus to read fields on these records, it would be terribly slow. As this is done upon opening every operation in the barcode app, it's making the app feel sluggish. To workaround the problem, this PR introduces a config paramter `stock_barcode.usable_packages_limit` which will limit the total number of empty packages being read to feed the frontend cache. This gives the option to tradeoff between cache locality and network connection. Setting this limit to a smaller number will result in more rpc calls instead of suffering a slowdown on one big rpc call to load all data once. Benchmarks: This will totally depend on the configured limit. Lower limit would mean higher speedup and vice versa. As an example, setting a limit of 1000 cut down the loading of get_barcode_data from 13.87 s to 768 ms opw-4245980 Forward-Port-Of: odoo/enterprise#74096
This update optimizes the performance of Odoo's list views by streamlining how the system identifies the currently edited record. By reducing unnecessary database queries, this change results in faster loading times for list views, enhancing the user experience.
Original PR description
This commit reduces the number of read to a getter `editedRecord` which loops on all the record of the list to find the current one in edition.
This update resolves an issue where document filtering was overly restrictive, limiting the actions available on visible records. By disabling domain selection, the system now correctly applies actions to records that are currently displayed, ensuring users can perform the intended operations. This improves the overall usability of the document management feature.
Original PR description
We disable the domain selection because most of the actions are only applied on visible records. Task-3754115
This update corrects an issue where the date wasn't displayed on Chilean Point of Sale (POS) receipts when a VAT number wasn't entered. The localization logic was incorrectly removing the date based on country and VAT status, leading to inconsistent display. This fix ensures the date is always shown on receipts for Chilean POS transactions, regardless of VAT presence.
Original PR description
### Steps to reproduce: - Install "l10n_cl_edi_pos" - Create a new company with the Chilian localization - Do not add a VAT number - Go to POS, create an order and validate - The date is not displayed on the ticket ### Cause: The localization is moving the date from the bottom of the receipt to the header but the conditions are not the same: - If the country of the company is Chile then date is removed from the bottom - If the company has a Chilian VAT the date is shown in the header So there is a case where none of the conditions are True and the date does not show. ### Solution: Add a condition on the VAT to delete the date from the bottom. opw-4330252
This update eliminates the creation of a duplicate demo account (123456) within Odoo branches. Branches primarily use their parent company's accounting data, so this change streamlines account management and avoids unnecessary duplication. It ensures branches accurately reflect their parent company's chart of accounts.
Original PR description
Branches can access their parent companies' accounts, and generally will just use their parent companies' CoA. Therefore, it makes no sense to create an account `123456 Account Payslip Houserental` in a branch if it already exists in the parent company. Community PR: https://github.com/odoo/odoo/pull/188247 task-none
This update clarifies the error message displayed when reporting VAT information in Argentina (l10n_ar_edi). The previous message was outdated and confusing, but the new message clearly explains the issue and provides guidance on how to resolve it. This improves the user experience and helps ensure accurate VAT reporting.
Original PR description
Before this change the message was showing an out-of-date minimun amount to report info of the receptor. Also, the message is more clearly to the user: what are the cases and how to solve them Old Message  New Message  LATAM 1291 / Adhoc ticket 82478 Forward-Port-Of: odoo/enterprise#73203
This update resolves a crash within the Web Studio module that occurred when reloading the interface. The fix ensures that critical data passed through URLs is correctly loaded, preventing the application from failing. This improves the overall stability and reliability of Web Studio for users.
Original PR description
…o studio Have a flow where active_ids is in the url and is used by the action itself (with a dynamic context key for example). Enter studio and reload. Before this commit, this flow crashed, because active_ids was not present. After this commit it doesn"t crash. opw-4296198 Forward-Port-Of: odoo/enterprise#74291
This update resolves a problem where invoices were being rejected by the ISS due to incorrect document types. The change automatically assigns the appropriate document type based on the customer's tax information, ensuring invoices are correctly processed and approved.
Original PR description
Users have encountered invoice rejections from the ISS due to an incompatible document type when creating automatic invoices. This modification ensures that the correct document type is assigned based on the customer's taxpayer type, allowing the invoice to be approved by the ISS. task-4299210 Forward-Port-Of: odoo/enterprise#73945
This update resolves an issue where invoices with spaces in their payment references (e.g., 'ODOO_BUG') weren't automatically matched with bank transactions. The fix ensures that all payment references, regardless of spaces, are correctly recognized, improving the reliability of automated reconciliation processes. This prevents missed matches and ensures accurate financial reporting.
Original PR description
### Steps to reproduce the issue: 1. Create an Invoice with "ODOO_BUG" as payment reference 2. Create a Bank Transaction with the same amount and customer as the Invoice and "ODOO_BUG" as Label 3.…
### Steps to reproduce the issue: 1. Create an Invoice with "ODOO_BUG" as payment reference 2. Create a Bank Transaction with the same amount and customer as the Invoice and "ODOO_BUG" as Label 3. The Transaction and the Invoice are automatically matched 4. Create an Invoice with "ODOO BUG" as payment reference 5. Create a Bank Transaction with the same amount and customer as the Invoice and "ODOO BUG" as label 6. The Transaction and the Invoice are not automatically matched ### Explanation: When evaluating `st_line_text_values` in `_get_invoice_matching_st_line_tokens`, the values are split at every whitespace. When trying to find `account.move.line` that match the tokens resulting from the operations, every `name`, `move_id.name` or `move_id.ref` with a whitespace in it will not be recognized due to the whitespaces being removed from the `account.bank.statement.line` side. ### Fix reasoning: From a business perspective, no Invoice/Payment/Bill reference should have a space in it bar some already covered exceptions. To avoid performance heavy queries, the text value will simply be added to `exact_tokens` and treated as such, allowing for an automatical reconciliation between an `account.move.line` and an `account.bank.statement.line` if their refs match perfectly. opw-4114296
This update fixes a bug that caused a traceback error when merging two Helpdesk tickets with specific SLA configurations. The change ensures the correct method is called during the merge process, preventing the error and ensuring smooth ticket merging functionality. This improves the stability and reliability of the Helpdesk module.
Original PR description
### Steps to reproduce: - Install Data Cleaning and Helpdesk modules - Create 2 Helpdesk tickets with conditions: - at least 1 helpdesk ticket has an SLA policy and is in a stage excluded by the SLA policy - at least 1 helpdesk ticket doesn't have an SLA deadline and has an SLA policy and is also in a stage excluded by the SLA policy - Merge those 2 tickets - Notice a traceback pops-up ### Current behavior before PR: In this commit https://github.com/odoo/enterprise/pull/69352/commits/97e83104dad816a7a65345dea74a66e5dbea94cb a new merge method was introduced but in the new file we created we are importing datetime from datetime and then using datetime.datetime and since we are already importing the sepcific class we don't need to call it like module.class.method ### Desired behavior after PR is merged: We are calling the method directly from the class without using the module before the call so it is only datetime.max opw-4330793
This update fixes a bug in Odoo's Studio where changes to menus weren't immediately reflected in the editor dialog. The issue stemmed from a change in how Studio handles its environment, preventing key events from being properly communicated. Now, menu modifications are correctly displayed in the editor after confirmation.
Original PR description
In studio, click on Edit Menu in the main navbar. Add a menu or edit the name of a menu. Click Confirm Before this commit, the hierarchical list of the menu editor was not updated. This was due to the fact that studio's dialog service is altered to allow it to have the specific studio sub environment It is that way since 2ae63d9a43ba973d905232105201d88e423a8245 As a consequence, the "menu changed" event triggerd by the menu service on the main environment's bus was not forwarded to to studio's env's bus. After this commit, the hierarchical list is updated correctly task-4001101
This update fixes an issue within Odoo's Web Studio module related to how address formatting is handled. The change ensures that address replacements work correctly when a specific setting is used, improving the consistency of address displays. This resolves a technical limitation impacting the user experience within Web Studio.
Original PR description
The FormatAddressMixin implements a feature that will replace some parts of a view with some other when having no_address_format in the context. commit 28d8ee5ea27106bf21e5a25c3fce48d39ffed4fd partially solved the problem, but not for all the spots where we need to do a `get_view` without being parasited with the foreign tree parts. opw-4335439
This update ensures that transaction currencies are correctly set, even when a company doesn't use multiple currencies. Previously, a missing currency setting would cause issues. Now, the system automatically uses the company's default currency, improving data accuracy and reliability.
Original PR description
In case we are not in a multi currency environment the currency of the journal is falsy, so if there is not a currency set, we take the one from the company task: 4293986