Daily updates from Odoo
Tuesday, November 14, 2023
19 changes · 17.0
Enhancements to existing features
Knowledge now automatically saves your work when you click away from the document or switch windows. This improvement prevents the frustrating loss of unsaved changes by detecting when you've left the document and saving any modifications you've made.
Original PR description
This commit adds an autosave feature when the window detects a `focusout` event. This enables Knowledge to save more often in order to fix one of its biggest issue: the surprise loss of data. When we detect a `focusout` we call the method isDirty to check if the body has indeed been modified. If that's the case then we launch the save mechanism to commit the changes done to the Database. task-3531468
Resolved issues and error corrections
This fix resolves an issue where article content was being lost when users changed the visibility settings of a Workspace article. The problem was caused by the editor being reset after loading, which unintentionally removed the content. The fix ensures that content is properly saved before any visibility changes are applied.
Original PR description
**Before this PR**: - Changing the visibility of a Workspace article did not save the content, resulting in content loss. - In several functions `isDirty` function returns a pending promise, hence the `if conditions` are always calculated to be true. **Reason**: - The issue was caused by the behavior of the `resetEditor` function. From `_onChangeVisibility`, `resetEditor` function triggers after calling `load` function, which resulted in the unintentional removal of the article content. - `isDirty` has been changed from getter method to async function from PR https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3 **After this PR**: Now article content is saved when visibility changes. **Task**-3491577
This fix prevents users from accidentally reducing quantities of service products that have already been marked as delivered in Field Service Management tasks. When a service product is added to a task, its quantity is now locked at the delivered amount, preventing inconsistent behavior and error messages when users try to decrease it.
Original PR description
- steps: open fsm app -> select a task -> add products -> select service product -> add some qty -> try to remove qty -> inconsistent behavior and error message. - Issue: The qty of these products…
- steps: open fsm app -> select a task -> add products -> select service product -> add some qty -> try to remove qty -> inconsistent behavior and error message. - Issue: The qty of these products should not be decreasable - Cause: Service product with the *qty_delivered_method* set as 'manual' are considered as directly delivered so their quantities shouldn't be decreasable once you added quantity. This logic is applied in the __inverse_fsm_quantity_ method in industry_fsm_sale module - Fix: adding a min_quantity key in the catalog _sale_product_catalog_update_sale_order_line_info_ method return dictionary, the value is setted as the sol.qty_delivered. Once this value has been fetched, the kanban_record will include it in the productCatalogData.minimumQuantityOnProduct I'm open to discussion to implement this in the sale_stock module but i don't think the quantity delivered are updated as soon as the quantity is added to the sale order anywhere else than in the industry_fsm_stock module. Also added a small improvement, if the product is already at the delivered/minimum quantity, inputing a quantity below the delivered/minimum one will reload the record to set the quantity to the delivered/minimum. Task-3553140 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves issues with spreadsheet version history when spreadsheets are created from templates. Previously, users would encounter errors when trying to view version history, and the system would lose track of revision information due to mismatches between template data and regular spreadsheet data. The fix ensures that spreadsheet data is properly converted and synchronized when created from templates, and that revision history is correctly maintained and cleaned up.
Original PR description
Task: 3575942
This fix restores proper translations for Belgian accounting reports in Dutch, French, and German languages. The translations were not being applied correctly due to annotation issues that occurred during the review process. This ensures users in Belgium can now see the accounting reports in their preferred language.
Original PR description
After merging the new Belgian accounting reports in 17.0, it seems the translations were not having the right annotions (due to a renaming during the review process) and were thus not applied. Original commit: https://github.com/odoo/enterprise/commit/c76133635bc1542765937116f02bbbd390599106 This commit fixes that such that the Belgian reports are properly translated again in NL, FR and DE. no-task-id
Fixed a crash that occurred when Italian users filtered the General Ledger report by Customer Invoices or Vendor Bills. The issue was caused by incorrect report configuration when localized tax reports were installed. The fix ensures the correct base report is selected, allowing users to filter by journal type without errors.
Original PR description
[FIX] account_reports : general ledger localization Issue: ====== In some countries (like Italy), with the corresponding l10n module installed, opening the General Ledger and selecting the "Customer…
[FIX] account_reports : general ledger localization Issue: ====== In some countries (like Italy), with the corresponding l10n module installed, opening the General Ledger and selecting the "Customer Invoices" or "Vendor Bills" journal in the filter crashes, telling the `report_id` of the computed options is inconsistent with the report using them. Steps to reproduce the issue: ============================= - Install accounting and l10n_it_reports - Go to accounting / reporting / general ledger - Choose customer invoices in journals Origin of the issue: ==================== When selecting only sales or purchase journals (not both together), the General Ledger displays additional lines corresponding to the data of the Generic Tax Report matching the chosen options. The way it was done in 16.4, however, let the tax report choose the first variant available for the current company, so if the l10n module contained a tax report, the wrong report was chosen and set in `report_id`, and we were calling the Generic Tax Report with an options dict whose `report_id` key corresponded to a localized variant instead of the root report. Solution: ========= Previous versions used to directly force the `report_id` key, but this does not work anymore because of the introduction of the composite reports (aka sections), and the way they changed the options generation. The key to force is now `selected_variant_id`, to make sure the root report is the one that gets selected. opw-3580078 Forward-Port-Of: odoo/enterprise#50399
This fix resolves a critical error that occurs when the EDI document processing system runs automatically. The issue was caused by using an underscore (_) as a variable name, which conflicts with Odoo's translation system. This fix renames the variable to prevent the system from crashing when processing electronic invoices for Ecuador.
Original PR description
Currently, an error occurs as below when cron 'EDI : Perform web services operations' runs. Error: ``` TypeError: 'str' object is not callable File "odoo/tools/safe_eval.py", line 365, in safe_eval…
Currently, an error occurs as below when cron
'EDI : Perform web services operations' runs.
Error:
```
TypeError: 'str' object is not callable
File "odoo/tools/safe_eval.py", line 365, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(615,)", line 1, in <module>
File "addons/account_edi/models/account_edi_document.py", line 256, in _cron_process_documents_web_services
nb_remaining_jobs = edi_documents._process_documents_web_services(job_count=job_count)
File "addons/account_edi/models/account_edi_document.py", line 243, in _process_documents_web_services
self._process_job(job)
File "addons/account_edi/models/account_edi_document.py", line 202, in _process_job
edi_result = method_to_call(moves)
File "home/odoo/src/enterprise/saas-16.4/l10n_ec_edi/models/account_edi_format.py", line 220, in _cancel_invoice_edi
return self._l10n_ec_cancel_move_edi(invoices)
File "home/odoo/src/enterprise/saas-16.4/l10n_ec_edi/models/account_edi_format.py", line 202, in _l10n_ec_cancel_move_edi
_("You cannot cancel a document that is still authorized (%s, %s), check the SRI portal",
ValueError: <class 'TypeError'>: "'str' object is not callable" while evaluating
'model._cron_process_documents_web_services(job_count=20)'
File "odoo/addons/base/models/ir_cron.py", line 373, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 688, in run
res = runner(run_self, eval_context=eval_context)
File "odoo/addons/base/models/ir_actions.py", line 558, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 379, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
This is because with the recently reflected https://github.com/odoo/enterprise/pull/49350 added [1],
which uses `_` as a variable,; in Odoo, `_`(_()) is used in translation, and it is a class, so we can't use
`_` as a variable.Also, this is causing the "local variable `_` referenced before assignment" error from [2]
because the '_l10n_ec_cancel_move_edi' method tries to access `_` before [1] when the above cron
runs or when a user requests a cancellation EDI.
This commit fixes the above issue by changing the variable name.
[1]-https://github.com/odoo/enterprise/blob/b1abcb7a5b075ccbb1409a5fb19c6b142bc6cf77/l10n_ec_edi/models/account_edi_format.py#L197 [2]-https://github.com/odoo/enterprise/blob/b1abcb7a5b075ccbb1409a5fb19c6b142bc6cf77/l10n_ec_edi/models/account_edi_format.py#L190
sentry-4608132760
Forward-Port-Of: odoo/enterprise#50353This update fixes an issue where incoming invoices for Chilean operations were not applying the correct default tax. The system now properly adds the default purchase tax when processing incoming emails with invoices, and prioritizes it in the tax sequence to ensure it's applied first.
Original PR description
Since changes have been made in default tax settings, incoming emails with invoices for l10n-cl are not configuring the tax correctly. This ensures that the default tax is being added correctly. This PR is a revision of #49332 wich did not work since method `_get_withholding_taxes()` returns a set, and the default_purchase_tax cannot be added that way. Besides, as the default tax is the main one, we put it first in the sequence of taxes. Forward-Port-Of: odoo/enterprise#49651
This fix resolves an issue where subsidiary companies could not access parent company accounts when performing bank reconciliation. Users working with subsidiary branches can now properly select accounts from the parent company in the reconciliation widget, enabling complete financial operations across the company structure.
Original PR description
When having a sub company selected, the accounts from the parent company.ies are not accessible in the reconciliation widget. Steps: - Have a company with one branch (X and X.1) - Create a bank statement line in X.1 - In the manual operations tab of reco widget, try to select another account -> no accounts available opw-3518443 Forward-Port-Of: odoo/enterprise#48368
This update fixes a bug in the Planning module where recurring shifts created on the last day of a month were incorrectly scheduled for earlier dates in subsequent months. For example, a shift starting on January 31st would appear on February 29th instead of the last day of February. The fix ensures all recurring shift occurrences maintain their original day-of-month position, improving scheduling accuracy and reliability.
Original PR description
Steps: In planning, create a shift with date: 31/1/2020 and recurrence each month for 5 months. Expected: For all shifts, the date should be the last day of the month. Issue: From February on, each shift's date is the 29th. Cause: We calculate the next date by adding the recurrence delta to the previous one. In this case: `31/1/2020 + 1 month = 29/2/2020; 29/2/2020 + 1 month = 29/3/2020; etc.` Fix: Calculate the nth next date by adding the recurrence delta, multiplied by n, to the first date. In this case: `31/1/2020 + 1 month = 29/2/2020; 31/1/2020 + 2 month = 31/3/2020; etc.` task-3449851 Forward-Port-Of: odoo/enterprise#50503 Forward-Port-Of: odoo/enterprise#44965
This fix resolves a discrepancy in how helpdesk ticket open hours were being calculated across different reports. The system was using different date references (assignment date vs. close date) in different places, causing the same ticket to show different hours open depending on which report you viewed. This update ensures consistent calculations across all helpdesk reports by using the creation date to close date method, which aligns with Odoo's official documentation.
Original PR description
`_compute_open_hours`() is not defined the same way as the SQL one. `_compute_open_hours` uses `close_date` and SQL view uses `assign_date`. https://www.odoo.com/documentation/16.0/applications/services/helpdesk/overview/reports.html uses difference between create date and close date so we'll use that one. _steps to reproduce:_ - create a helpdesk ticket and close it - compare helpdesk.ticket and helpdesk.ticket.report.analysis _before this commit:_ hours open are different on the two models _after this commit:_ hours open are the same on the two models opw-3562355 Forward-Port-Of: odoo/enterprise#49956
This update removes references to the IAP sandbox platform from the Peruvian EDI module, as this platform will no longer be supported. The change simplifies the code without affecting functionality, since test mode already operates without requiring credits.
Original PR description
The support for IAP sandbox platform will soon be dropped, so all references to it need to be removed. This reference wasn't necessary in the first place since, in test mode, the service doesn't require credits to run. Forward-Port-Of: odoo/enterprise#50387
This update removes unnecessary test server configuration from the digital signature service (itsme). A recent system update made the manual endpoint switching no longer needed, simplifying the setup process and reducing maintenance overhead.
Original PR description
Since commit odoo/odoo@550595d, it's no longer necessary to change the endpoint to the IAP services test server. Forward-Port-Of: odoo/enterprise#50402
This fix ensures that paused subscriptions are now displayed when viewing a customer's subscription list. Previously, paused subscriptions were hidden from the customer's page, making it difficult to track all subscription statuses. Now customers and support teams can see the complete subscription history including paused ones.
Original PR description
[FIX] sale_subscription : Paused subscription is not visible in contact's page Steps to reproduce: 1- Install Subscriptions and Contacts modules 2- Pause a subscription that is 'In progress' 3- Go to the customer's page and click on the subscription smart button Current behavior before PR: The paused subscription is not shown in the list of subscriptions under a contact Desired behavior after PR is merged: The subscription list for each contact will now show the paused subscription too opw-3571647 Forward-Port-Of: odoo/enterprise#50514 Forward-Port-Of: odoo/enterprise#49732
Fixed a critical issue where the bank reconciliation widget wasn't updating when transaction amounts were modified in the list view, which could result in incorrect journal entries being created. The system now properly refreshes the reconciliation display to reflect all changes made to transactions, ensuring accurate financial records.
Original PR description
The bank reconciliation kanban view is currently not updated after changes to transactions in the list view. This can lead to wrong (outdated) information to be shown on the right side in the bank…
The bank reconciliation kanban view is currently not updated after changes to transactions in the list view. This can lead to wrong (outdated) information to be shown on the right side in the bank reconciliation kanban view. This further allows creating wrong reconcilation journal entries with the "Validate" button (I.e. after a change to the "amount" of a transaction in the list view is not reflected on the right side of the bank reconciliation kanban view). The test tour was extended to test for this case. To reproduce: 1. Go to bank reconciliation (in kanban view) 2. Select some transaction kanban card that is not yet reconciled 3. Switch to the tree view 4. Modify the "amount" field of the transaction that was selected in step 2. This corresponds to a change in the database. 5. Switch back to kanban view 6. The right part of the UI (under the "Validate" button) is not updated: I.e. the top line (liquidity line) has a wrong debit / credit. 7. Validate 8. The journal entry created due the validation in step 7 uses the non-updated / wrong values and is thus wrong. task-3504471 PR on 16.0: https://github.com/odoo/enterprise/pull/47930 (very different code) Forward-Port-Of: odoo/enterprise#48175
Fixed an issue in the Barcode app where scanning a tracked product component would create a duplicate line instead of selecting the existing one when no lot number was assigned yet. This fix allows users to properly assign lot numbers to tracked components without manual intervention, improving the efficiency of barcode-based receiving workflows.
Original PR description
When a move line is for a tracked product, if its `qty_done` is equal or greater than its `product_uom_qty`, the line will not be selected when the product will be scanned. It's annoying when this line has no lot yet. How to reproduce: - Create a product with a BoM kit and at least one tracked component (both product should have a barcode of course); - In the Barcode App, create a new receipt; - Scan the product kit and validate -> Before the validation, the kit is decomposed and a line for each component should be created; - Scan the tracked component -> Instead of selecting the existing line, a new one is created. That means the user is not able to set the lot for this line without select it manually. To fix that, the line will be selected even if it has enough `qty_done` only if the product is tracked and there is no lot/serial number. Forward-Port-Of: odoo/enterprise#49608 Forward-Port-Of: odoo/enterprise#49163
This update resolves an issue where the Recruitment Analysis menu appeared twice in the system. The fix ensures that the recruitment reporting menu properly overrides the original menu, eliminating the duplicate entry and providing a cleaner navigation experience for HR teams.
Original PR description
Before this commit, two menuitems were created for Recruitment Analysis. This commit redirects the menuitem from hr_recruitment_reports to override the menuitem from hr_recruitment. follow-up of odoo/enterprise#46083 Forward-Port-Of: odoo/enterprise#49114 Forward-Port-Of: odoo/enterprise#49099
This fix resolves an issue where direct messages couldn't be opened properly on Android and iOS mobile apps after a recent system update. The fix ensures that mobile apps receive the correct information to display direct messages in the proper view when users click on notifications.
Original PR description
* = test_mail_enterprise Since commit [1], the model `mail.channel` was renamed to `discuss.channel`. In our Mobile App (Android, iOS) we have a specific logic to handle opening a DM with the correct action related to this model. Due to this renaming, we were not able to open the action of the direct message on Android and iOS apps. Also, as we can't push change on `iOS`, we are not able to adapt the logic in the Mobile App (due to Apple Store Policies). This commit forces to send the old model to apply the correct logic on the Mobile App (Android, iOS). Steps to reproduce: * Send a DM to the Mobile App's user * The user clicks on the notification * The Mobile App opens but not in the correct view => BUG [1]: https://github.com/odoo/odoo/commit/90cb44e1e1b6bad9c12f3bd14d1c9e340461e19e Forward-Port-Of: odoo/enterprise#50520
The daily target input fields in the Helpdesk 'My Performance' section now display correctly in dark mode. Previously, these fields showed an unwanted visual effect when focused. This fix improves the overall appearance and consistency of the interface for all users.
Original PR description
Before this commit, in helpdesk homepage, the daily target inputs in the 'My Performance' area were reasonably functional in focused state, but in dark mode, they exhibited an undesirable box-shadow/inset effect. This commit addresses the issue by applying a 'form-control' class to the inputs and removing any superfluous classes, thereby enhancing the visual consistency and aesthetic. <table> <tr> <td>Before</td> <td> After</td> <tr> <td> <img alt="before" src="https://github.com/odoo/enterprise/assets/80678921/fef930e2-06d3-4932-ac91-726f6fddd132"> </td> <td><img alt="after" src="https://github.com/odoo/enterprise/assets/80678921/16321474-0070-4987-9e35-c4b963f8dc6f"> </td> </table> task-3593349 Forward-Port-Of: odoo/enterprise#50536